Filesystem si má zachovávat určitou vícefunkčnost a neutralitu. O toto by se měl starat OS - resp. v případě Linuxu ekosystém OS a distribuce kolem něj. Samotnému btrfs bych to tolik ani nevyčítal, byť důsledky jsou opravdu k zešílení. Se zavaděči, mirrorem (jakéhokoliv typu), ..., byl vždy trochu problém, to není jen vinou btrfs.
Linux si trochu nešťastně zvykl zavádět přes initrd - to vzniklo před dávnými lety, kdy se image kernelu musela vejít do (tuším 4MB) a zbytek musel být v modulech. Myslím, že initrd dělá nepříjemný mezikus mezi bootloaderem a spuštěním initu (or whatever). Díky tomu, co distribuce, to odlišná procedura zavádění systému. A díky tomu musí být i filesystem dostatečně univerzální.
Myslím, že nejen Windows, ale i FreeBSD mají z pohledu uživatele startovací proceduru daleko přímější, jednodušší a instalovanou jedním vrzem. U Linuxu to bude holt chvíli trvat, než se všichni shodnou na nějakém společném řešení.
Co bych btrfs naopak maličko vyčítal je, že implementuje funkce z low end poptávky a mám trochu starost, jestli z něj nakonec nebude tak trochu kočkopes. Nejde, podle mě, udržovat vývoj filesystemu, který má jak enterprise vlastnosti, tak řeší kdejakou nestandardní hardwarovou situaci. Kombinace HDD a SSD v jednom raidu je podle mě přesně taková vlastnost, bez které by se enterprise filesystem lehce obešel.
Btrfs to otestuje automaticky ve chvíli, kdy se poškozený soubor pokusíte přečíst. Vzhledem k tomu, že z mechanického disku se nikdy nečte, tak to automaticky ani nikdy neotestuje. Scrub se spouští ručně, abyste si mohl vybrat, kdy ho spustíte, jelikož snižuje výkon. Úplně stejně se spouští scrub na MD nebo ZFS. Pokud je vám jedno kdy, strčte ho do cron.weekly a bude se „sám spouštět sem tam na pozadí“.
Protože při kontrole filesystému je potřeba ten filesystém odpojit. Kdyby se filesystém sám od sebe odpojoval a kontroloval a znemožňoval uživateli práci, tak by z toho uživatel moc nadšený nebyl.
Ostatně ext2 se sám od sebe při startu kontroloval po určitém počtu připojení, a působilo to probémy - když zapneš počítač a půl hodiny nemůžeš pracovat, protože se to samo rozhodlo, že se to musí zkontrolovat.
Pozor, minimálně na btrfs (na ZFS nevím) není scrub kontrola FS v tom smyslu, jako ji provádí třeba e2fsck - při scrubu se pouze zkontrolují kontrolní součty, ale už se třeba neověřuje, že je to validní B strom (že jsou všechna data dosažitelná, že pointry nevedou někam dopryč, že tam není cyklus…).
Bohužel se mi to stalo, a nejsem sám.
Bug v SW, vadná RAM? Je to notebook (bez ECC), ale memtest86 nic nenašel. Teoreticky třeba má paměť při uspání pomalejší refresh nebo při převážení špatný kontakt… kdo ví. Bohužel mi přijde, že čím složitější FS, tím horší následky taková chyba má.