Vlákno názorů k článku
Nepoužívejte Bcachefs s jádrem 6.7 na více discích, hrozí ztráta dat od vogo - Jak jde čas, tak to vypadá, že fousatá...

Jak jde čas, tak to vypadá, že fousatá EXT4 s kořeny v devadesátých letech minulého století, až na občasné excesy, zůstává jistotou pro obyčejného usera :-). Hnát se do minoritně používaného souborového systému znamená nutnost opravdu pravidelně zálohovat a počítat se ztrátou dat. Stále to říkám, jsou dva druhy lidí, ti kteří zálohují a ti, kteří o data ještě nepřišli.

Bohuzel ani to zalohovani nemusi byt zachrana - kdyz treba zvolite zfs/zfs nebo btrfs/btrfs kvuli tomu ze tam je send/recv .. a ono se to podela oboje.

Udrzovat ruzne technologie (diverzifikovat riziko) pak znamena ze jste degradovan na zakladni featury.. takze zas jsme zpet u preferenci klasickych FS.

Pokud člověk myslí zálohování vážně, tak zvolí nějaký ověřený filesystém. Však také na co mít zálohu na nějakém hyper-super systému, když se to potom nedá obnovit. Navíc záloha je záloha, tam nepotřebuju mít o tisícinu sekundy rychlejší přístup k souboru. Osobně preferuji EXT4, sice čas od času vidím nějaké srovnání, kde není tenhle stařeček kdo ví jak hvězdný, ale prostě funguje. Jasně pro webserver se asi nehodí, ale pro osobní počítač je to až někam a víceméně bez rizika.

Asi jsem první větu nepochopil, ale ZFS i btrfs jsou otevřené. Problém je, že běžný administrátor nejspíš nerozumí z hlediska kódu ani EXT4, ani XFS, ani ZFS ani btrfs a nakonec ani bcachefs.

EXT4 má svoje výhody a svoje úskalí (např. aktuálně https://blog.allegro.tech/2024/03/kafka-performance-analysis.html).

Disaster recovery na jiný souborový systém smysl dává, u záloh to nemusí být v určitých nasazeních možné, protože se to prostě nedá stihnout v daném čase.

Myslel overeny, ne otevreny. Proste "production ready, non experimental".

Jako tady ty problemy ze "kafka jede na ext4 pomalu", jsou takove echt cicoviny, ktere delaji dnesni decka protoze vubec nerozumi jak veci funguji - treba ze disky maji hlavicky, ktere je nutno nekam presunout, a tudiz je k dispozici nejake IOPS.

Pokud ta aplikace dela 300K iops, tak to asi normalni komp/ssd disk stejne neda. To neni problem EXT4 prece.

BTW ja mam ext4 implementovano po svem (v PHP), kvuli obnove dat.. neco jako btrfs/zfs se v rozumne dobe neda udelat a ani nevim zda maji nejakou normalni dokumentaci vyjma kodu.

18. 3. 2024, 19:25 editováno autorem komentáře

V Sunu tomu zas az tolik lidi nerozumelo. To byli specialisti. Ja jsem se ztratil po prvni tretine prednasky jak pouzivat zfs debugger a dtrace pro hledani problemu v zfs aby bylo o cem prednaset. Ale tak jsem jenom blbej sysadmin/architekt co nici systemy a nema programovani jako hlavni napln prace. Mozna by to nekdo talentovany i dal napoprve.
Clovek s tim ale musi delat. Denodenne aby pochopil.

Mit odladeny FS se pokrocilymi funkcemi je jedna z velmi tezkych uloh v IT. Zakerne je na tom to, ze to z vnejsiho pohledu pokud jste na tom nedelali vypada jako lehky ukol.

Nazyvat send/recv zalohou je jako nazyvat fs snapshot zalohou. Nevylouci to logickou chybu na fs.
Ne. Zaloha ma byt idealne kopie na jiny fs. Klidne neco jednoducheho jako xfs,ext,ufs,stream atd.

Dalsi vec. Zalohy se co? ... testuji/verifikuji! Jinak je zalohovani na co? No na... h

Az na ten drobny detail, ktery tu zaznel, ze mas vzdy nejakou zcela Omezenou konektivitu, a ta data potrebujes nejak v Omezenem case prenest.

Nemluve o tom, ze neni zaloha jako zaloha, a nikdy neresis 100% vsech okolostoicnoti ktere mohou nastat, jednoduse proto, ze jich je nekonecne mnoho, a to by znamenalo taktez nekonecne vysoke naklady.

Co myslis, jak funguje 90% vsech zalohovacich apps? Nj, delaji snapy. Jinak receno, na zalozni HW se prenasi prave a jen to, co se od minule "oficielne" = FS to nejak zaznamenal, zmenilo.

BTW: Nedavno jsem jednomu svemu zakaznikovi posilal milostne psanicko ... ve kterem jsem ho upozornil, ze kompletni obnova zaloh by trvala cca 10 dnu, v idealnim pripade. Rychlejs by to totiz na prislusnem HW neslo. S tim, ze realitu bych odhad na mesic, protoze ono se vzdy najde neco s cim se nepocitalo, co nefunguje, ...

To je jednoduche. Bud mi za to ta data stoji a nebo ne. Bud do reseni investuji a nebo ne. To same se tyka i zdroju a to nejen HW. Tj. nekoho kdo oddeli dulezita data od mene dulezitych. Kdo to vyjedna (nebo jak by rekl Prazak - vykomunikuje) u zakaznika. Data ktera muzou jit hned na archivaci a ktera maji jako mezistupen zalohovani. Jestli poridit temne vlakno nebo data vozit autem do trezoru.

Kdo naplanuje verifikacni behy a v jakem sledu. To je nezavisle na pouzitem FS. Zadny FS na svete neresi spravne zalohovaci procesy a dimenzovani infrastruktury.
Nedimenzovani backup site je jednim s dalsich prohresku. Zalohovani na jiny FS je level nizka az stredni investice.

Dobrym kompromisem bylo reseni kdy daemon se byl schopen domluvit s backup serverem na tom kdy vyklopit buffery aby byla aspon nejaka konzistentni data , ktere bloky vyklopit na pasky a zaloha pak jela uz jen v rezii sanky,storage site a pasek. Nezatezovaly se koncove stroje. To je ale reseni od nekoho jehoz jmeno se tu nesmi vyslovovat.

19. 3. 2024, 10:13 editováno autorem komentáře