Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje (diskuse)

[Andy]

oprava: ... která nás čeká v lednu 2013 ...

[Petr Tomášek]

Tady koukám, že to někomu přeteklo už teď

[Bedňa]

Nechcem byť grammar nazi, ale tých chýb je tam viac.

Nešlo by spraviť nejaké tlačítko "grammar nazi" a tam hádzať bugy aby to nezaplevelilo diskusiu?

[Josef Kufner]

Ono by možná stačilo použít kontrolu pravopisu.

[Mti.]

To se zjevne neujalo.

[Bedňa]

[Filip Jirsák]

Většina z čtenářů Jaderných novinek si je dobře vedoma zkázy, která nás čeká v lednu 2013

Vědoma a v lednu 2038…

[Pepa]

a ještě:

polání - volání

[mankind_boost]

polání -> volání

[Aleš Kapica]

Tvrzení že..

Vývoj btrfs ukázal, že přesun prototypů systémů souborů do hlavní řady jádra nevede ke stabilitě, výkonu nebo připravenosti k produkčnímu nasazení rychleji, než když zůstanou mimo jádro, dokud není většina vývoje hotová. Začlenění do hlavní řady naopak omezuje rychlost, jakou se systém souborů může dostat do kompletního stavu a připravenosti k produkčnímu nasazení.

..mi přijde přinejmenším sporné, protože o produkčním nasazení souborového systému zpravidla rozhodují mnohem konzervativnější lidé, než jsou to co je spravují.

Mám nasazeno Btrfs od té doby co je v kernelu a nikdy jsem s ním nezaznamenal problém - což bohužel nemohu říct o "produkčním" ext3. Jeho "produkční" nástupce ext4 byl začleněn ještě v horším stavu než Btrfs a během stejné doby prodělal mnohem větší kotrmelce. Přesto se bude do omrzení opakovat, že začlenění Btrfs do kernelu bylo uspěchané.

[Brundibar]

"Kapica vs kernel developeri filesystemu" 1:0. Oh, wait!

Ignorace napr. faktu zpomalovani BTRFS v case ten problem neodstrani.

[Aleš Kapica]

Sorry, ale nic takového jsem zatím nepozoroval. Nehledě na fakt, že rychlost souborového systému není v případě Btrfs zrovna ta nejpodstatnější "fičura".

[Logik]

No vidíš, já jsem po půl roce utek z BRTFS, když přes to, že na něm byla polovina volnýho místa, tak mu došlo nějaký místo na inody či co a výsledkem byl totálně rozbitej balíčkovací systém.

[Michal Kubeček]

Zajímavé, to je zrovna věc, kterou bych čekal spíš u ext2-4.

[Aleš Kapica]

Na něco podobného jsem kdysi dávno také narazil, příčina ale nebyla v Btrfs, ale v tom že příkaz df blbě počítal. Jinak ano. U Btrfs na malých testovacích diskových oddílech se může stát že se zaplácne - nebo také pokud se používají kvóty. Ovšem u velkých disků má řadu páček, které umožňují podobné situaci předcházet.

[logik]

- Stejná instalace na ext4 bez problémů, takže rozhoddně to nebyla vina df.

- A byl to relativně malý oddíl (SSD ještě rozdělené na dual-boot). A? Od filesystému čekám, že bude fungovat a ne že bude fungovat pouze za nějakých (navíc ani předem nespecifikovaných) podmínek.

-Přesně tím se liší produkční verze od betaverze: že má vychytané takovéto "mouchy". U takového produktu typu filesystém je pak vychytání těchto much dokonce nejpracnější a zároveň nejdůležitější věc. Když bude FS geniálně navrženej, že bude o polovinu rychlejší než konkurence, ale někdy zhavaruje, tak je to prostě "křáp".

[Aleš Kapica]

- Stejná instalace na ext4 bez problémů, takže rozhoddně to nebyla vina df.

- A byl to relativně malý oddíl (SSD ještě rozdělené na dual-boot). A? Od filesystému čekám, že bude fungovat a ne že bude fungovat pouze za nějakých (navíc ani předem nespecifikovaných) podmínek.

-Přesně tím se liší produkční verze od betaverze: že má vychytané takovéto "mouchy". U takového produktu typu filesystém je pak vychytání těchto much dokonce nejpracnější a zároveň nejdůležitější věc. Když bude FS geniálně navrženej, že bude o polovinu rychlejší než konkurence, ale někdy zhavaruje, tak je to prostě "křáp".

