Btrfs, lepší systém souborů – teorie (diskuse)

[branchman]

Viem, ze je to clanok o Btrfs, ale toto sa mi nezda:

(jen ext3 a ext4 umožňují také žurnálování dat, čímž ale efektivně snižují rychlost zápisu na systém souborů na polovinu – data jsou zapsána nejprve do žurnálu a až po té do bloků daného souboru).

Nebolo by efektivnejsie zurnal "posuvat po disku", vzdy do neho zapisat a potom len odkazat na tento blok z inode a premiestnit zurnal o trochu dalej? Nebol by tam stale rovnaky problem pri prepise dat zo zurnalu do blokov?

Takyto ext3 by mi z principu nemohol dovolit vytvorit subor vacsi ako polovica disku (druha polovica by musela byt zurnal), co sa mi nezda - v praxi som to pred chvilou skusal na

dd if=/dev/zero of=testfile bs=1M count=100
mkfs.ext3 testfile
sudo mount -o loop testfile /mnt/test
dd if=/dev/zero of=/mnt/test/testfile bs=1M count=99

a prebehlo to v pohode

[qazasd]

jen ext3 a ext4 umožňují také žurnálování dat

mount -o loop -o data=journal testfile /mnt/test
dd if=/dev/zero of=/mnt/test/testfile bs=1M count=99
dd: zápis „/mnt/test/testfile“: Na zařízení není volné místo

[kapo]

Rika se tomu Wandering logs a je to pouzito napr. v ReiserFS, viz stary clanek: http://lwn.net/Articles/41652/

[Sten]

Nebolo by efektivnejsie zurnal "posuvat po disku", vzdy do neho zapisat a potom len odkazat na tento blok z inode a premiestnit zurnal o trochu dalej?

Čili implementovat COW? Samozřejmě by to efektivnější bylo, kdyby ext3/4 podporovalo posuvný žurnál.

Takyto ext3 by mi z principu nemohol dovolit vytvorit subor vacsi ako polovica disku (druha polovica by musela byt zurnal), co sa mi nezda

ext3/4 automaticky commituje žurnál jednou za čas (standardně je to pět sekund), případně pokud se žurnál naplní. To, že data žurnál chrání, tedy platí jenom omezeně (ale btrfs to při nedostatku místa dělá IMO stejně).

[Sten]

Tak ne, ext3/4/btrfs žurnál u probíhajícího zápisu nečistí, ale aplikace, kterou jsem to zkoušel, při ENOSPC zavolá fsync a zkusí to znovu.

[lertimir]

Hlavní problém s btrfs je asi chybějící fsck. Chris vypuštění pořád odkládá. Mělo být na LinuxCon Europe a nic.

[CET]

Hlavní problém s btrfs je asi chybějící fsck. Chris vypuštění pořád odkládá. Mělo být na LinuxCon Europe a nic.

Tak pokud by opravdu nebylo mozne btrfs poskodit, tak bych po fsck neprahnul. Jestli ale nektery zarizeni po FLUSH data nezapisou, tak je to spis problem HW nez btrfs a takovej HW bych nechtel ani s fsck.btrfs, protoze abych pri kazdym vypadku elektriky musel resit fsck a pak slysel keci, ze btrfs neni nijak lepsi, protoze po vypadku elektriky musi opravovat, to opravdu ne.

Btrfs (podle toho clanku) vypada skvele a jenom na spatnym HW muze mit problemy. Ale spatnej HW bych nechtel pouzivat ani s ext3 nebo reiserfs.

Jinak by me zajimalo takovyhle detailnejsi srovnani se ZFS:) ZFS mi pripada hodne podobny jako btrfs, ale rad bych porovnani v tech technictejsich detailech, ktere clanek zminuje. Bude porovnani?

[Petr]

Njn, jenže jak poznáte tento špatný hardware když ho budete kupovat?

[kolcon]

... pripadne pokud je to primountovane bez barrier, tak je to raz dva...

[Whyki]

