Jaderné noviny: Systém souborů Btrfs (úvod) (diskuse)

Diskuse byla administrátory uzamčena.

[jozko]

Mozno by som zvazil btrfs, no pokial tomu dobre rozumiem on pouziva standardny linux read cache, ktory je oproti ARC hlupy.

Ak by bolo mozne pouzit ARC ako standardny linux read cache, tak by btrfs davalo zmysel.

Napr. teraz si linux pamata v cache iba posledne pristupnene data, kdezto ARC si pamata posledne data ako aj najcastejsie pristupovane data a sam si nastavi pomer, aby bola co najviac efektivna. V realite potom dostanete pri 20% ARC cache z velkosti disku hitrate > 90%, co je ozajstne zrychlenie.

Ak by niekto vedel ako vymenit algoritmus cache v linuxe, nech napise. Dakujem

[Sten]

Existuje implementace LIRS pro Linux, ale nevím, jak stabilní je

[Program]

Tohle ale není věc FS, ale algoritmu správy diskové cache. Linux používá (pokud vím) běžné LRU a nevím o tom, že by tady LRU nedostačovala. LRU má jen problém s "výplachem" cache při čtení velkého souboru, ale to je stav, který nastává snad jen u desktopů (a tam by zase složitější algoritmus mohl dělat jiné zajímavosti, kvůli velmi volatilní velikosti cache).

[Heron]

No ale u BTRFS se ta cache nechová dle očekávání.

Např když čtu soubor (dostane se do cache) a potom udělám reflink (nebo rovnou snapshot), ale tu kopii neměním (na disku oba soubory zabírají stejné bloky) tak se ta kopie stejně čte z disku. Tedy ta cache funguje na úrovni souborů a nikoliv bloků.

Když takhle dělám zálohu snapshotů, kde se bezpečně vleze do cache (4GB subvolume na 32GB RAM), tak se každý další snapshot čte opět z disku přičemž těch změn je tam minimum. Čtou se opakově tytéž bloky.

[Josef Kufner]

Ten výplach nastává celkem běžně u zálohování a dokáže to docela dobře zvednout vytížení celého počítače.

[Jardík]

Btrfs jsem před měsícem kopnul na desktop. Po 2 týdnech se mi to ale začalo zpomalovat a musel jsem to přeformátovat. Teď už to zlobí znovu, možná nějaký mount volby, či komprese a v kombinaci s ní fragmentace? Zkusil jsem i připojit s autodefrag volbou, nepomáhá. Doufal jsem, že díky kompresi se mi zrychlí čtení z disku (který je v laptopu pomalý), hlavně programy, knihovny a konfiguráky. Zrychlení jsem však nezpozoroval, a teď se to navíc spíše zpomaluje. Subvolumes se mi taky líbí, můži si nainstalovat třeba kolik chcu linuxů na jeden oddíl a sdílí volné místo a nemusím řešit že tom dám tolik a tolik místa. Ale asi to brzo přeformátuju zpět na ext4, kvůli tomu zpomalování Mám to s kernelem 3.12.6 a mountuju s noatime,compress=lzo,space_cache,autodefrag,inode_cache

[jozko]

sa cudujem, lebo so ZFSonlinux maju ludia vacsinou zrychlenie. Na nete je plno ubuntakov co pisu ako dali svojmu notasu "druhy zivot". Len je to komplikovane to mat na boote a taktiez pri aktualizaciach to robi sarapatu. Taktiez treba 64bit CPU atd atd atd. Zatial vela obmedzeni, ale stabilne a rychle

[Conscript89]

Filesystem na /boot nema zadny vliv na rychlost pri bezne praci, vzdyt na /boot se pristupuje jen pri bootovani, nebo updatu kernelu (pripadne i bootloaderu). Zrovna /boot bych dal na nejaky "generacemi overeny" FS.

[Ladislav Jech]

Presne. /boot na ext2, ext3.. root a zbytek uz na cokoli, s cim si chci prave hrat.

[Vykook]

Ti nevím, já třeba právě snapshotuju / (nemam samostatnej /boot, jinak bych to dělal jen na něm) než instaluju nový jádro. Je to pro mě nejtriviálnější řešení... Já jsem se vlastně naučil snapshotovat skoro pořád a jako bonus od té doby co to dělám, tak se nic nesesypalo :D

[Conscript89]

Nevim co pouzivas za distro, ale treba RH based distribuce zachovavaji (tusim) 2 predchozi kernely coz je jeste trivialnejsi reseni :)