No a jsme doma. Btrfs není souborový systém pro diskové oddíly menší než 1GB. Základní režie si pak ukousne víc, než kolik zbyde na data. Naopak čím větší blokové zařízení, tím efektivnější Btrfs je.

Mimochodem KAŽDÝ souborový systém má nějakou režii některý větší a jiný menší. Dlouho jsem používal Reiserfs, protože ten měl režii bezkonkurečně nejmenší a oproti ext souborovým systémům byl i mnohem spolehlivější. Pro malé logické diskové oddíly jsem ho používal ještě loni, než ho nahradil právě Btrfs. Pro větší diskové oddíly jsem ho vyměnil za Btrfs už dříve, protože cca od 750GB výše trvala hodně dlouho kontrola po případném vynuceném restartu.

Na ext4 a ext3 mám jen ty nejhorší vzpomínky. Několikrát jsem se nechal přesvědčit a pokaždé mě vypekly. A jednou mě to stálo i nějaká data. Přitom šlo o ext4 nad RAID6 polem, ve kterém odešel pouze jeden disk. Jen pro zajímavost - Btrfs ustálo mnohem větší kejkle nad 4TB RAID6 polem z 95% zaplněným, ze kterého vypadly 2 disky kvůli vadnému řadiči, beze ztrát.

[trekker.dk]

Dlouho jsem používal Reiserfs, protože ten měl režii bezkonkurečně nejmenší a oproti ext souborovým systémům byl i mnohem spolehlivější.

Jak kde. Z mých zkušeností má reiserfs daleko větší sklony k samorozpadu (tj. žádné úmrtí disku) než ext3/ext4

[Bedňa]

Ja patrím k dlhoročným užívateľom Reiseru a za tie roky som nemal jedinú zlú skúsenosť ani na jednom stroji. Dokonca mašina ktorá kolabovala niekoľko krát denne kvôli neznámej chybe Reiser stále držal konzistenciu. Potom čo nezabralo nič som tam hodil ext3 a ten sa nenávratne rosypal po prvom páde. Napokon sa ukázala chyba v radiči, tak len toľko.

[astray]

S Reiserfs mám dobré zkušenosti, stejně jako s EXT2, EXT3, EXT4 a XFS. Btrfs jsem experimentálně používal pro lokální zálohování, ale jednoho dne systém zahlásil, že nemůže zapisovat nová data, protože je oddíl plný, i když dat tam bylo jen pár megabajtů. Další věc, se kterou mám špatné zkušenosti, je softwarový RAID. Prostě zničeho nic systém zahlásil chybu libata a bylo po datech (RAID1). Stalo se mně to dvakrát na různých strojích a od té doby dělám jen hardwarový RAID.

[Mti.]

ehm... zil sem v domeni nevedomeho laika, ze od toho je raid6, aby ustal vypadek 2 disku. To snad neni "jen" frajeria filesystemu. A v tom prvnim pripade to nebyl "jen" vypadek 1 disku, ze? To se totiz nemel fs vubec dozvedet. (kdyby to byl jen vypadek) To bych ciste na ext[234] nehazel. :-/

S reiserem mam jen 1 zkusenost v ostrem provozu ... a dobra nebyla... na dalsi sem nenasel odvahu, nasledne na tom zeleze zil ROKY stejny system (debian) nad ext3 ... mam tedy tvrdit, ze ext je super a reiser uplne spatny? Jinak mam ext[34] na veskere technice a vesmes bez potizi. Urcite nic, kde bych mohl ukazat prstem jen na fs. (a nemit pri tom vycitky svedomi)