Btrfs jsem v drivejsich verzich chvili pouzival a poskodit jej je velmi jednoduche. Napisu 2 zpusoby kterymi jsem to zvladnul behem 3 dni pouzivani.

1. v notebooku vam dojde batterie, system se poskodil a zadna oprava v te dobe nebyla mozna

2. Start systemu s jinym jadrem v okamziku kdy jste provedli hibernaci do swap.

Obcas se zkratka neco stane a prijit o vsechny data je vec kterou neskousnu. I zminovany reiserFs ktery se tezko opravoval umoznoval zotaveni v naproste vetsine pripadu.

[Sten]

Reiserfs byl donedávna to nejhorší, z čeho jsem kdy obnovoval data, při rozpadnutí RAIDu přesunul 90 % souborů do lost+found (bez jména). xfs přesunul asi 5 % (plus asi 1 ‰ zmizelo). ext3 rozpadnutí RAIDu zvládlo bez chyb, to mě hodně překvapilo.

Tedy btrfs je ještě horší, tam to řeší rovnou kernel panic.

[Tomáš Bžatek]

Zajimave, ja mel prave s reiserfs 3.6 nejvetsi uspech pri obnovovani poskozene partition, treba pri prepsani 20% zacatku nulama nebo pri rozpadnutem mirroru raidu, kdy prichazely nahodne data z underlying device.

[Luboš Doležel (Doli)]

Já jsem jednou u Reiseru natvrdo vypnul počítač a to bylo naposledy, co jsem se k těm datům dostal. fsck označoval souborový systém jako v pořádku, ale mount vždycky selhal s výpisem nějakého assertu do dmesg.

[Max]

Hmm, u nás se PC vypínal natvrdo jak na běžícím pásu. O dost výpadků se postaral psův zadek (nebo náhodná návštěvník zavadil nohou), který se opřel o hw reset. Vždy ok, takže zajímavé :).
Zdar Max

[Luboš Doležel (Doli)]

Jo, já taky neměl nikdy problém. Až jednou...

[Bedňa]

Na to pomáha reiserfsck --rebuild-tree.

[Luboš Doležel (Doli)]

To už jsem nechtěl podstupovat, cenná data tam nebyla. Ale principiálně mi vadilo, že fsck.reiserfs po dlouho trvající kontrole poví, že je všechno OK, a přitom to nejde připojit ani R/O.

[Bedňa]

To som osobne ešte nezažil, že by nešiel pripojiť, nemohlo byť skôr niečo s partíciou, než s FS?

[Luboš Doležel (Doli)]

S tou se nic nedělalo a FSCK opravdu všechno prošel a bylo to podle něj OK. Byl to skutečně assert z kódu pro reiserfs. Od té doby jsem ho nikdy nikam nedal.

[Sten]

To jsem se dočetl a následně zkusil taky. Ano, data to zachránilo, ale všechna byla v lost+found a bez jmen souborů.

[Bedňa]

To sa mi nikdy nestalo.

[Semo]

Pred rokmi som pisal zvukovy nahravac pracujuci s usb2serial prevodnikom, na ktory bol v jadre zabugovany driver a obcas si sahol na NULL pointer pod. nasledkom coho casto tuhlo jadro a natvrdo som resetoval. fsck.ext3 si s tym vzdy poradilo az do momentu, ked sa tvarilo, ze si poradilo (hladilo, ze FS je opraveny), ale pomiesalo bloky roznych suborov dohromady. A akurat sa mu to podarilo na zdrojakoch a skompilovanych binarkach toho, co som prave pisal. To ma z ext3 vyliecilo a odvtedy pouzivam vsade reiserfs a ten uz podobne veci prezil absolutne vzdy. A ked som raz zmazal strasne kvantum uzivatelskych dat vinou blbej klavesnice, tak vysledok po --rebuild-tree ma sice stal asi 6h prace, ale 99% som obnovil.

Takze uz mna je ext3 pouzivane v sucte znacne mensiu dobu ako reiserfs a napriek tomu mam s nim viac blbych zazitkov.