[Aleš Kapica]

Člověče nic proti, ale ty jsi evidentně dosud nepochopil, co to vlastně je to snapshotování. Nainstalovaná starší jádra automaticky neodstraňuje snad žádná distribuce, ale pokud si něco důležitého při aktualizaci převalíš, tak můžeš být bez snapshotu v pytli bez ohledu na to kolik jich máš.

[Conscript89]

Ja tu celou dobu mluvim jen o /boot. Snapshoty samozrejme vim k cemu jsou. Jasne, ted uz jednu vyhodu vidim, moznost vratit se k libovolnymu jadru nainstalovanymu v minulosti (coz ovsem vyzaduje hodne mista pro takovy /boot), nevim ale porad jaky prospech todle muze mit.

[Aleš Kapica]

Kupodivu ani ne. Snapshotování je z hlediska místa výrazně šetrnější než klasické zálohy.

[Vykook]

FreeBSD, ale to je v tomto případě vcelku jedno. Taky si nechává poslední jádro.

[JanM]

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í).

[sid]

a urobil si kompresiu vsetkych suborov? nestaci to pridat do mount, tam to sposobi len to, ze nove subory budu komprimovane. Teda ak si ten fs od zaciatku nevytvoril s podporou kompresie. Este by si teoreticky mohol zapnut skinny extents (btrfstune -x)

[Aleš Kapica]

Komprese naopak zpomaluje. Je dobrá tehdy, pokud chceš lépe využívat místo, Btrfs však má o něco větší režii a zpomalování může způsobovat více faktorů.

[sid]

zpomaluje? samozrejme to asi je podmienene tym ci je to SSD alebo harddisk ale ked je nieco malo menene tak ak musim nacitat 2x menej dat tak by som to mal poznat,ci je to zly predpoklad? Moderne processory robia dekompresiu celkom rychlo.

[Aleš Kapica]

Pokud neskončíš, tak jako přispěvatel o kus níže na druhém odstavci, tak o tom jak je to s kompresí u Btrfs píšu v naší wiki.

[Sid]

ano, precital som si to, ale stale tam nie je ziadna podpora pre vase tvrdenie, ze kompresia ked sa prevazne citaju data spomaluje.

[Sten]

A týká se to ZLIB nebo LZO? U ZLIB mám zkušenost, že to hodně vytěžovalo CPU a na slabších počítačích na to nebylo dost výkonu, s LZO tam ale problém nebyl.

[tom]

Meril jste to? Ja ano. Na jakemkoliv modernim pocitaci nezpomaluje - naopak. Proste mensi objem zapisovanych dat zpusobi vetsi usporu casu, nez kolik se ho zabere tou komprimaci.

[Jardík]

Já ani tak nezapnul kompresi kvůli rychlejšímu zapisování, jako spíš kvůli rychlejšímu čtení. Ale jak říkám, nepozoruji zrychlení a ještě se to časem strašně zpomaluje. Asi se vrátím na ext4.

[luky]

Dejte si /usr do squashfs a udelejte zapis pres aufs (a nebo jiny vrstvici FS) a cas od casu pregenerujte squashfs image.

[pepe_]

Návod nebude ?

[David Šmíd]

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.

Wiki

 

---

[Jardík]

Kompresu jsem zapnul s prvním připojením před překopírováním starého /, vše by tedy mělo být zkomprimované. Ten autodefrag ale zapnutý nebyl, snapshoty jsem nepoužil, měl jsem tam akorát 1 extra subvolume pro gentoo, to jsem ale nedávno smazal, protože nanaplnilo mé očekávání, že si nainstaluju pouze to co chci, bez blbých závislostí, např. gtk3 tahalo jako závislost gtk2.

[anonym]

ona defragmentace v CoW (vcetne nerozbijeni snapshotu) neni nic snadneho, coz je take duvod proc ZFS ji jeste nema

uz dlouho sem se chtel podivat jak btrfs resi tu defragmentaci, muj odhad je ze se prepne do specialniho modu kdy se nechova jako CoW, a potom se zase chovat zacne (alternativa k tomu by byla ze kdyz najde dost fragmentovany soubor tak ho cely oznaci za "zmeneny" a zkopiruje na nove misto, ale to zase nehraje do snapshotu)

[kavol]

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 :-/

[ebik]

Nejspis ti nefunguje TRIM tak jak ma, pouzivas ext4 s mount optionem 'discard'? Nemas mezi ssd a fs jeste nejake dalsi vrstvy, nakonfigurovane tak, ze TRIM neprojde?

