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

10. 6. 2014 | Luboš Doležel | Jaderné noviny | 4253×

Aktuální verze jádra: 3.15-rc6. Citáty týdne: Frederic Weisbecker, Paul McKenney, Andrew Morton. Tux3 zaslán k revidování. 2038 je blíže, než se zdá.

Obsah

• Aktuální verze jádra: 3.15-rc6
• Citáty týdne: Frederic Weisbecker, Paul McKenney, Andrew Morton
• Tux3 zaslán k revidování
• 2038 je blíže, než se zdá
  • Jaderná řešení
  • Zapojení glibc

Aktuální verze jádra: 3.15-rc6

Aktuální vývojová verze jádra je 3.15-rc6 vydaná 22. května. Jelikož rc5 vyšlo o pár dní dříve a rc6 o několik dnů později, tak mezi nimi byly skoro dva týdny. Výsledná velikost ale není dvojnásobná, snad i díky tomu, že se blížíme k závěru řady rc a už by se to mělo uklidňovat, ale možná i proto, že někteří správci neposlali své žádosti o přetažení, protože věděli, že jsem offline. Ať už je to jakkoliv, nevypadá to špatně. Linus se u rc7 plánuje vrátit k obvyklému nedělnímu vydávání, tedy snad 1. června, a mělo by jít o snad poslední rc v řadě 3.15.

Stabilní vydání: verze 3.4.91 vyšla 18. května s řadou důležitých oprav, včetně jedné (známé) důležité bezpečnostné opravy. Ti, kdo mají rádi své jádro obzvlášť stabilní, se mohou uchýlit k verzi 2.6.32.62 vydané 21. května; zahrnuje opravy 39 chyb s číslem CVE.

Citáty týdne: Frederic Weisbecker, Paul McKenney, Andrew Morton

Už si mě vyhlédli draví zmrzlí žraloci, kteří nade mnou létali v kruzích po mých několika nedávných přeinženýrovaných vizích.

-- Frederic Weisbecker

Vzhledem k tomu, že jsem neslyšel příliš mnoho stížností na přílišnou jednoduchost RCU, bych se rád vyhnul změnám v masce nohz_full za běhu.

-- Paul McKenney

Vkládání věcí okolo MM do kódu čekajících front je poněkud špatné. Opravdu nevím, jak tohle vysvětlím své rodině.

-- Andrew Morton

Tux3 zaslán k revidování

Po letech vývoje a několika nepodařených startech byl systém souborů Tux3 zaslán k revidování ve snaze dostat jej v nejbližší budoucnosti do hlavní řady. Tux3 nabízí řadu slibných funkcí patřících do systémů souborů nové generace s vysokou úrovní spolehlivosti. Zaslání patche je pro Tux3 krokem kupředu, ale asi ještě nějakou dobu potrvá, než se dostane do hlavní řady.

Jediný člověk, který kód zatím kontroloval, byl Dave Chinner a nebyl zrovna nadšený. Musí se toho hodně pročistit, ale Dave má obavy hlavně kvůli různým věcem okolo správy paměti a změnám v systému souborů, které by podle něj měly být odděleny k samostatnému revidování. Jeden z hlavních mechanismů Tux3 nazvaný „forkování stránek“ nebyl na loňském Sumitu o úložištích, systémech souborů a správě paměti přijat moc dobře a vývojář Tux3 Daniel Phillips od té doby ke zlepšení moc nepřispěl.

Dave má také obavy z nedokončené povahy řady slibovaných funkcí. Před léty bylo Btrfs začleněno v nekompletním stavu a doufalo se, že to urychlí vývoj; Dave nyní říká, že to byla chyba, kterou nechce opakovat:

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

Suma sumárum to vede k nepříliš vřelému přijetí. Daniel ale chce tento kód dostat do stavu, kdy půjde kód začlenit. Pokud na to dojde, měli bychom vidět řadu menších patchů, které usnadní revidování změn specifických pro Tux3. Teprve až bude tento proces dokončen, bude čas na to uvažovat o začlenění do hlavní řady jádra.