[8an]

Už existuje alespoň nástroj restore, který dokáže ze zbořeného filesystému obnovit data (soubory včetně adresářové struktury, ale bez symlinků a práv souborů, takže systém je potřeba přeinstalovat, ale o svoje data nepřijdete).

[Bedňa]

I zminovany reiserFs ktery se tezko opravoval umoznoval zotaveni v naproste vetsine pripadu.

Prepáč mi, ale je to totálna blbosť, na ReiserFS som prešiel aj preto že, práve pri HW chybách má najlepšie schopnosti sa zotaviť, už som tu aj o tom písal, Ext mi dva krát na tom istom HW skapal bez akejkoľvek možnosti obnovy. Na Btrfs sa teším, ale na Reiser budem v dobrom spomínať naveky. Nebiť toho, že sa Ext dostal do Kernelu, nikdy by ten zmätok v konkurencií nemal šancu. No a keď prirovnám dobu aktívneho vývoja ReiserFS, aký FS na Linuxe sa mu vyrovnal? Teraz po rokoch ho doťahujú, ale Ext ani za sto rokov, aj keď sú už dnes rýchle procesory a disky, skús si vylistovať adresár bin na Reiseri a Ext, stále má na vrch tak tri krát, prv to bývalo 5krát a viac.

[Whyki]

Mluvim pouze z vlastni zkusenosti, nemusi jit o pravidlo.

Moje zkusenotst byla takova ze rozbit ReiserFs bylo daleko jednodussi nez ext3. A opravy byli technicky narocnejsi a casto jsem prisel o cast dat.

[Bedňa]

Mne sa to ešte nepodarilo za niekoľko rokov, ale počul som, že možné to je :)

[Heron]

Je to tak.

Pokud diskové zařízení lže o provedeném zápisu, tak je to problém HW. S tím se žadný FS neumí vyrovnat a u Btrfs je to ještě znásobeno použitím více diskových zařízení. Případná ztráta dat jde tedy plně na vruh vadnému HW.

Srovnání Btrfs a ZFS neplánuji, se ZFS nemám žádné zkušenosti.

[Program]

Tenhle přístup miluju. To je problém HW a basta, aneb tupost některých lidí nezná meze...

[Zopper]

Jenže tady to tak opravdu je - FS nemá jinou možnost, než předpokládat, že k FLUSH došlo. Samozřejmě, byla by tu ještě možnost čekat třeba deset vteřin, ale takové řešení není reálně použitelné...

S falešným flsuh si neporadí žádný FS. Příklad: na disku by byl flush skutečně dokončen až deset sekund po ohlášení. Já ten disk mám zapojený jako externí, dám umount a jakmile systém zahlásí odpojení, vytáhnu ho - flush se tedy neprovedl a ať tam už byl jakýkoliv FS, je tu problém.

Tohle je poněkud extrémní příklad, ale snad dost jasně vysvětluje, proč nemůže filesystém řešit disky, které lžou. Prostě to není možné.

[lertimir]

Ale takto mnohdy je. Kamarád měl obrovské problémy s externím 2,5" diskem, který se napájel přímo s USB, provedl zápis korektní odpojení (měl to sice na Win ale to by hrát roli nemělo.) Po zahlášeném povolení odpojit disk vytáhl a mnohdy tam data nebyly, někdy i po 5 sekundách. Nakonec to řešil tak, že když disk měl okamžitě odpojovat, tak měl 16 MB soubor, který po svých datech tam nakopíroval a ihned smazal a pak odpojil disk. Soubor vytlačil s interního bufferu disku zapisovaná data a disk byl v pořádku. Ale je to blbárna.

[pavlix]

Tenhle přístup miluju. To je problém HW a basta, aneb tupost některých lidí nezná meze...

To nezná. A často si to samé myslí o druhých.

[Sten]

