Administrace komentářů

Na zjišťování problémů a automatickou opravu je scrub.

Může se zdát podivné, že připomíná "FSCK v kernelu", nicméně je to celkem v souladu s ideou, že systém má mít co nejdéle uptime a co nejméně důvodů být v neobvyklém offline režimu, kdy běží FSCK na odmountovaných discích a nic jiného se nedá dělat.

Kromě toho mělo kdysi dávno smysl mít FSCK mimo kernel kvůli velikosti příslušného kódu. To ale při dnešních velikostech RAM (a při nápadech typu deduplikace na ZFS) nemá až tak valný smysl, což je jeden z těch mnoha důvodů přechodu od FSCK ke scrubu.

Dlužno taky dodat, že scrub trvá (obecně) mnohem déle než FSCK (bereme-li třeba Ext4 za vzor, jak dlouho má trvat FSCK), protože u Ext4 nejsou žádné checksumy dat ke kontrole. Proto je lepší, když se dá se systémem (aspoň omezeně) pracovat během scrubu.

Případný oddělený FSCK pro Btrfs by taky znamenal, že by se musel na dvou místech udržovat kód, který by dělal něco velmi podobného, jen v jiném prostředí, s jinými požadavky na synchronizaci atd. Což nemusí být zrovna nejlepší využití času vývojářů.

…ale historií podivných problémů…

Otázka je, co z toho je skutečná historie Btrfs a co souvisí spíš s faktory mimo ten souborový systém.

Některé anekdoty mi (vzdáleně) připomínají začátky PulseAudio. V prvních 5 letech jeho existence jsem PulseAudio vyhazoval, jak jen to šlo, všechno buildil bez něj atd. Důvod byl ten, že to na žádném mém stroji nefungovalo. Nejčastěji zvuk nebyl vůbec. Nebo neexistovala možnost zároveň nahrávat a přehrávat, tedy mít normální online hovor. Nebo se místo očekávaného zvuku ozvalo něco divného, jako by si to rozdávali roboti.

Když se na to dívám zpětně, skoro nic z toho nebyly chyby v PluseAudio (byť něco málo možná jo). Jak se později ukázalo, vyplul zkrátka na povrch nepříjemný počet dlouho skrytých bugů v ALSA driverech všeho druhu.

Dnes mi PulseAudio funguje skvěle. Přes Bluetooth umí aptX. Přehrává mi všechno lokálně i po síti. Neumím si bez něj desktop představit.

Těžko říct, podobně na tom může být některý hardware (v anekdotách často zmiňovaný), který třeba s Ext4 "funguje" (v tom smyslu, že se na první pohled nic překvapivého neděje), zatímco s Btrfs to třeba najednou začne odlétat na některý z checksumů, které nesedí vlivem bitflipu v paměti.

To^^^ je samozřejmě znepokojivé a nepříjemné, ale nepřipadá mi to jako důvod nedůvěřovat Btrfs a důvěřovat tomu jinému filesystému. Rozumné dlouhodobé řešení podle mě netkví v tom, že se problém bude ignorovat a/nebo používat takový filesystém, který ho ignoruje.

Konkrétně tento nepříjemný zážitek s Btrfs jsem měl taky:

• FS je ve stavu že při každém mountu je potřeba udělat zero log

Bylo to v roce 2012. Chtěl jsem Btrfs RAID 5, jenže co s tím, když tenkrát žádný neexistoval. Disků bylo 5 a asi jsem na ně měl dát RAID 1 (v tom smyslu, v jakém ho definuje Btrfs), jenže i tuhle variantu jsem zavrhnul. (Přece nebudu mít jenom polovinu místa, blablabla, atd.)

Inu, udělal jsem tedy to, co se dělat nemělo a co návody velmi výslovně nedoporučovaly: mdadm AID 5 a na tom Btrfs. Problém s tím byl hlavně proto, že tahle kombinace měla nějaký notoricky známý problém se synchronizací; Btrfs prostě nebyl na tenhle režim provozu navržený a měl mít vlastní RAID. (Taky v Btrfs není žádný optimalizační hint jako stride a stripe width; prostě to nad softwarovým AIDem být nemá.)

Asi 2 měsíce to takhle běželo, jenže potom, po nějakém divném restartu, resilveringu toho mdadm a kdesičemsi dalším začala dlouho trvající otrava s btrfs-zero-log (což je dnes btrfs rescue zero-log; tenkrát to byla samostatná binárka). Sice ne při každém mountu, ale asi tak při každém pátém jo.

Celkově to rozhodně nebyla příjemná zkušenost, to ani náhodou, nicméně nenapadlo by mě vinit z důsledků takového experimentu Btrfs a/nebo usuzovat na základě toho cokoliv ohledně fungování Btrfs dnes.