2038 je blíže, než se zdá

Většina z čtenářů Jaderných novinek si je dobře vedoma zkázy, která nás čeká v lednu 2038, kdy datovému typu time_t používanému k ukládání časových hodnot (v podobě sekund od 1. ledna 1970) dojdou na 32bitových systémech bity. Může být překvapivé, že si vývojáři dělají čím dál větší obavy z tohoto termínu, když ještě zbývá 24 let, ale jsou pro to dobré důvody. Zdali tyto obavy povedou k brzkému řešení, se ještě uvidí; od srpna minulého roku, kdy se toto téma vynořilo naposledy, se toho moc nestalo. Nedávné debaty ale ukazují, jak by řešení mohlo vypadat.

Byly doby, kdy vývojáři doufali, že se problém vyřeší sám. Na 64bitových systémech byl typ time_t vždy definován jako 64bitová hodnota a v dohledné době mu místo nedojde. Vzhledem k tomu, že 64bitové systémy asi přebírají vládu nad světem – k přechodu dojde v nejbližších letech i na telefonech – nemohlo by nejlepším řešením být jen počkat, než 32bitové systémy zhynou a spolu s nimi i tento problém? Řešení, kdy se nemusí nic dělat, je samozřejmě lákavé.

Tento nápad má dva problémy: 1) 32bitové systémy se budou pravděpodobně vyrábět mnohem déle, než by většina lidí čekala a 2) v současnosti se nasazují 32bitové systémy, u kterých se očekává životnost delší než 24 let. 32bitové systémy budou ještě dlouho užitečné jako levné mikrokontroléry a po jejich nasazení se bude často očekávat, že poběží po mnoho let a přitom bude obtížné či nemožné je aktualizovat. Jistě už byly nasazeny systémy, které v roce 2038 budou nepříjemným překvapením.

Jaderná řešení

Proto dává smysl řešit problém dřív než, řekněme, v roce 2036. Má to ale háček: problém není tak lehké vyřešit. Alespoň pokud má člověk obavy z drobných detailů jako rozbití stávajících systémů. Protože linuxoví vývojáři na většině úrovní mají obavy o kompatibilitu, nejjednodušší řešení (jako rozbití ABI na BSD) se nepovažují za přijatelná. John Stultz v nedávné debatě naznačil několik alternativních řešení, žádné z nich ale není bez komplikací.

První přístup spočívá ve změně 32bitového ABI na 64bitovou verzi time_t (změnily by se i související datové struktury jako struct timespec a struct timeval). Staré binárky by byly podporovány přes rozhraní pro kompatibilitu, zatímco nové by normálně používaly nové ABI. Tento přístup má své výhody, například tu, že řada aplikací by šla aktualizovat jednoduše tak, že by se překompilovaly. Vzhledem k tomu, že několik variant BSD už touto cestou šlo, řada nejhorších problémů s aplikacemi již byla vyřešena. Vestavěné mikrokontroléry obvykle běží na vlastních distribucích sestavených kompletně ze zdrojových kódů; změna ABI tímto způsobem by umožnila vytvoření systémů funkčních po roce 2038 už v blízké budoucnosti s minimem obtíží.

Na druhou stranu by jádro muselo udržovat rozsáhlou vrstvu pro kompatibilitu po dlouhou dobu. Vývojáři mají navíc obavy, že se najde řada aplikací, které ukládají 32bitové hodnoty time_t do vlastních datových struktur, formátů na disku a tak dále. Řada těchto aplikací by se rozbila nečekaným způsobem a bylo by obtížné je opravit. Jsou tu také obavy kvůli režii spojené s používáním 64bitových hodnot time_t na 32bitových systémech. Většině této režie by se dalo předejít v jádře tím, že by se interně používal odlišný formát, ale aplikace by se mohly zpomalit také.