Ja jsem napriklad kdysi na SSD s funkcnim TRIM neco omylem smazal (neco vetsiho), a zkusil obnovit pomoci extundelete. Velikosti byly spravne, ale soubory obsahovaly nuly (protoze TRIM spravne prosel, a firmware toho SSD implementoval dotaz do TRIMnute oblasti tak, ze vratil blok nul), cimz jsem si nechtene experimentalne overil, ze ten TRIM opravdu funguje.

For s SSD je v tom, ze diky wear-levelingu je rychlost SSD neprimo umerna poctu bloku fyzicke pameti SSD o kterych to SSD vi, ze jsou volne. TRIM je zpusob jak tomu SSD rict, ze jsi neco smazal, jinak si po case bude myslet, ze cela partitiona je pouzivana, i kdyz budes mit zabrano jen treba 20%.

Proto nekteri vyrobci prodavaji nasobky 30GB misto nasobku 32GB. Ty 2GB maji rezervovane na wear-leveling. Jini vyrobci zase montuji misto osmi pametovych cipu devet. SSD vetsinou zapisuji po mensich blocich (4kB?) ale mazou po vetsich blocich (512kB?). A prepsani casti fyzicke pameti v SSD je vzdy nejprve jeji smazani. Takze pokud mu dochazi misto, nebo pokud ma spatne implementovany wear-leveling, tak na to aby prepsal jeden 4kb blok, musi nejprve ostatni bloky v tom 512kb bloku presunot nekam jinam, aby ho mohl cely promazat, coz vede k znacne snizenym rychlostem zapisu.

[ebik]

Jen ještě dodám že http://www.google.com/search?q=test+trim+ext4 mi vrátí spoustu návodů, jak ověřit, zda TRIM funguje.

[vodic]

Tak přesně tenhle problém mám také na OpenSUSE 12.3 i 13.1 s SSD OCZ Agility s Btrfs (zaplněný sotva z půlky). Když jsem se opovážil na pozadí updatovat systém, když děti koukaly na pohádku, tak to vycházelo tak 10s video, 30s printscreen. A TRIM dělám pravidelně, takže tím to není. V žádném logu nic není. Prostě jen systém na něco čeká a vůbec mu to není divné.

[ebik]

Trim se ma delat predevsim sam, nebo je to u BTRFS jinak?

[vodic]

Také si myslím, že by mělo, ale když trim zavolám ručně, tak to chvíli trvá, takže si nejsem úplně jistý, jestli se to volá pravidelně automaticky. Žádné speciální mount volby ve fstab nemám.

[mimi.vx]

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 :)

[vodic]

No sice 64b systém mám, ale SSD, které zvládá bez problémů zapisovat stovky MB/s, se mi nezdá být označitelné jako "pomalá flashka". Takže se obávám, že tady psa nevyhrabu.

[Jakub Lucký]

doporučuji si před komentováním ten článek přečíst...

[vodic]

To jsem samozřejmě udělal. Dokonce ještě před tím, než na něj bylo upozorněno. Stále nechápu, jak by mohla nastat situace, kdy se může třeba i minuty čekat na zapsání špinavé stránky, když na mém systému tohle nemůže nastat, protože špinavá stránka se zapíše díky rychlosti SSD prakticky hned.

[Jakub Lucký]

Protože existuje jedna fronta na zápis, která má na svém začátku zápisy do pomalé flešky (jiné než SSD)

[kavol]

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ď?

[Jakub Lucký]

Tak to není ten případ, o kterém mluví předřečník výše...

[kavol]

a to prosím který?

v tomto konkrétním vlákně si na zpomalení stěžují tři lidé, jardík, vodic a já ... a ani jeden z nás nic o jiné pomalé flashce nepíše, takže mi není jasné, čí (a jaký tedy) případ by to měl být (nebo víš o našem hardware něco víc než my?)

[Jakub Lucký]

Máte pravdu. Prošel jsem si to, zmátly mne zmínky o flešce v #66

[vodic]

Tímto potvrzuji, že opravdu v systému žádnou flashku (mimo SSD) připojenou nemám :)

[Petr Ježek]