Mám disk, který flush správně implementuje, a přesto se mi btrfs poškodilo (došlo místo na disku, několik bugů s tím stále existuje). Chybějící fsck by ani nebyl takový problém, hlavní problém je (byl), že veškeré chyby končí kernel panic, a to i když je oddíl připojen read-only — to se opravdu skvěle zachraňují data.

[d]

Chybějící fsck by ani nebyl takový problém, hlavní problém je (byl), že veškeré chyby končí kernel panic ...

Ano, stavu, kdy to muze skoncit panic'em, je stale jeste mnoho, ale aktivne se pracuje na handlovani nejcastejsich chybovych stavu.

a to i když je oddíl připojen read-only — to se opravdu skvěle zachraňují data.

Data se velmi dobre obnovuji ze zalozni kopie. Btrfs ma stale status experimentalniho filesystemu ve vyvoji.

[CET]

došlo místo na disku, několik bugů s tím stále existuje

OK, to jsou ale bugy btrfs, ne features. Az se ty bugy odstrani, tak by fsck nemel byt potreba. A taky, na produktivni data nepouzivam unstable FS.

[Martin Mareš]

Ale spatnej HW bych nechtel pouzivat ani s ext3 nebo reiserfs.

No to asi nikdo :) Ale realita je bohužel taková, že takových disků je po světě habaděj a není to o nich snadné poznat, než nastane nějaký problém. A pokud nastane, setsakramentsky se hodí mít po ruce nástroj, kterým se dá FS opravit.

Nebo můžete narazit na bug ve firmware diskového pole, nebo můžete omylem přepsat kus partitiony, když si spletete disky, atd. Situací, kdy jsem potřeboval sáhnout po fsck, už bylo...

[lertimir]

Jednu z metod, kterou používá kamarád na zjištování rizika chyb u nových disků je ta, že vždy provede uvodní plné formátování (na windows) kdy skutečně proběhne na každý sektor zápis a čtení. Ten formát je současných disku několik hodin (2TB / 100MB/s je 20 000 s. (Nevím jak to provést na linuxovém systému, třeba někdo poradí.) Současně při tom pravidelně monitoruje výskyt opravitelných read chyb, tak jak je ukazuje SMART tabulka disku. V případě, že četnost chyb je vysoká, disk vrací. Považuji dobré zpracovávání opravitelných read chyb jako jednu z možnosti včasné detekce problémů.

[pavlix]

dd if=/dev/zero of=/dev/sdx
dd if=/dev/sdx of=/dev/null

Případně můžeš vyladit velikost bloků.

[Michal Kubeček]

Není pak už praktičtější na to rovnou použít badblocks v read-write režimu? :-)

[Radek Hladik]

Osobně si nemyslím, že jedinou funkcí fsck má být oprava po výpadku proudu nebo HW. Ostatně už to jméno navozuje spíše FileSystem ChecK, tedy kontrolu souborového systému. Prostě pokud jsou na FS věci, které se dají nějak křízem zkontrolovat, tak se zkontrolují a případně vyřeší. Například každý (nesmazaný) soubor by měl být v nějakém adresáří, projedu tedy všechny soubory a pokud některý není v žádném adresáří, šup s ním do lost+found. Nebo FAT si udržuje informaci o volném místě na disku, tak se to přepočítá a pokud nesedí, tak se to opraví. Extx má záložní superblocky, pokud se neshodují, tak se to nějak vyřeší...

Prostě se zkontroluje všecko možné, co má tak nějak spolu hrát, jestli je to opravdu vše OK. A neřeší se, jestli došlo k výpadku vadným HW, které něco nehlásí, jak má, nebo zda užívatel udělal fdisk sda1 místo fdisk sda... A další nezanedbatelná funkce je přečtení celého disku a jeho struktur a kontrola, zda je vše OK.

[CET]

Ostatně už to jméno navozuje spíše FileSystem ChecK, tedy kontrolu souborového systému. Prostě pokud jsou na FS věci, které se dají nějak křízem zkontrolovat, tak se zkontrolují a případně vyřeší. ....