To ze na ext3 tvra dlouho fsck...ano... skoro plne 3.6TB si vzalo skoro 2 hodiny... jenze ten stroj se resetoval tak 1x za rok... tak z toho 1x bylo s fsck.... uz se to vedelo, takze se davalo bacha, kdy se k tomu pristoupi.... no poprve to byl dobry vydrb (to se zrovna upgradovaly fw u 1TB seagatu, bo tam meli krpu... a mel sem tam 2 rady s ruznymi cd na nahrati upgrade... a mezi tim sem omylem nabootoval system... sem si pockal....tehda jen asi hodinku, bo to jeste nebylo tak plne. ... ext4 je v tomto dost pohodlnejsi. Skoro to v jednm hloda, jestli to ted kotroluje poradne, kdyz to netrva tak dlouho.

[Aleš Kapica]

ehm... zil sem v domeni nevedomeho laika, ze od toho je raid6, aby ustal vypadek 2 disku. To snad neni "jen" frajeria filesystemu.

Ano. I já. O to nemilejší překvapení to bylo. Jinak i já mám stroje kde běží ext3 nebo ext4 Ovšem ty už takhle běží nějaký pátek. Není důvod překopávat něco co funguje.

Jinak pokud bych měl FS ze kterého bych potřeboval distribuovat image disků virtualizovaných strojů, tak bych také šáhnul po jiném FS než je Btrfs. Ten se na uložení často modifikovaných velkých souborů nehodí. Zato pod NFS u diskless systémů nemá chybu!

[pavlix]

Jinak pokud bych měl FS ze kterého bych potřeboval distribuovat image disků virtualizovaných strojů, tak bych také šáhnul po jiném FS než je Btrfs. Ten se na uložení často modifikovaných velkých souborů nehodí. Zato pod NFS u diskless systémů nemá chybu!

Pokud na strojích používáš NFS, pak mě nenapadá, kdy bys vůbec potřeboval modifikovat nějaký diskový image.

[Aleš Kapica]

Nemám jen jeden stroj.

[Josef Kufner]

Proto jsem v domácím serveru posunul nastavení sítě a spuštění sshd ještě před mount ostatních disků.

[logik]

Zas tak malý oddíl to nebyl, nepamatuji si přesně, ale řádově desítky gigabajtů se standardní instalací ubuntu. Prostě něco, kde by to mělo normálně fungovat.

Pokud FS neustál výpadek disku u RAID 6, tak to není chyba FS, ten ale chyba řadiče. FS by takový výpadek vůbec neměl zaznamenat, protože řadič by měl furt dávat filesystému k dispozici funkční blokové zařízení.

[logik]

Zas tak malý oddíl to nebyl, nepamatuji si přesně, ale řádově desítky gigabajtů se standardní instalací ubuntu. Prostě něco, kde by to mělo normálně fungovat.

Pokud FS neustál výpadek dvou disků u RAID 6, tak to není chyba FS, ten ale chyba řadiče, FS by takový výpadek vůbec neměl zaznamenat, protože řadič by měl furt dávat filesystému k dispozici funkční blokové zařízení.

[Heron]

BTRFS používám (trvale) od roku 2011, (rok před tím to bylo lehké oťukávání a testování) a žádné zpomalení jsem za ty tři, čtyři roky nepozoroval. Naopak, BTRFS přináší s sebou vlastnosti, které, pokud se používají, z něj dělá jeden z nejrychlejších FS.

[Kozzi]

Prave naopak, pokud se nepouzivaji tak se jedna o docela rychly FS. Jakmile se zacne pouzivat snapshotovani tak je to po urcite dobe konec. BTRFS je zatim nepouzitelny. Ve srovnanim se ZFS je to jen hracka.

[Heron]

Byly doby, kdy jsem dělal snaphosty všech subvolumes 1x za hodinu a skladoval jsem v jednom okamžiku tisice snapshotů (více méně jen z důvodu, že to jde a jako test, co to vydrží). Dneska jsou to dva denně (a jedná se pořád o stejný FS od toho roku 2011). Opět, žádné zpomalení, naopak ty snapshoty přinesly zrychlení jedné činnosti. (Aneb jak rychle kdo umí zkopírovat 300GB dat, já mám za 1s snapshot, se kterým si můžu dělat co chci.)

[treti pylon]

Cekal bych, ze kdyz to jednomu funguje a druhemu ne, aspon nekoho z vas napadne sem napsat i distro, kernel apod. Jinak je z toho jen drbarna.

[Puk]

Netřeba se opakovat. Problémy tu jsou a nadšenci na abíčku vám data nevrátí. Red Hat moc dobře ví proč v RHEL 7 je to stále jen TP a ignorovat tvrzení jaderných vývojářů, že je to stále nehotové, může snad jen ... ignorant.

[Aleš Kapica]

Relevantnější link by nebyl? Jardík je zde vcelku profláknutá osoba, které snad nefunguje nikdy nic.

Nevím jestli sis toho všimnul, tak my co ho používáme nejsme anonymní, takže se dá hravě dohledat co, kde a jak dlouho a na čem děláme. Myslím, že do kategorie "nadšenec na ábičku", co si ucvrnkává z toho jak svižně mu linux proti widlím na netbooku šlape, nespadáme.

[Heron]

Problémy tu jsou a nadšenci na abíčku vám data nevrátí.

Data vám vrátí záloha (stejně jako u havárie hw, kterému žádný fs nezabrání).

ignorovat tvrzení jaderných vývojářů, že je to stále nehotové, může snad jen ... ignorant

Na tom se shodneme. Admin je od toho, aby to posoudil. Výsledkem je, že ono to v praxi funguje a přináší to značné zjednodušení některých operací. Já jsem s BTRFS nikdy o žádná data nepřišel, což se o některých jiných FS říct nedá, a ve chvílích, kdy selhal HW, jsem stejně vytáhl zálohu. Tedy ano, "nehotový" produkt se v praxi osvědčuje už teď.

Jinak odkazovaný blog ..., jediná informace je "pomalost". No to jsme se toho dozvěděli. O ztrátě dat ani slovo.

[lambada]

Zde pisou:

Don't use the linux filesystem btrfs on the host for the image files. It will result in low IO performance. The kvm guest may even freeze when high IO traffic is done on the guest.

Image file ne, rozumim. Ale co oddil? (nemam s btrfs zadne zkusenosti) Da se btrfs (ci presneji raid1 s checksumy) vyuzit pro hostovani oddilu pro KVM guesta?

Dik

[Heron]

Nedá, export blokového zařízení (samozřejmně, soubor je také blokové zařízení, ale souboru se chceme vyhnout) nad nějakou storage vrstvou umí (AFAIK) ZFS, BTRFS je "jen" FS.

Takže na oddíly pro KVM je nejlepší použít obyčejné LVM.

Co jsem nezkoušel je připojení btrfs s volbou nodatacow (ale to potom neumí ani checksumy), nebo atribut souboru nocow.

Jinak podle mě storage se nedá ochcat, ten výkon je daný hw a když někdo napíše low io performance, tak mi zazvoní zvonek pozor, někdo spoléhá na bůh ví jaké cachování v bůh ví čem. Ano, btrfs má poněkud pomalejší fsync, ale když to vím, tak s tím umím pracovat (nebo ten storage na to připravit).

[Aleš Kapica]

Já jsem obešel problém s blokovymi zařízeními u virtuálů tak, že jsou všechny stroje diskless. A sdílený disk s daty používá Btrfs.

[kdave]

Co jsem nezkoušel je připojení btrfs s volbou nodatacow (ale to potom neumí ani checksumy), nebo atribut souboru nocow.

Soubory s NOCOW atributem se na image virtualnich stroju daji (a maji) pouzit a vykon se vrati do normalnich mezi. Nove qemu pro to ma uz snad podporu.

Pokud jsou image oddelene v jednom adresari, tak staci nastavit NOCOW atribut na ten adresar a vsechny nove vytvorene soubory ho zdedi (presunute do toho adresare ne).

[Aleš Kapica]

Zajímavá informace..

[Vladimír Čunát]

Jo, Btrfs mi při velkém průtoku dat přes relativně zaplněný disk znatelně zpomaluje po pár měsících/letech, nejspíš kvůli fragmentaci (5400rpm HDD). Na druhou stranu, se správným nastavením a defragmentací některých částí to není tak špatný.

[Aleš Kapica]

Btrfs má několik metod, jak si s takovou situací za běhu poradit. To je to co se mi na něm líbí. Fakt ovšem je, že pokud to někdo nemá odzkoušené, tak se toho - po zkušenostech s jinými fs - bojí. Asi tak jako já zpočátku.

[kdave]

Nedovedu si moc predstavit, ze by vyvoj mimo mainline mel za nasledek rychlejsi stabilizaci. Hodnekrat jsem byl svedkem situaci, kdy vyvojarum vsechno funguje, ale dostavaji reporty od uzivatelu, ze je neco rozbite a jim se to nedari zreprodukovat.

Kde nejsou uzivatele, nejsou prirozene chyby a vsechno je stabilni. Spise jde o to, jak zdravy je cyklus chyba -> oprava -> release. Tady bych rekl, ze to u btrfs neni stale ono, coz je podle me motivace pro to tvrzeni.

Na druhou stranu je tezke nezanaset nove a nove chyby, kdyz pribyvaji featury, zvlast ty s tendencemi hrabat uplne do vseho. Obvykle to zabere 2-3 releasy nez se to vychyta, nekdy i dele, kdyz je potreba udelat rewrite.

Kdyz uz je neco v mainline, byva to o par kroku snadnejsi to zacit pouzivat nez v pripade, ze je potreba kdesi najit a stahnout zdrojaky/patche, patchovat (a doufat ze to zrovna na tuhle verzi pujde) pripadne resit byt jen trivialni konflikty. A takovehle "prkotiny" muzou odpuzovat statecne testery. Zapnout config option zvladne mnohem vic lidi.

[Aleš Kapica]

Svatá pravda. Rozumná řeč.

[ebik]

Ano, ale také je to o pár kroků snadnější používat pro někoho, kdo neví co dělá, a pak dělá filesystému negativní reklamu, protože mu to nefunguje. Také vznikne mezi laiky zmatení od které verze že už to jako funguje (zvlášť, když funkčnost je relativní pojem, vzhledem k požadavkům daného uživatele). Vývojáři ostatních FS musí při navrhovaných změnách obecných funkcí (VFS) dávat pozor aby nerozbili FS, který vlastné není stabilní (a musí to ve svých patchích řešit). Proto by také featury měli být na vývojovém stromě a do releasu jít až po řádném otestování. Nevím jak je na tom btrfs s vývojem teď, nicméně věřím, že když je výběr z několika funkčních (unixových) filesystémů, není potřeba se začleňováním dalšího FS spěchat.

[little.owl]

+1

[Michal Kubeček]

"čekajících front"? Když už se to mermomocí musí pro zmatení nepřítele překládat, proč ne aspoň "čekacích"?

[olin]

Ony ty fronty asi pořád na něco čekají a nejsou nikdy prázdné...

[MN]

Asi mi neco tak uplne nedoslo, ale proc maji tyhle zpravicky skoro 3 tydny skluz?

[ebik]

Výživná diskuze zde, odkaz by měl vést na nejrelevantnější příspěvek

http://www.abclinuxu.cz/clanky/jaderne-noviny-3.-4.-2014-diskove-bloky-vetsi-nez-4k/diskuse#12

[Marián Kyral]

Sis asi nevšiml, ale tohle není zprávička

[ebik]

Myslím, že tím tazatel nemyslel "Zprávičky" v boxu vlevo ale prostě "zprávičky" jako synonymum slova "novinky"/"noviny".

[frr]

Dnešní pýtické citáty mě donutily následovat link a přečíst si kontext. A tušil jsem správně, opět byl mnohem výživnější celý kontext, než samotný "vtipný" citát

První dva citáty jsou z jediného vlákna v mailing listu, kde se pár lidí baví o tom, jestli by nešlo "full nohz" zapínat/vypínat per CPU core, nejlépe za chodu. Ono to má vliv na RT odezvu vs. rychlost obsluhy syscallů. Na stroji, který dělá několik různých věcí (různé typy úloh), by to mohla být zajímavá vlastnost. V tom vláknu je dále zajímavé, jak se pánové občas baví "o voze a o koze" ale nakonec se zřejmě domluvili.

Třetí citát je z jedné dlouhé zprávy, která obsahuje podobných hlodů několik. Můj další kandidát na dobře mířený hlod je "Thusly does kerneldoc bitrot." Jinak je to o nějakém ladění v MM, jde o drobnou optimalizaci čehosi s ohledem na efektivitu práce s kešemi v multicore CPU...

[Ondrej 'SanTiago' Zajicek]

Taky si rypnu do prekladu - IMHO prekladat 'review' v tomto vyznamu a kontextu jako 'revidovat' je zavadejici. To uplne posouva vyznam. Lepsi preklad by byl 'recenzovat' nebo jeste lepe 'posuzovat'.

[Ondrej 'SanTiago' Zajicek]

BTW, myslel jsem, ze 'revidovat' je jeden z mnoha vyznamu 'review' a prekladatel to jen otrocky prelozil, ale zrejme tomu tak neni, 'revidovat' ma anglicky ekvivalent v 'revise', coz dela preklad 'review' na 'revidovat' jeste nepochopitelnejsim.

[niobi]

Koukam někomu time_t už pretekl v lednu 2013

[JZD]

s/přístip/přístup/