Ach jo, na Phoronixu probíhají testy btrfs dva roky a stále je nejpomalejší. Proč asi? Zatímco COW probíhá prakticky v reálném čase, žurnálování nikoli. Dokud se nevyřeší úklid po COW na úroveň nezpomalující podstatně průběžné operace s daty, nejde o žádný pokrok a výhody COW jsou placené prodloužením času práce, což je zcela nepřijatelné. Komprimace ostatně také není cesta z houští, opět jde o náklady komprimace časové i z hlediska nároků na zdroje. Zkrátka nápad dobrý, ale provedení doposud nepříliš použitelné tam, kde je omezení kapacitní a zdrojové, tj. současně a především finanční. Hádejte, proč Oracel pracuje s tak vysokými maržemi...

[archen]

No, na starsim jadru v Gentoo mam uplne stejnou zkusenost, dal jsem si do crona automatickou defreagmentaci na celej file system, resp. vsechny adresare: find / -xdev -type d -print -exec btrfs filesystem defragment '{}' \;

viz ArchWiki hutny soubor informaci o BTRFS: https://wiki.archlinux.org/index.php/Btrfs

Nicmene i v tomhle gardu se system zpomalil zhruba o 20-30 procent, prolezl jsem dalsi internetove zdroje souvisejici s tuningem btrfs a zkousel vse aplikovat. Nicmene nominalniho vykonu jsem jiz za zadnou cenu nedosahl.

Dalsi zajimavy odkaz: http://www.phoronix.com/scan.php?page=article&item=linux_btrfs_311&num=1

[Bedňa]

Je dobrý na zálohovacie servery vďaka snapshots, na desktop je ideálna náhrada ReiserFS, alebo Reiser4. To padneš do kolien z tej rýchlosti, hlavne na starom železe.

[Aleš Kapica]

K Btrfs na wiki DCE FEL ČVUT.

[Filip Jirsák]

Škoda toho zmateného vysvětlení COW v druhém odstavci. Myslím, že v článku se najde inspirace pro opravu na té wiki…

[Aleš Kapica]

Přiznávám že ten druhý odstavec je poněkud zmatený, z hlediska zpracování manuálu má však pro mne prioritu zbývajících 99% obsahu té stránky. A to tam toho ještě dost není, protože část věnovanou kvótám mám zatím ve formě poznámek.

[Filip Jirsák]

Chápu. Ale pokud bych na tu stránku narazil jako čtenář náhodou, asi bych dál nečetl.

Jako nepřihlášený to editovat nemohu, ale co to napsat třeba takhle?

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.

[Aleš Kapica]

O účet není problém požádat. Opruz s formulářem je tam jen kvůli robotům.

[R]

Uz sa da zistit, kolko je vo filesysteme volneho miesta?

[Aleš Kapica]

Dávno, akorát mi není jasné k čemu ti to je. Z mého pohledu tak maximálně pro hrubou orientaci.

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.07GB

Př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.

[Vladimír Čunát]

Před pár dny mi to ukazovalo ~28/60 GB volno a zároveň jsem dostával out-of-space... trošku mi to leze do extrému (3.12 rw, noatime, nodiratime, compress=zlib, noacl, space_cache, autodefrag, inode_cache).

[R]

Potrebujem to napriklad preto, aby som vedel, ze "aptitude upgrade" sa nerozoserie v strede instalacie, lebo doslo miesto.

[kavol]

Problémy jsou opravovány

vidím ...

známého přispěvatele do Btrfs Josefa Bacika

Bačíka, IIRC

[Conscript89]

Tak todle je trosku nefer. Opravdu sis myslel ze by takovy bug bez jakychkoliv dat (vidim jen ze se ptas kam je dat) by nekdo zvladl kouzelne opravit pres vanoce?

[kavol]

nemyslel; myslel jsem si ale, že když na tom máme několik placených vývojářů, tak by se aspoň někdo mohl za ten měsíc ozvat, a ne jako když já řeším blbosti s qmmp apod. někde mezi kolekcema, tzdatama, co musí vyjít právě teď hned, RHEL7 deadlinama, atd., ve volném čase při flejmováním na ábíčku ... no nic, dotáhnu ten image na testovací mašinu s RHEL7 a uvidíme, na RHEL7 bugy se reagovat musí

[michich]

Bačíka, IIRC

Ne, opravdu je to jenom Bacik. Kolega se ho na to jednou ptal.

[Já]

f(Bacik) < f(Bačík)

f = ? :)

[xyz]

f = pocet interpunkcnych znamienok :)

[kavol]

bych se skoro vsadil, že na PaP jsem to viděl s diakritikou ... no tak nic, ď. za info

[TM]

