Hlavní navigace

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ží...

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 7. 2020 23:34

    vdx

    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í...

  • 20. 7. 2020 11:07

    ja.

    > 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.

  • 20. 7. 2020 14:59

    vdx

    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.

  • 21. 7. 2020 17:05

    bez přezdívky

    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.

  • 22. 7. 2020 21:02

    kdave_

    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.