Vlákno názorů ke zprávičce Linus Torvalds doporučuje nepoužívat ZFS na Linuxu od LA_USER - Já třeba ZFS používám proto, že pro mě...

Já třeba ZFS používám proto, že pro mě neexistuje rozumná alternativa, co by za mě vyřešila najednou cryptování, snapshoty, rozdílové posílání snapshotů, SSD cache, a jiné nice-to-have features.

ZFS běží i na RPI4.

Šifrování je z mého pohledu jediná killer featura, kterou ZFS má. Všechno ostatní, co říkáte, umí i BTRFS. Ale protože podpora šifrování se postupně objevuje i v jiných FS, jako F2FS, třeba se dočkáme toho, že se jednou implementuje správně, tj. na úrovni VFS, a pak ji bude moct používat i BTRFS a ZFS už nebude potřeba.

Další killer feature je stabilita. BTRFS se mi zatím pokaždé rozsypalo. Nemít zálohy, přišel bych o data. U ZFS se mi to (zatím?) bohudík nestalo.

Naprosto rozumím obavám z Oracle, ale po technické stránce mi to přijde jako zbytečná žabomyší válka.

mozte prosim napisat viac o konfiguracii, v ktorej ste BTRFS bezali a celkovo o detailoch, ako k tomu doslo? sam ho mam na NASe ako RAID1 a dalsie backupy neriesim. dakujem! j

OpenSUSE, defaultní instalace na laptopu. Vždy se to přibližně po půl roce provozu se to sesypalo a nedalo se to ani namountovat. Nic důležitýho jsem tam neměl, home a veškerou konfiguraci mám ve verzovacím systému, tak jsem se v tom nevrtal a přeinstaloval.

Po druhém pádu jsem přešel na ubuntu s homem na ZFS, to tam mám přibližně dva roky. Teď na podzim jsem nainstaloval 19.10 se ZFS rootem a jsem spokojenej. Funguje to velice dobře. Ze ZFS používám většinu pokročilých vlastností a zatím bez problému.

Úplné rozsypání jsem zažil někdy na začátku 2016 s tehdy aktuálním kernelem, začalo to hlásit "corrupt leaf", ačkoli scrub procházel bez problému. Data byla stále dostupná, takže šla vykopírovat až na těch několik poškozených souborů. Pak jsem pustil fsck a ten smazal rekurzivně celý adresářový strom. A pak už to nešlo ani namountovat.

Zbytek byly nefatální problémy:

- RAID1 šel degradovaně připojit pro zápis pouze jednou, pak jen pro čtení. To opravili před pár lety.
- Dostalo se to do stavu (vytvářením a mazáním snapshotů, i když jsem je nemazal na přeskáčku), kdy metadata zabírala spoustu místa a bylo potřeba pustit balance -musage 20, což trvalo několik dní na lowendových rotačních discích (6TB). Když se to stalo podruhé (cca. po dvou letech provozu), bylo to celé tak pomalé, že jsem to zrušil a vytvořil znovu.
- Opakovaně se tomu na 4.15 daří vyrábět nested snapshoty, které se musí mazat rekurzivně. Takže workaround v pohodě, ale přijít na to chvíli trvalo (chybová hláška byla useless).
- Kolem 4.1 vyráběl Dovecot na btrfs RAID 1 soubory, které při čtení vracely I/O error, žádnou chybu to nezalogovalo, scrub bez potíží a po rebootu se to vždycky na pár dní samo opravilo.

I kdyby byl BTRFS bezchybny, tak ti RAID 1 nezarucuje mnoho. Muze ti odejit (byt odnesen...) cely NAS.
Pokud ta data mas rad, tak backupy ano. (btw - ne 'dalsi' backupy, protoze RAID1 zadny backup neni.)

BTRFS se mi pod rukama rozsypalo tolikrát, že to na více blokových zařízeních odmítám používat.

U ZFS se mi stalo snad jen jednou a to mou chybou(přetekla data na datasetech, co nebyly omezené a měly být).