V klasickém file systému ale přece v inodě nejsou jen přímé odkazy na bloky - to platí jen pro menší soubory. Používá se několik úrovní - přímý odkaz na blok souboru, odkaz na blok s přímými odkazy, .... atd.

[Sten]

Máte sice pravdu, ale z hlediska zabraného místa je jedno, jestli je to přímo v tabulce/stromu inodů nebo v jiném bloku odkazovaném z inodu, pořád to bude n ukazatelů na n bloků.

[TM]

To ano. Netvrdím, že techniky používané v novějších filesystémech nemají proti takovému přístupu výhody. Jen mně připadalo, že autor má trochu pomýlenou představu o tom, co je v inodách.
Kdysi mně na jednom fóru administrátor jedné velké a velice známé české Internetové firmy(později tam snad dokonce šéfoval technickému oddělení) tvrdil, že v inodě je i jméno souboru. Trochu se mně to vybavilo

[kapo]

To ano, ale podstata problému je v tom, že jsou to odkazy na bloky a ne extenty - tj. extent s konstantní velikosti (4kB?). Kolik takových odkazů potřebujete na třeba DVD image (4GB) ? Toto je to, co špatně škáluje. I když budete mít soubor uložen souvisle, stejně budete muset přečíst hromadu bloků jen kvůli odkazům. V případě extentů načtete jen jednu adresu + velikost a čtete už jen data.

[Jura Jurátor]

Napadlo mě, že když se v článku píše o tom, že Btfrs je odolnější oproti náhlým výpadkům. Tak jestli to nepřináší větší odolnost OS LINUXu proti výpadkům napájení, či hrubšímu zacházení některých uživatelů spočívajícím ve vypnutí zdroje - takzvaně "natvrdo" ?

[Program]

Tak samozřejmě, ale jde jen o konzistenci dat. Data v zápisové cache prostě na disku nejsou a když mrsknete bookem o zem, tak Vám to taky FS nezachrání.

[Jura Jurátor]

Děkuji za odpověď.

Jen reviduji poznatek ze školení, kde bylo uváděno, že na nekorektní vypnutí je Linux extrémě náchylný. (I když v praxi, moje maminka, když jí naskočil v dual bootu OpenSUSE a nevěděla si s ním rady, tak prostě vypnula proud a butovala znova. Tohle udělala snad 100x a OpenSuse pořád dodnes nabíhá. Tak jestli to není jen jakýsi hoax)

J.

[Heron]

Nebylo to školení od MS?

Neříkám, že by se to tak mělo dělat, to určitě ne, ale dobře napsaná aplikace (například db) na normálním fs a normálním hw (který nelže o zápisech) nemá s nekorektním vypnutím žádný problém. S příchodem virtualizace se dokonce běžně dělají snapshoty virtuálky za jejího plného běhu a z těchto snapshotů se potom dělají kopie. Nikdy nebyl s tímto žádný problém a přitom z hlediska toho os je to stejně jako kdyby někdo zmáčkl reset. Konkrétně ta db bude ve poslední dokončené transakce a každý slušný fs bude ve stavu posledního syncu (ext3 každých 5s, btrfs by default 30s apod, dá se vynutit aplikací kdykoliv).

[ivan]

Jednu dobu s tim mel problemy XFS (ale i jine filesystemy), pak se ukazalo, ze nektere hardisky lzou a posilaji potvrzeni do OS uz kdyz primou data do cache a ne kdyz jsou data skutecne zapsana. Tahle chyba se projevovala hlavne na XFS a proto se problem hledal tam.

[jas]

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...).

[ebik]

Dokonce jeden vývojář linuxu (Pavel Machek) v době kdy přišla ext3 a jakž takž se stabilizovala, tak v rámci testování vypínal svůj počítač zásadně "natvrdo". Když mi to říkal tak to bylo již více než půl roku co to takhle dělal a nezaznamenal žádný problém.

[Radek]

V úvodu se píše, že „než bude Btrfs připravené, tak si asi řada lidí bude myslet, že je už úplně zastaralé.“

Jaké jsou moderní „trendy“, které se do návrhu Btrfs nedostaly?

[Sten]

Btrfs ještě není připravené, takže všechny ty, které přijdou v následujících několika letech

[Heron]

A ty spadnou z nebe už kompletně připravené?

[Sten]

Ne, ale budou moderní. Btrfs oproti nim už bude zastaralé

[GeoRW]