Prostě se zkontroluje všecko možné, co má tak nějak spolu hrát, jestli je to opravdu vše OK. A další nezanedbatelná funkce je přečtení celého disku a jeho struktur a kontrola, zda je vše OK.

No dobra, jenze ty popisujes veci, ktere se resi u standardnich FS. Ext3 a FAT. btrfs ma kontrolni mechanismy vestavene a (jak je ve clanku napsano), pokud pri praci neshodu zjisti, tak ji opravi sam. Volne misto u FAT - na btrfs to neni tak jednoduche, uz jen definovat "volne misto" je obtizne - je volne misto pocet volnych bloku (pak to muze platit jen do te doby, dokud se nezacnou nektere linkovane kopie menit) nebo je to [celkove misto disku] - [velikost vsech souboru] (vcetne linkovanych) (pak ti muze vyjit, ze uz mas pres GB nad limit disku). Rozhodne se to ale musi resit dynamicky. Z navrhu btrfs se taky nemuze nikdy stat, ze by nesmazany soubor mohl byt mimo adresar (mel nejak poskozeny popisovac), protoze zapis se provadi bezpecne - dokud nejsou vsechna data na HW zapsana, tak se nezmeni odkaz. Kdyz se odkaz zmeni, tak jsou data zase v poradku na novem miste. At nastane vypadek kdykoliv, data jsou porad konzistentni.

[Radek Hladik]

Chápu, že volné místo na BTRFS je komplikované. To jsem psal jako příklady kontrol, které se dají udělat křížem, tedy něco, co nějak má být a zároveň se to dá z jiného směru ověřit. BTRFS se svými B+ stromy, podsvazky, kontrolními součty a podobně určitě taky něco takového má. Vždyť už jen ta možnost ověřit, zda více kopií dat souhlasí. Pokud bych měl mít něčím nahradit RAID, pak určitě budu chtít nástroj, který mi ověří, že všechny kopie jsou konzistentní. A to v daném okamžiku a ne jen "vírou", že to tak má být.

A jsem vždy skeptický k tvrzením typu "nemůže se stát", "není možné", "transparetně se opraví"... Osobně už jsem zažil tolik "nečekaných", "nepravděpodobných" a "nemožných" situací, že bych mohl vyprávět

[Petr Svoboda]

Z navrhu btrfs se taky nemuze nikdy stat, ze by nesmazany soubor mohl byt mimo adresar (mel nejak poskozeny popisovac), protoze zapis se provadi bezpecne - dokud nejsou vsechna data na HW zapsana, tak se nezmeni odkaz. Kdyz se odkaz zmeni, tak jsou data zase v poradku na novem miste. At nastane vypadek kdykoliv, data jsou porad konzistentni.

To ovsem predpoklada, ze vznikne verze, ktera neobsahje zadne chyby a bude navzdy bez chyb. Hmm...

[Michal Vyskočil]

Hezký článek. Přidám jenom obligátní rejpnutí

Btrfs má dvě prvenství. Je to první linuxový systém souborů s nástrojem na defragmentaci

Pokud definici drobet rozšíříme o POSIX kompatibilní souborové systémy, tak tím prvním byl ve skutečnosti xfs.

[Heron]

Díky

Tou větičkou jsem myslel systém souborů, který je od začátku vyvíjen na linuxovém jádře. XFS má xfs_fsr, to jistě, ale je to FS firmy SGI původně pro IRIX.

[Michal Vyskočil]

Já vím, proto jsem psal o rozšíření definice. Já to beru tak, že XFS je podporován jak v RHEL6, tak ve SLES11, takže o něm skutečně můžeme uvažovat jako o linuxovém FS, i když počítám, že btrfs má ambice jej do budoucna nahradit.

[lertimir]

XFS je výborný filesystém na operace s velkými soubory, ale také stačil jeden výpadek napájení, xfs se odmítlo moutnout a fsck běžel přes hodinu na 750GB filesystému. Podle mne bez fsck se existovat nedá.

