Administrace komentářů

Scrub + RAID56: mostly OK, mostly OK 
RAID56: Unstable, write hole still exists (see below)

Což je sice pokrok, ale takto napsané to nevyznívá tak, že už je z praktického hlediska pořešené.

A u mdadm a dmraid tedy nevadí, že tohle není, nebylo a nikdy nebude "pořešené"? Já ten dvojí metr prostě nechápu.

Write hole na Btrfs je zajímavý teoretický koncept, který sice nikdy nikdo neviděl v praxi, ale mohl by (čistě teoreticky) nastat, když se ve formální verifikaci celého přístupu prohledají všechny okrajové případy.

Nicméně uživatelé nebezpečného šílenství typu dmraid nebo mdadm už léta (desetiletí!) všechna rizika s tím spojená ochotně přijímají. Tak proč je najednou jakési zanedbatelné, dočasné a teoretické riziko na Btrfs problém, který stojí za řeč?

Definice těch stavů totiž říkají:

mostly OK: safe for general use, there are some known problems that do not affect majority of users
Unstable: do not use for other then testing purposes, known severe problems, missing implementation of some core parts 

Takže pokud je skutečné stav RAID56 módu v brtfs takový, jak píšeš, představoval bych si, že by v té tabulce měli aspoň "mostly OK" místo "unstable".

Mé oblíbené odkazy z nedávné historie Ext4 ([2009] [2012] [2015] [2018]) zase říkají, že Ext4 je průser jak mraky, který není ani mostly OK, natož stable nebo co, a nikdo už to nikdy nevyřeší a neopraví. Přesto je rizikový Ext4 s rizikovým AIDem (mdadm / dmraid) dál "podporovaný" některými instalátory a dokonce (bohužel) i doporučovaný.

Kromě toho, co je to vlastně raid5/6 mód? Mód pro metadata a mód pro data jsou dvě oddělené věci. Proto jsem zmiňoval raid1c3/4: Kdo si opravdu myslí, že Btfs musí být nejen nesrovnatelně lepší než mdadm/dmraid (což už spoustu let je), ale dokonce přímo dokonalý (a otázka je, proč si tohle pořád někdo myslí), ten si může u metadat nastavit takový režim, který write hole vylučuje, tedy replikovaný raid1c3/4. Pseudo-problém vyřešen.

Případně pokud má někdo dojem, že ZFS (se svým úžasným kódem v C89, který se s každou druhou verzí Linuxu nepřeloží a musí se počkat, až někdo patche zas opraví — ano, já vím, může za to CDDL, ale co se dá dělat, tak to prostě je) je lepší volba, nechť klidně používá ZFS. A kdoví, třeba ZFS nakonec je dobrá volba. Linux si nasral do vlastního hnízda napřed odmítnutím Reiser4, dost možná nejlepšího filesystému všech dob, potom zdržováním restrukturalizace VFS tolik potřebné pro Btrfs / ZFS a ve finále ještě otrávením celého "ekosystému" kolosální kravinou typu Tux3 (kde je tomu nesmyslu dnes konec?!), což Btrfs soustavně házelo klacky pod nohy. Solaris se ve stejném období vyvíjel solidním tempem. (Škoda, že Solaris dopadl, jak dopadl.)

Každopádně díky za odpověď. Nic proti btrfs nemám, sám btrfs na několika místech mám (ale ne v raid56 módu).

Data nebo metadata? To je, oč tu běží.

Můj raid5 a raid6 z let 2015 a 2017 se zatím těší plnému zdraví. Data i metadata mám ve stejném formátu, protože v těch dávných dobách ještě nebyl raid1c3/4. Jediné, na čem mi záleží, je fakt, že to řešení je nejspolehlivější, jaké můžu mít — lepší než softwarový AID (dmraid, mdadm), napůl-hardwarový pseudo-RAID (tedy zase jenom AID) atd.

Ale v tomto případě nejde ani tak o fud jako o nešťastnou komunikaci ze strany btrfs vývojářů.

Ta komunikace je sice nešťastná, ale přijde mi, že celkem odpovídá přístupu nedůvtipného okolí k celému projektu a k práci těch vývojářů.

Fedora 33 bude mít Btrfs (konečně, s 10-letým zpožděním!) jako implicitní filesystém v instalátoru. Dobře, to je bezva.

Jenže Solaris měl už v roce 2009 takovou samozřejmost, že update se instaloval do naklonovaného atomického snapshotu filesystému. Pak se jednoduše snapshot s novým systémem povýšil na ten "hlavní", kopie se degradovala na klon a nabootovalo se z nového atomického obrazu. Nikdy se nebootovalo z něčeho, co by mohlo mít nekonzistentně přepsanou část programů nebo (kni)hoven. Kdo dnes takhle využívá Btrfs? Kromě několika menšinových distribucí tohle zatím nikde není. I Fedora volí přehnaně konzervativní nastavení, kde Btrfs snapshoty vůbec nebudou hlavním tématem (kromě systemd-homed) a kde se bude systém při aktualizacích postaru přepisovat.

To^^^ se sice zdá být hloupé a smutné, jenže když se člověk podívá an mailing list Fedory z doby půl roku zpátky, jak tam pár idiotů navrhovalo odstranění Btrfs z distribučního kernelu Fedory (opravdu! bez prdele!), najednou se prostý fakt, že se konečně Btrfs stává implicitním filesystémem, jeví jako úspěch.

Stylu komunikace vývojářů Btrfs se tedy vůbec nedivím! Kdyby mi někdo házel klacky pod nohy plus zároveň chrchlal zelenáče do ksichtu, taky by se mi nechtělo komunikovat.

Podobně jako když se filesystém formát označil za stabilní.

Co to znamená stabilní? Poslední podstatná změna diskového formátu Btrfs se datuje někdy do dob kernelu 2.6.31 ze srpna 2009.

Podobně jako ZFS má svoji feature bitmap (man zpool-features), která postupně nahradila těžko udržitelné jednorozměrné verze poolů, má i Btrfs své incompatibility flags (viditelné třeba v btrfs inspect-internal dump-super <zařízení>), které jednoduše brání použití Btrfs s novými rozšířeními na fosilním kernelu, který ta rozšíření nepodporuje. Jak by to mělo být jinak? To by měl být filesystém zmrazený a 20 let stagnoval? To snad ne; to už tu v minulosti bylo a nebylo to dobré.