podla mna brtfs bude pripravene az vtedy ked vyjde stabilna verzia GNU Hurd, t.j. nikdy

[vadimo]

Ja som dal btrfs mojej mame na stary laptop s pentiom 4. Skapal tam hdd, vymenil som za cf kartu. je tam lzo kompresia. cca rok bez problemov. ona tomu aj tak moc nezavari.

[B.E.]

nemám moc dobré zkušenosti ale casem se to zlepsuje:
- upgrade balíků trvá mnohonásobně déle a potvrzuji ze system byl nedavno "zabitej" (viz např. tento bug) https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/607632

- potvrzuji slova KAVOLa (obcas byl system nepouzitelny a to se kopiroval jen soubor a nikde nic pretizeneho neni)

- 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)

- nedoresena (auto-)defragmentace a komprimace dat - viz vase prispevky vyse (hodila by se utilita brtfs-defrag, btrfs-compress a neco na kontrolu duplicitnosti bloku)

- offline/online FSCK a jeste nedavno mi zlobil i FSCK pri startu - proste neproblehnul - musel jsem nabootovat z knoppixe a FS opravit rucne :( (to nemluvim o volbe super-blocku - ktera predrokem nebyla nikde uvedena - vyvojari asi zacali konecne psat dokumentaci

- obcasna haseni v syslogu o BTRFS - unlinked 6 orphans a device fsid xxx devid 1 transid yyy /dev/sda3 - co to je - mam se bat mrtveho FS:)?

Nemyslim si, ze je vadne SSD nebo radic - ve W7 na druhe partisne jede vse OK
-proste si myslim, ze jsou nektere funkce nedoladene + chybi uzivatelska podpora/rozhrani, ale FS ma velkou budoucnost - libi se mi

-jeste nedavno sem mel chut BTRFS vymenit za ext4, ale veci se asi daly do pohybu a nektere bugy zacinaji mizet - tak uvidime :)


(ADATA SSD 511 60GB, C2D T7700, 4GB, 3.11.0-13-generic Lubuntu saucy 64bit) discard,ssd,autodefrag,inode_cache,space_cache,subvol=@)

[jas]

- 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).

[ebik]

To není úplně pravda. Dnešní df hlásí hodnoty used free a total. Nikde není ale psáno, že used + free = total, a také na extX je used+free menší než total. Když extX hlásí, že je tam X bytes free a vy máte soubor nulové délky, a nikdo jiný zrovna nemá otevřeno nic pro zápis (ani přes mmap), tak do toho souboru téměř tolik bytů můžete zapsat (možná dokonce přesně tolik). To je vyváženo tím, že čistý naformátovaný extX fs má seznam bloků (něco jako MFT u FAT), což běžně dělá asi 2% kapacity, které jsou zabrané i kdybych zapsal na filesystém jediný soubor od začátku až do konce. FAT to má podobně, akorát některé implementace FAT počítají s tím, že mají aktuální velikost volného místa "nakešovanou" a uloženou na disk a od tohoto čísla dál odečítají nově zabrané bloky. Tak se může stát, že vinou nějaké chyby (vypnutí el. proudu) to číslo neodpovídá realitě, a dokud člověk filesystém neopraví, tak to furt reportuje špatně. Teprve modernější FS nepředalokovávají tabulku bloků, protože mají pokročilejší struktury na zaznamenání mapování umístění částí souboru. U takových FS (pokud jsou správně naimplementovány) by free mělo odpovídat nejvýše velikosti zapsaného souboru + metadat/žurnálu potřebného k zapsání toho souboru, takže by se prakticky u nemělo stát, že nelze zapsat soubor menší než polovina místa reportovaného ve free. Nicméně zápisem ve smyslu zabrání dalšího místa, zde myslím zapisování do řídkých souborů, přepisování souborů linkujících stejné bloky mechanismem COW, a tak podobně. Pokud systém reportuje v df 1GB volného místa, a zápis (pod rootem - tedy bez mechanismu reserved blocks a podobných zvláštoností) vrací No space left on device, tak je něco špatně v implementaci.

[jas]

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).

[Gilhad]

df -i udava kolik je volnych inodu - cili tam to zaplneni prazdnymi soubory videt je

[Honza Jaroš]

No mně na Gentoo s jádrem 3.10.25 ukazuje df celkem odpovídající i údaje na btrfs, jen to chce nejdřív syncnout filesystem.

[jadd]

Zajímavé čtení, jen jsem se pozastavil nad větou

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.
nebo

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.