Už dlouho je, ale (pochopitelně) se jim nechce na to v dokumentaci příliš upozorňovat, kdyby se náhodou ještě něco stalo.
AFAIK ten "write-hole" problém nastane právě tehdy, když probíhá zápis na disky, zároveň dojde k zastavení systému (výpadek napájení, kernel oops, hard reset CPU atd) a zároveň během tohoto downtimu jeden nebo více disků selže (je odpojen atd).
Pokud se stane jen jedna nebo dvě věci z výše uvedenýho, tak se nestane nic.
Mám v btrfs raidu5 celej svůj /r/DataHoarder rack a popravdě jsem se ještě nedokopal k připojení UPSky. Od spuštění v 2019 to zažilo nepočítaně výpadků proudu, i pár disků odešlo, ale ještě jsem nepřišel o jedinej soubor. I tak mám ale samozřejmě zálohy (S3 u Backblaze).
Diky za info. Ty vicenasobne podminky jsou takove co nikdo nezminoval - takze bych rekl ze to bude pro me bezpecny (systemy mi nepadaji, UPS mam).
Me spis od praktickeho nasazeni odradilo to, ze je ten btrfs pomalej (vuci srovnani s mdraid/ext4 ... prislo me ze to cte porad jen 1 disk, namisto "R0" pristupu).
Takze pokud R5/R6 tam jede - a budu mit offsite zalohy (nechci cloud, ale sync na "write only" repliku.. coz je pro casovane snapshoty a send/receive asi ideal, ne?), tak bych to mohl nasadit jako finalni/produkcni reseni?
A jak je to tedkom s mixed type poolem jako ssd+hdd? Tj nejake SSD bud jako metadata/smallfile cache (read-mostly kopie), pripadne R1 uloziste pro tyhle metadata/smallfile?
Ke stavu raid5/6 jsem nedávno četl jeden dva roky starý post z mailing listu a příjde mi, že je to i dnes stále ve stejném stavu. https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/
5. 10. 2022, 23:11 editováno autorem komentáře
Tak z precteni z techto problemu mi je fakt blivno.. ale hlavne ze je to moderni a frikulinsky :(
Chapu ze nejde postavit nejaky slozity zazrak, ale pristup ze rozdelame vsechno a nedokoncime nic.. se me osobne nejak nelibi. Pokud se rozhodnu neco pouzit.. tak to je pro realne featury..
.. takze zas zpet ke klasice? jednoduse "for piece of mind".
Před dvěma lety mi klekl jeden disk v Btrfs RAID-1, následkem čehož jsem se seznámil se zábavným bugem v Btrfs, kde když ve dvoudiskovém raidu odejde jeden disk, tak poškodí nějaká metadata a zbylý disk už pak lze přimountovat pouze v read-only režimu a špatný disk tak nelze nahradit novým. Bug byl známý už léta a popsaný kdesi ve wiki, ale s opravou zjevně nikdo nespěchal.
O žádná data jsem nepřišel, ale musel jsem je všechna překopírovat jinam a diskové pole vytvořit znova. Btrfs tam používám pořád, protože tam nemám nic zásadně důležitého (a tenhle konkrétní bug už, myslím, mezitím opravili), ale beru ho od té doby spíš jako zajímavou hračku, než jako dospělý souborový systém.