[Sten]

Jj, XFS je výborný systém, dokud nedojde k „něčemu neočekávanému“ (rozpadnutí diskového pole, výpadek proudu), většinou se potom můžete s přinejmenším částí dat rozloučit.

[Lukas]

No to urcite nema. Xfs je souborovy system s vynikajici skalovatelnosti, dobre si rozumi s databazemi a hodi se na ukladani velkych souboru. Zaroven ma taky velmi dobre vlastnosti pro ukladani streamovanych dat o vysoke rychlosti. To je neco co btrfs nikdy nebude, a uz jenom z podstaty sveho designu. Btrfs bude urcite velmi uzitecny na desktopech, v embeded zarizenich nebo jako /home, ale na virtualizaci, databaze ci nejake workloady s velkymi naroky na rychlost se uchyti jen stezi.

[Milan Beneš]

Ahoj,
možná se pletu, ale koncept subvolumes mi připadá identický s "folders" na ZFS, nebo se pletu?
Ví někdo, jak je to s kvótami na btrfs?

[Sten]

Btrfs kvóty podporuje, a to nejen user a group, ale i na subvolume, což je asi hlavní důvod, proč je na VPSkách používat

[d]

Btrfs kvóty podporuje, a to nejen user a group, ale i na subvolume, což je asi hlavní důvod, proč je na VPSkách používat

Btrfs jeste quoty neumi, existuje experimentalni patch http://lwn.net/Articles/462401/ .

[Yenya]

Dvě drobné nepřesnosti:

- BTRFS implicitně vytváří a kontroluje kontrolní součty jen metadat, nikoliv dat samotných (jestli se něco nezměnilo od doby, co jsem se díval naposled). Kontrolní součty dat umí, ale není to implicitní chování.

- žurnálování dat nemusí nutně znamenat 2x pomalejší zápis. Je to o něco víc než 1x, ale zápis do žurnálu je rychlejší (protože sekvenční), takže pokud budu v rámci souboru přepisovat sem tam blok, nebude to 2x pomalejší. Navíc ten druhý zápis není časově kritický (nečeká se na něho), takže pokud disk není ze 100 % busy, může aplikace se žurnálováním dat dokonce zaznamenat zrychlení. Na druhou stranu pokud budu streamovat na disk velké množství sekvenčních dat, bude to víc než 2x pomalejší, protože kromě sekvenčního zápisu přidám občas seek mezi daty souboru a žurnálem.

[Heron]

Podle btrfs wiki je implicitní kontrola crc jak dat, tak i metadat. Ale to je skutečně drobnost.

K tomu žurnálování dat. Jasně, tam je více možností, ono to nemusí být vždy 2x pomalejší, například je možnost mít žurnál na jiném zařízení (třeba SSD), tedy rychlý a ovladač FS se potom postará o zápis dat na cílové datové bloky.

Díky za doplnění.

[čha čha čha]

CRC a zadny crypto? Tak to je pekne na pikacu.. :/

[Michal Kubeček]

jen ext3 a ext4 umožňují také žurnálování dat

Žurnálování dat AFAIK umožňuje i ReiserFS (od jádra 2.6.8).

[----]

osobně používám ZFS (FreeBSD 9) a nemůžu si jej vynachválit; btrfs bude asi něco podobného, ale sám jsem jej nezkoušel.

[JoHnY2]

Cekam az to jeste trochu dozraje a prijde podpora RAID5. Diky pekenymu zdrazeni HDD to jeste nemusim resit a nejspis to vyjde na konec jara a Fedoru 17. Ta obecne slouzi jako dobrej barometr pouzitelnosti.

[d]

Zatím ale neexistuje příkaz, jak vynutit kontrolu celého systému souborů, lze ale snadno napsat skript, který přečte všechny soubory a tím také dojde ke kontrole součtů všech datových bloků.

Ale existuje, viz "btrfs scrub", je v kernelu od verze 3.0. Nejen ze soubory nacte z disku, ale take provede opravu, pokud je to mozne.

