Vlákno názorů k článku Fedora 33 přejde na Btrfs od vdx - Možná, že se Fedora plošným nasazením Btrfs zaslouží...

Možná, že se Fedora plošným nasazením Btrfs zaslouží o vyřešení některých letitých nedostatků tohoto Fs.
Mimo jiné nemožnost efektivního offline checku s opravou chyb. Zadalší mizerná výkonnost s SMR disky. A také příliš velké zatížení procesoru při online checkování (scrub atp.) na slabších strojích. Btrfs už provozuju možná 10 let a zatím vidím téměř nulový pokrok v těchto oblastech, z čehož usuzuji, že ve vývojářském týmu bude nějaká konkrétní žába na prameni (v rozhodovací pozici), která úsilí v těchto věcech zatvrzele blokuje, patrně proto, že to nepovažuje za relevantní...

> Mimo jiné nemožnost efektivního offline checku s opravou chyb.

Od tohto odstupujú aj ostatné filesystémy. Offline check pri dnešných veľkostiach filesystémov môže trvať dni, a to je na offline príliš dlho. Preto sa snažia prejsť na online opravu chýb.

A v žiadnom prípade preventičný fsck pri každom 20-tom nabootovaní. Viete si predstaviť, že by vám server bootoval týždeň-dva iba kvôli preventičnému fsck?

> Zadalší mizerná výkonnost s SMR disky.

Ktorý fs nemá mizernú výkonnosť so SMR diskami? Žeby to bolo mizernou výkonnosťou SMR diskov samotných?

SMR je použiteľné naximálne pri host-managed SMR, keď máte na to navrhnutú celú architektúru storage. Disk-managed SMR bude vždy problematický z hľadiska výkonu.

> A také příliš velké zatížení procesoru při online checkování (scrub atp.) na slabších strojích

Na atome (C2538) som si ani nevšimol.

Preventivní pravidelný offline check je úplný nesmysl, když máte online automatický check, který to řeší na pozadí - tohle jsem neměl na mysli. Ale *** nouzový offline check, který spolehlivě řeší středně těžké problémy *** (např. oblíbený power-off failure death) má IMHO stále smysl a ve většině případů to bude efektivnější než se pak snažit vykopírovat data na jiný harddisk, formátovat a znovu kopírovat. V lokálním případě to bude znamenat tam ten náhradní disk přinést, připojit, nabootovat do jiného systému atd. Na dálku přes admina taky možné, ale rychlost může být ještě podstatně menší. V každém případě opruz na x-hodin, protože to člověk musí sledovat a aktivně něco dělat (i kdyby nakrásně nasadil záložní server). Ze zkušenosti si pamatuju, že kontrola 1TB rotačního disku u ext4 mi i v případě oprav chyb trvala podstatně kratší čas (desítky minut)

SMR disky mají jen v některých případech špatnou výkonnost, existuje možnost jak to aspoň částečně řešit, přičemž nějaká podpora je v kernelu tuším od verze 4.12. Mně se podařilo vytunit fs tak, že aspoň pro archivační účely rychlosti příliš nepadají a jsem zatím celkem spokojen za tu cenu, kdybych ale měl možnost volby, pořídím PMR - ty už ale výrobci kromě nejvyšších uber řad téměř nenabízí. A provozovat na SMR core system, nějakou databázi nebo vývoj by byla v každém případě hloupost, od toho jsou SSD.

Měl jsem brtfs na starším ntb s Core2Duo ULV a žralo mi to pravidelně 50% vytížení jádra, což je IMHO moc. Takže na Atomech to bude asi něco podobného, akorát že když je to v NASu, tak to provoz neomezí, protože většina paketů prochází přes hw čipset. Projevit se to může asi až při streamingu s de/kodóváním, nebo kdyby tam člověk provozoval další aplikace přes SSH tunel, tiskárnu, USB zařízení nebo tak.

musim potvrdit, ze SMR disky su uplne v pohode v pripade dlhych sekvencnych Write operacii, teda uplne vhodne ako Archivacne mediu, resp. medium pre taketo sekvencne zapisy. Slapu plne v pohode. Musi to vsak byt Simple disk alebo JBOD. Nie RAID.
V pripade presunu SMR disku do RAIDu, ktory nema na urovni Storage systemu podporu HMSMR je to tragedia, hlavne u SW RAIDu:
- objavuju sa write hole (pretoze mnozstvo operacii caka na cache samotneho disku)
- po vyhuleni I/O v pripade bezneho Random I/O je to cista katastrofa. Asi taka ako pad performance pri QLC SSD.
- mame testy a

Co sa tyka BTRFS data scrubbing - musim potvrdit, ze na stredne malych NAS s RAID5 nemam paru o tom, ze scrubbing bezi. A to mi tam frci este Snapshot/Replica a 20+ kontajnerov na Atom server line CPU. Mam slusne velku farmu v praci aj doma, takze pisem z reality.
Btw, viac o uspesnom prepojeni LVM s BTRFS RAIDu a pouzivani v praxi sa dozviete na nezislom fore Synoforum.com. Aktualne rozbiehame uz aj lokanu CZ/SVK verziu.

Btw, tie posty zopar jedincov k teme straty dat na BTRFS - zalohy nic? Stracat data si naozaj zasluzi ten, kto sa o ne nestara.

Check se porad vyviji. Chyby, co se objevuji, jsou spis zpusobene vadnym hardwarem (nejcasteji memory bitflip, u disku firmware), takze hodne zalezi jestli se z toho da nejak poznat, kde ta chyba zacala a kam az se rozsirila. Ohledne efektivity je ve vyvoji mod, ktery se nesnazi udrzet v pameti vsechna metadata, za cenu, ze neco musi cist znovu z disku.

S drive-managed SMR disky se toho moc udelat neda a mel to byt spis takovy predel nez se upravi software. WDC pracuje na podpore host-managed SMR. Talk o tom treba tady https://osseu19.sched.com/event/TPI0/file-system-support-for-zoned-block-devices-naohiro-aota-damien-le-moal-western-digital .

Na slabsich strojich bude s CPU asi problem obecne, scrub cte data skoro linearne, takze dovede asi saturovat pomalejsi procesor na pocitani checksumu, pripadne pouziva intenzivne pamet a tahle rezie bude znat.

Ohledne konspiraci se zabami na prameni muzu zodpovedne prohlasit, ze blokuju zejmena kod, ktery nesplnuje naroky na kvalitu nebo neimplementuje svuj usecase dostatecne :) Kdyz by nekdo prisel s vylepsenim scrubu tak nebudu proti a pomuzu. S checkem je to tezsi, protoze neni nejaky univerzalni navod, jak co presne udelat, takze se vic diskutuje a premysli.