Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Tento systém souborů si za dobu své krátké existence prošel snad každou částí cyklu mediálního humbuku. Nějakou dobu to byl systém souborů příští generace, který měl vyřešit mnoho našich problémů; distribuce válčily, aby se ukázalo, kdo jej bude mít jako výchozí jako první. Pak se ukázalo, že všichni ti zkušení vývojáři systémů souborů si nedělali legraci, když tvrdili, že trvá celé roky, než je systém souborů dostatečně důvěryhodný na to, aby mu bylo možné svěřit důležitá data. Aktuálně je možné jít na konferenci a slyšet na Btrfs akorát samé stížnosti; vypadá to, že došlo na vystřízlivění. A než bude Btrfs opravdu připravené, tak si asi řada lidí bude myslet, že je už úplně zastaralé.
Pravda ale nemusí být tak deprimující. Vývoj Btrfs pokračuje se silným důrazem na stabilitu a výkon. Problémy jsou opravovány a uživatelé se po tomto slibném systému souborů znovu poohlížejí. Hraje si s ním více uživatelů a openSUSE v září dokonce zvažovalo, že by mohl být jako výchozí systém souborů. Situace se možná stabilizuje a možná se pomalu dostáváme do nové fáze, kde se – stále pomalu – usadí jako jeden z klíčových systémů souborů na Linuxu.
Tento článek je zamýšlen jako první díl seriálu pro uživatele, kteří by rádi zkoušeli a hráli si se systémem souborů Btrfs. Začneme se základy návrhu Btrfs a jak je vyvíjen; pak se podrobně podíváme na specifické funkce Btrfs. V tomto seriálu se ale určitě neobjeví výsledky benchmarků; ukazuje se, že řádné testování systémů souborů je obtížné; je také silně závislé na zátěži a hardwaru. Nekvalitní výsledky by nikomu nepomohly, proto to ani nebude zkoušeno.
Není to tak dlouho, co uživatelé Linuxu stále pracovali se systémy souborů, které se od dob Unixu moc nevyvinuly. Systém souborů ext3 například stále používá blokové ukazatele: inode každého souboru (centrální datová struktura s veškerými informacemi o souboru) obsahuje seznam ukazatelů na každý jednotlivý blok obsahující data souboru. Tento návrh fungoval dobře, pokud byly soubory malé, ale špatně škáluje: 1GB soubor by vyžadoval 256 tisíc ukazatelů na blok. Novější systémy souborů (včetně ext4) místo toho používají ukazatele na „extents“; každý extent je skupinou souvislých bloků. Jelikož se systémy souborů snaží ukládat data souvisle, ukládání na bázi extentů značně snižuje režii spojenou se správou prostoru souboru.
Btrfs samozřejmě používá extenty také. Ale značně se liší od většiny jiných systémů souborů: jde o systém souborů typu copy-on-write („COW“, kopíruj při zápisu). Kdykoliv jsou na ext4 přepisována data, nová data jsou zapsána přes stávající data na úložném zařízení, čímž je původní kopie zničena. Btrfs místo toho přesune přepisované bloky jinam v rámci systému souborů a zapíše nová data tam, takže starší kopie zůstane nedotčena.
Režim COW přináší řadu výhod. Jelikož nejsou stará data přepisována, obnova po pádech a výpadcích dodávek energie je přímočařejší; pokud nebyla transakce dokončena, pak zůstává původní stav dat (a metadat) na původním místě. Proto mimo jiné nemusí systém souborů typu COW implementovat oddělený žurnál pro získání odolnosti proti pádům.
Copy-on-write navíc nabízí zajímavé nové funkce, především pak snapshoty. Snapshot je virtuální kopie obsahu systému souborů; je možné jej vytvořit bez jakéhokoliv kopírování dat. Pokud je později změněn blok dat (buď ve snapshotu nebo v originálu), pak je tento jediný blok okopírován, zatímco původní data se nadále sdílejí. Snapshoty se mohou používat jako takový „stroj času“ nebo pro jednoduchou obnovu systému při selhání aktualizace.
Další důležitou funkcí Btrfs je vestavěný správce jednotek. Systém souborů Btrfs může pokrývat několik fyzických zařízení při různých konfiguracích RAID. Jakákoliv jednotka (sada jednoho nebo více fyzických zařízení) může navíc být rozdělena na „podjednotky“, které můžeme vnímat jako nezávislé systémy souborů sdílející společnou sadu fyzických jednotek. Btrfs tedy umožňuje spojit některá nebo všechna úložná zařízení v systému do jednoho velkého zdroje, který pak může být sdílen mezi různými systémy souborů a každý bude mít svá vlastní omezení využití.
Btrfs nabízí celou škálu dalších funkcí, které nejsou jinými linuxovými systémy souborů podporovány. Může provádět úplné kontrolní součty dat i metadat, což jej činí robustním při poškození dat hardwarem. Úplné kontrolní součty jsou ale náročné, takže se dá očekávat, že nebudou používány na mnoha místech. Data mohou být ukládána na disku v komprimované podobě. Funkce přijmi/odešli se dá mimo jiné používat jako součást mechanismu pro přírůstkové zálohování. Funkce pro online defragmentaci může za běhu systému opravit fragmentované soubory. V jádře 3.12 jsme mohli zaznamenat přidání funkce pro offline deduplikaci; hledá bloky obsahující stejná data a sdružuje je do jediné sdílené kopie. A tak dále.
Je nutné upozornit, že přístup copy-on-write není zadarmo. Je evidentně nutné provádět nějaké garbage collection (úklid nepoužívaných dat), jinak by kopie bloků rychle spotřebovaly všechno volné místo na systému souborů. Kopírování bloků může navíc zabírat více času než prosté přepsání a současně značně zvýšit spotřebu systémové paměti. Operace COW mají také tendenci fragmentovat soubory, čímž ničí kontinuální rozvržení souborů, na kterém kód systému souborů tak tvrdě pracoval. Fragmentace vadí na SSD méně než na mechanických discích, ale i v případě SSD nebude přístup k fragmentovaným souborům tak rychlý.
Takže všechna ta skvělá funkčnost obsažená v Btrfs nebude zadarmo. V mnoha situacích se administrátoři mohou rozhodnout, že režie spojená s Btrfs nevyvažuje výhody; na takových místech poslouží systémy souborů jako ext4 nebo XFS. Pro ostatní ale bude flexibilita a funkčnost nabízená Btrfs jistě dosti přitažlivá. Jakmile bude obecně přijato, že je Btrfs použitelné pro ostré nasazení, tak se asi začne objevovat na řadě systémů.
Jedna z obav, které váš redaktor LWN slyšel na chodbách během konferencí, je, že se tempo vývoje Btrfs zpomalilo. Pro ty zvědavé z vás je tu přehled počtu sad změn v kódu Btrfs v jádře, a to po přibližně ročních intervalech:
Rok | Počet sad změn | Počet vývojářů |
---|---|---|
2008 (2.6.25—29) | 913 | 42 |
2009 (2.6.30—33) | 279 | 45 |
2010 (2.6.34—37) | 193 | 33 |
2011 (2.6.38—3.2) | 610 | 67 |
2012 (3.3—8) | 773 | 63 |
2013 (3.9—13) | 671 | 68 |
Tato čísla nevykazují zpomalování vývoje; během roku 2010 došlo ke zjevnému zpomalení, ale pak se stav ustálil. Při pohledu na tato čísla je ale pořeba mít pár věcí na paměti. První je, že počáteční práce představovala přidávání nových funkcí do zbrusu nového systému souborů, zatímco práce v roce 2013 zahrnuje téměř výhradně opravy. Takže velikost změn se značně zmenšila, ale dalo by se říct, že tak to má být.
Dalším důležitým bodem je to, že příspěvků od tvůrce Btrfs Chrise Masona za poslední roky jednoznačně ubylo. Částečně kvůli tomu, že pracoval na kódu btrfs-progs v uživatelském prostoru – což je práce, která není výše zohledněna – ale je také jasné, že byl vytížen dalšími pracovními záležitostmi. Bude zajímavé sledovat, jak se věci změní po přechodu Chrise a známého přispěvatele do Btrfs Josefa Bacika do Facebooku.
Abychom to shrnuli: objem nového kódu zařazovaného do Btrfs se za poslední roky jednoznačně zmenšil, ale to je dobrá zpráva pro všechny, co by brzy rádi viděli stabilní systém souborů. Na tomto systému souborů se intenzivně pracuje a je pravděpodobné, že jak se distribuce budou více poohlížet po Btrfs, tak se pozornost vývojářů ještě zvýší.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
3.12.6
a mountuju s noatime,compress=lzo,space_cache,autodefrag,inode_cache
Na nete je plno ubuntakov co pisu ako dali svojmu notasu "druhy zivot".On jim ten dech časem dojde, až se a) zaplní disk nebo b) pakliže hodně zapisují. ZFS nemá defrag (btrfs sice ano, ale jak se píše v ostatních příspěvcích, tak to taková výhra také není).
Ten autodefrag účinkuje jen na nově zapsaná data, stará data zůstanou defragmentována. Stará data je potřeba defragmentovat pomocí btrfs-progs, jenže to má dva háčky.
První je ten, že defragmetace adresáře nedefragmentuje rekurzivně - prostě jen defragmentuje uvedený adresář (vynechá i soubory v něm !), musí se použít find a každý soubor/adresář defragmentovat zvlášť.
Druhý je, že na kernelu <3.9 defragmentace rozpojí spojení se snapshoty, takže obsazené místo dost markantně naroste. Z čehož vyplývá, že i samo použití autodefrag vylučuje vytváření snapshotů.
Takže smazat snaphosty, nové nevytvářet, defragmentovat každý soubor/adresář zvlášť (to zabere třeba i dny), nastavit autodefrag a pak se to možná bude dát používat.
Po 2 týdnech se mi to ale začalo zpomalovat ...no, jsem v této situaci po půl roce s rychlým SSDčkem ... kopíruju si takhle půlgigovej soubor přes wifinu, takže nicmoc rychlýho, asi 2 MB/s, chci si k tomu votevřít druhej terminál a nic, černo, a teprv asi po půl minutě mi naběhne shell ... koukám vedle, a průměrná rychlost kopírování je někde pod mega, i když ta síť dává ty dvě ... přepnu se zpátky, chci si v tom shellu pustit midnight, a zase asi dvacet sekund nic ... moc príma jako chápal bych, kdyby se ten systém mezitím tvářil vytíženě, ale ono nic, disk nebliká, v topu žádnej proces nevylejzá, jen se prostě čeká na Godota nebo co :-/
problem muze byt i tady toto http://www.abclinuxu.cz/clanky/jaderne-noviny-7.-11.-2013-proc-pomala-flashka-zpomali-64bitovy-stroj a ne btrfs :)
Protože existuje jedna fronta na zápis, která má na svém začátku zápisy do pomalé flešky (jiné než SSD)nemá; žádné takové zařízení není připojeno co teď?
Copy-on-write (COW) v případě Btrfs znamená, že se při zápisu změněná data zapisují na nové místo a původní data zůstávají na disku nezměněna. Díky tomu se například snadno implementují snapshoty, protože aktivní snapshot bude ukazovat na blok se změněnými daty, zatímco v archivním snapshotu zůstane odkaz na původní data.
root@schroeder:~# btrfs fi df / Data, RAID1: total=47.97GB, used=43.98GB System, RAID1: total=32.00MB, used=12.00KB Metadata, RAID1: total=2.00GB, used=1.07GBPřesnější je výpis když používáš kvóty.
stroj (DATASERVER) :~# btrfs qgroup show -pcre /home | grep 0/262 0/262 23875584 23875584 3221225472 0 1/1 ---Jenže ten ti sám o sobě -máš-li více subvolumes - taky moc neřekne, pokud si to nezkombinuješ ještě s jinými příkazy.
Bačíka, IIRCNe, opravdu je to jenom Bacik. Kolega se ho na to jednou ptal.
Problem bol este trocha zlozitejsi. Nie len, ze hlasili data ako zapisane, ked boli len v cache, ale dokonca nemali cache energeticky zalohovanu (ziadna zalozna bateria), takze pri vypadku energie nastal velmi velky problem. Mimochodom, podobne "chyby" sa hlasia dodnes a je to jeden z dovodov preco pre XFS existuje sw force shutdown (cca simulacia vypadku energie na spolahlivom ulozisku (na ulozisku, kde nenastanu problemy s cache)).
XFS si v tejto oblasti toho odtrpelo este viac. Na rozdiel od ext systemov suborov ma totiz xfs oddelene fronty pre zapis metadat a pre zapis dat, vysledkom coho byvalo po pade velke mnozstvo prazdnych suborov (nulovej dlzky). Tento "problem" nakoniec vyriesili barierami aj ked ani to povodne spravanie nebolo nejak chybne (akurat to casto nedokazali rozdychat zle napisane aplikacie).
Dalsi problem robil vyssie spominany interval pre sync dat (5s pri ext). Pri XFS je to az 60 sekund (aj to primarne kvoli VFS, ak si dobre pamatam). Mnozstvo aplikacii bolo bohuzial napisanych tak, ze ratalo so sync intervalom ako bol pri ext, z coho boli tlaky na zmenu dokonca aj pri XFS (o fsync/fdatasync ti vyvojari zvacsa asi nepoculi...).
- potvrzuji problem s DF (btrfs fi df / - mi vcera ukazoval 200MB free, smazu 4GB iso-soubor a btrfs fi df / ukazuje 12GB - a to nepouzivam kompresi)
Problem s df ma kazdy file system, aj ked pravdepodobne nie az tak zavazny.
- nedoresena (auto-)defragmentace a komprimace dat - viz vase prispevky vyse (hodila by se utilita brtfs-defrag, btrfs-compress a neco na kontrolu duplicitnosti bloku)
Neviem, co si mam o tej autodefragmentacii mysliet (hlavne by ma zaujimalo ako je implementovana), ale po skusenostiach z minulosti sa mi to moc nepaci. Autodefragmentacia mava casto negativny dopad na fragmentaciu dat (zvysuje totiz fragmentaciu volneho priestoru). Viz napr. problemy, ktore kvoli tomu malo XFS par rokov dozadu.
-jeste nedavno sem mel chut BTRFS vymenit za ext4, ale veci se asi daly do pohybu a nektere bugy zacinaji mizet - tak uvidime :)
Mozno by stalo za uvahu prave to XFS, co sa tyka vlastnosti, tak je celkom podobne btrfs (momentalne ma napada akurat, ze nema kompresiu dat a nema fs shrink).
Za vyhodu XFS oproti btrfs povazujem to, ze zachovava modularitu a nesnazi sa vsetko implementovat vlastnym sposobom (co je podla mna prevazne zbytocne, teoreticky to moze priniest zlepsenie vykonu, ale zas zvysuje pravdepodobnost chyb) -- btrfs ma cca vlastnu implementaciu lvm, raidu a pod.; XFS na to vyuziva standardne block-level lvm, md a pod.
Dalsia vyhoda je, ze XFS je na tom vykonnostne celkom schopne (vykon je porovnatelny s ext4, aj ked zalezi dost od jadra).
(ADATA SSD 511 60GB, C2D T7700, 4GB, 3.11.0-13-generic Lubuntu saucy 64bit) discard,ssd,autodefrag,inode_cache,space_cache,subvol=@)
Beh s online discard (volba discard) nie je z vykonnostneho hladiska moc odporucany. Casto je lepsie vytvorit nejaky cron job, ktory raz za X hodin zavola fstrim. Ten autodefrag by som osobne asi radsej tiez vypol (viz vyssie).
Pod problemami som, myslel prave to, ze ext4 je schopne vyhodit ENOSPC uz ked su zaplnene 2 % file systemu (staci, ze je plna ta tabulka). Je pravda, ze zapisovat dalej ide, ale len do existujucich suborov.
Pozeram, ze xfs s tymto uz problem nema a df to pocita aspon priblizne korektne. Je mozne, ze si to zle pamatam, ale este par rokov dozadu to tak nebolo a tiez tam bol problem so zaplnenim prazdnymi subormi. Dokonca pozeram, ze xfs uz pocita aj rezervovane miesto v df ako zaplnene, takze dnes uz asi neplati, ze s df maju problemy vsetky file systemy (aj ked hodnota v df sa stale neda povazovat za uplne presnu reprezentaciu volneho miesta).
Btrfs místo toho přesune přepisované bloky jinam v rámci systému souborů a zapíše nová data tam, takže starší kopie zůstane nedotčena.Nemělo být? Btrfs místo toho přesune přepisované bloky jinam v rámci systému souborů a zapíše nová data na původní místo, takže starší kopie zůstane nedotčena.
Btrfs místo toho kopíruje přepisované bloky jinam v rámci systému souborů a zapíše nová data tam, takže starší kopie zůstane nedotčena.
Hello, everything is going perfectly here and ofcourse every one is sharing data, that's truly good, keep up writing. 스포츠토토
Hi Dear, are you in fact visiting this web site regularly, if so after that you will absolutely get nice knowledge. 스포츠토토티비
Great looking web site. Assume you did a lot of your very own html coding. 토토사이트
Hi there, just wanted to tell you, I liked this article. It was inspiring. Keep on posting! 스포츠토토 슬롯머신사이트