[d]

• Transparentní šifrování (ve vývoji).
• Deduplikace bloků (ve vývoji).

Na sifrovani se nepracuje ani neni k dispozici zadny experimentalni patch. Udelat sifrovani spravne je tezke, ZFS to trvalo nekolik let.

Experimentalni patch na deduplikaci existuje, http://lwn.net/Articles/422331/ . Jinak lze deduplikaci naprogramovat jiz dnes ciste v userspace pomoci ioctl clone, tj. spocitat si hashe bloku (nebo vetsich casti souboru) a provest slouceni pomoci toho ioctl. Zatim takovy nastroj neni k disposic(sic!)i.

[Petr Ježek]

Na Archu je potvrzeno, že Btrfs vhodný na disk s velkým množstvím malých souborů, obdobně jako Reiserfs. Já jsem ho ještě nezkoušel, ale jiní reportují dobré výsledky, na SSD pak mimořádně skvělé (dokud SSD udrží data)...

[Aleš Kapica]

Používám Btrfs už docela dlouho na velkém 4TB logickém disku kde mám přímo data. Je nad sw raidem, takže pravděpodobnost HW chyby, která by jej nabourala je minimální.

Jinak používám Reiserfs. Ten je v pohodě pokud diskový oddíl nepřesáhne 1TB. To mě však nepálí, neboť jde většinou o systémové disky max. kolem 30GB.

Začal jsem však ve větší míře používat ext4, a to z toho důvodu, že pro uložení virtuálních disků je vhodnější. Neustálé žonglování s "ocaásky" co dělá Reiserfs, nebo průběžná kontrola CRC u Btrfs je u nich vcelku na nic - konzistenci FS virtuálního disku si zjišťujě virtuál uvnitř sám, takže by to jenom zbytečně zdržovalo.

[pavlix]

Používám Btrfs už docela dlouho na velkém 4TB logickém disku kde mám přímo data. Je nad sw raidem, takže pravděpodobnost HW chyby, která by jej nabourala je minimální.

Až na to, že RAID proti chybám v datech nijak nechrání. A většina variant raidu ani při sebelepší vůli nemůže chránit ani proti chybám na jednotlivých discích, pouze proti detekovanému selhání disku.

Začal jsem však ve větší míře používat ext4, a to z toho důvodu, že pro uložení virtuálních disků je vhodnější. Neustálé žonglování s "ocaásky" co dělá Reiserfs, nebo průběžná kontrola CRC u Btrfs je u nich vcelku na nic - konzistenci FS virtuálního disku si zjišťujě virtuál uvnitř sám, takže by to jenom zbytečně zdržovalo.

Ty na virtuální disky dobrovolně používáš soubory? Při jednoduchosti práce s LVM mi to přijde docela kontraproduktivní.

[sigma]

Ty na virtuální disky dobrovolně používáš soubory? Při jednoduchosti práce s LVM mi to přijde docela kontraproduktivní.

Ono to zas tak jednoduché není. Souborové úložiště virtuální disků nabízí podstatně lepší snapshoty a thin-provisioning než LVM. Třeba XenServer umí celkem dobře snapshoty i nad LVM, ale používají se docela magické triky a i tak první snapshot alokuje stejné místo jako má samotný celý virtuální disk. Např. s nativními snapshoty na SAN polích nelze linuxové LVM vůbec srovnávat.

Ale i tak, pokud bych měl volbu LVM nebo soubory, radši bych to dal na LVM. Určitě ale zase záleží na situaci druhu použití.

[pavlix]

LVM umí snapshoty nativně... za běhu snapshotu můžeš celý disk zazálohovat přes dd nebo tar, pak zrušit snapshot. Fakt netuším, co bys ještě víc chtěl.

Souborové úložiště žádné snapshoty nenabísí. Pokud je umí ta daná virtualizace, umí je bez ohledu na to, jestli je to soubor nebo block device.