Alternativou je zkrátka definovat novou sadu systémových volání, která by od počátku používala lepší formáty času. Nové formáty by rovnou mohly vyřešit další nepříjemnosti; ne všichni mají například rádi oddělené pole pro sekundy a nanosekundy ve struct timespec. Všechna systémová volání používající staré hodnoty time_t by byla označena za zastaralá s tím, že by byla odstraněna třeba ještě před rokem 2038.

Při tomto přístupu by nedošlo v blízké době k žádnému velkému rozbití ABI a aplikace by mohly přecházet postupně. Vestavěné systémy by mohly být zkompilovány s novými systémovými voláními v docela dohledné době, zatímco desktopové systémy by bylo možné nechat třeba ještě deset let být. A byla by to příležitost k opětovnému navržení některých dávných systémových volání s ohledem na potřeby 21. století.

Zapojení glibc

Diskuze nad těmito alternativami trvala překvapivě dlouho, než Christoph Hellwig přišel se svým (nyní) zjevným návrhem: vývojáři knihovny C budou muset být v řešení tohoto problému zapojeni, tak by snad mohli být i součástí diskuze. Po celé roky byla komunikace mezi jadernou komunitou a vývojáři knihoven C (včetně GNU knihovny C – glibc) přinejlepším sporadická. Změna vedení glibc usnadnila vedení produktivních debat, ale změna starých návyků je i tak těžká. Tak jako tak je pravda, že vývojáři glibc budou muset být do hledání řešení zapojeni; dobrou zprávou je, že na toto zapojení asi dojde.

Vývojáři Glibc nejsou známi pro lásku k rozbíjení ABI – nebo nePOSIXovým rozhraním, když už jsme u toho. Proto když se vývojář glibc Joseph Myers zapojil do debaty, tón se poněkud přesunul k řešení, které by umožnilo plynulý přechod při zachování stávajících POSIXových volání a kompatibility aplikací. Plán (který byl probrán jen nahrubo a ještě se na něm bude muset hodně pracovat) vypadá přibližně následovně:

• Vytvořit nové, 64bitové verze dotčených systémových volání. Proto by například bylo gettimeofday64() vracející čas ve struct timeval64. Stávající verze těchto systémových volání by zůstaly beze změny.
• Glibc by mělo nové makro s názvem jako TIME_BITS. Pokud by platilo TIME_BITS=64 na 32bitovém systému, pak by volání gettimeofday() bylo přemapováno na gettimeofday64() v rámci knihovny. Proto by aplikace mohly volitelně přejít do nového světa definováním správné hodnoty TIME_BITS.
• Nakonec by se TIME_BITS=64 stalo výchozí hodnotou, tedy poté, co by se distribuce dodávaly v tomto režimu po nějakou dobu. I na 64bitových konfiguracích by symboly pro kompatibilitu zůstaly, aby starší binárky mohly nadále pracovat s novějšími verzemi knihovny C.

Takový přístip by měl umožnit relativně hladký přechod na systém, který bude v roce 2038 fungovat, i když by řada nepříjemných drobností zůstala. Hovořilo se o podobném přemapování volání ioctl(), ale vypadá to jako cesta do pekel vzhledem k tomu, kolik takových volání je a jak těžké by bylo je všechna vůbec najít. Vývojáři jiných knihoven C, kteří často nemají zájem udržovat natolik rozsáhlou infrastrukturu pro komaptibilitu, jako má glibc, by možná zvolili jiný přístup. A tak dále.

Navzdory dalším překážkám je existence přibližného plánu připraveného díky spolupráci mezi lidmi od jádra a glibc nadějí. Možná se podaří rozumně robustní řešení najít dříve, než to bude opravdu urgentní a než bude nasazeno příliš mnoho systémů, které musejí fungovat i v roce 2038. Máme příležitost předejít s relativně nízkými náklady panice v roce 2038; jestliže tuto příležitost využijeme, budeme jednou děkovat sami sobě.

       

Komentáře

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