Přijde mi, jako kdybys to celé převracel naruby.

[sigma]

Nevim, nakolik ma smysl poustet se tady do diskuse, ale - implementace snapshotu v LVM je pro me nedostatecna. Je to opravdu tak max jsi psal - na zalohu a pak snapshot zrusit. I tak vytvoreni LVM snapshotu dost zasadne snizi vykon v zapisu. Myslim ze si to vyvojari uvedomuji a cetl jsem, ze se pracuje na podstatnem zlepseni moznosti LVM snapshotu.

Co vic bych chtel, a co virtualizacni reseni obvykle umi: pro kazdy virtual disk mit moznost drzet strom snapshotu (tj. nekolik snapshotu po sobe, pak se vratit zpatky, a pokracovat jinou vetvi). Pritom aby to nezabralo vic mista, nez objem zmenenych bloku + nejaka rezie. Kdyz to bude umet tohle, tak uz to umi i thin provisioning = mam zakladni obraz nejakeho stroje, z nej udelam X kopii a kazda mi na storage zabere jen to, co se zmenilo proti zakladu.

Jak udelas tohle pomoci LVM snapshotu? A proc v XenServeru, ktery to umi, tohle nepouzivaji a resi to pomoci vytvareni hromady obycejnych lv?

Souborovym ulozistem nemyslim prosty raw image, ale neco jako VHD format (mozna i QCOW2, ten tolik neznam), ktery prave resi veci jako thin-provision. Rozdil mezi FS a blokovym zarizenim je, ze soubory mohou dynamicky narustat a sdili pritom volne misto (nebo se pouziji primo sparse soubory, pokud to FS a OS umi).

(Psano z mobilu)

[Aleš Kapica]

Až na to, že RAID proti chybám v datech nijak nechrání. A většina variant raidu ani při sebelepší vůli nemůže chránit ani proti chybám na jednotlivých discích, pouze proti detekovanému selhání disku.

Od toho je FS, aby si pořešil konzistenci dat, ne? Raid mi minimalizuje pravděpodobnost stavu, že se ty data ztratí nadobro.

Proč používám virtuální disky jako soubory? Jednoduchá odpověď - pracuje se tak s nimi lépe než s LVM oddíly. Krom toho pro poslední řešení které používám, je to výhodnější.

[LukynZ]

Btrfs má dvě prvenství. Je to první linuxový systém souborů s nástrojem na defragmentaci....

Tak jiste, protoze to potrebuje jak prase drbani

[Aleš Kapica]

Ty toho o tom teda víš..

[LukynZ]

To je odpoved jak z nosu

[Aleš Kapica]

Zcela adekvátní vyjádření mého obdivu vůči znalci a mnohaletému uživateli linuxu, projevené na základě jeho jasnozřivého úsudku a vynikající znalosti fungování FS.

[LukynZ]

No spis arogantni hovadina hodna dlouholeteho uzivatele linuxu. Pokud je nejaky nesouhlas s tim, co jsem puvodne napsal, uvital bych spis vecnou odpoved a vyvraceni, ze to tak neni.

[Aleš Kapica]

Proč bych měl já něco vyvracet? Když ty s tím máš problém. Já ne.

[pepe_]

Tak sem vyzkoušel BRTFS jako / pro 50GB nově instalovanej UB12.04 a tak pomalej FS degradoval rychlost pc na 1/6 , a na 1/3 s noatime. Netušim proč ale už sem to odstranil a zpět na reiserfs ...

[Petr Fiedler]

Zdravím,

díky za skvělý článek, který je velmi srozumitelný i pro laika jako jsem já a i po těch letech má co říci. Je mi jasné, že btrfs je dnes jinde než tenkrát a budu si muset nějaké informace aktualizovat, ale i tak mi některé věci objasnil. Ještě jednou díky.

[Heron]

Díky! Jako zdroj informací doporučuju buď oficiální dokumentaci (man) nebo wiki. A hlavně si všechno vyzkoušet, hrát si.