Az elsőt nem kommentálom, mert nekem saját tapasztalatom elég sok van, és problémám csak kísérleti dolgoknál volt eddig, pl. a 3.11 ben frissen bevezetett skinny extent et régi filerendszerre utólag ráengedtem, és az online defrag meg balance tól segfaultolt a kernel. Adat nem veszett, nem is sérült, és kernel bugzillán küldtek patchet ami megoldotta.
Másik hiba xen virtuális gépet tároló filerendszer online defragolásánál volt, ez nem kizárt, hogy az O_DIRECT vagy egyszerűen egy régebbi kernel verziónak az együttállása miatt okzott hibát (de csak ritkán).
+ Egyszer volt olyan filerendszer sérülés, ami a memória random felülírása miatt következett be, azt nem írnám a btrfs rovására, ahogy te az ssd hibáját (???), és a recovery ott is nagyrészben segített (backup nem kellett visszaállítani).
>
> Gondolom ezt ugy erted, hogy vannak bizonyos esetek, amikor igaz.
>
Nyilván ott, ahol az adat jól tömöríthető, és a blokk eszköz sebessége a szűk keresztmetszet. Ez tipikus root filerendszernél (usr bin, lib, stb.) és home könyvtárnál (mindenféle sqlite, meg plain text dolgok). Egyébként a compresst a file tartalma alapján automatikusan kikapcsolja, ha nem jól tömöríthető, de ezt nem tudom pontosan megmondani mi a szabálya, de elvileg így van...
Egy példa: az usr/src ban két kernel forrás van most, 1.1gigabyte, a filerendszerben foglal 500 megát. Mivel file olvasásnál/írásnál a proci amit a kibe tömörítéshez használ elhanyagolható (pedig a zlib a lassabb van használva), gyakorlatilag 2x gyorsabb winyó írás/olvasás :) SSD nél ez nem számít, ott viszont a hely igen. Nekem egy 30 gigás ssdm van, nincs kedvem kiszámolni mennyi adat van rajta ebben a formában (usr és home) de nem 30 giga azt megmondom. :)
Nodatacow nál a meta adat még cow azért, csak az adat nem, tehát egy 100 gigás virtuális gép image file "sorban" van a winyón, akkor ha a virt gép a közepébe ír egy blokkot, akkor az a winyón fizikailag tök máshova kerül, nodatacownál meg oda, ahol eredetileg volt. Annyiban tényleg elveszti a btrfs az értelmét, hogy ilyenkor nincs checksum ellenőrzés, és a file tartalom sem garantált szabálytalan leállásnál. Viszont pl. snapshot, online méretezés, meg egyéb managelhető dolgok megmaradnak azért, ami nem rossz! Ja igen, compress sem lehet a nodatacow al együtt sajnos :)
>> Ami lassú az az fsync, úgyhogy ami sok fsync et használ, pl. mysql innodb, ott a btrfs lassú >> lesz. Erre van egykét megoldás, amit nem írok le ide, mert új vitákat generálna, stb. :)
> Engem erdekelnek a tapasztalataid, plane ha egy kulon threadbe irnad.
Jó, röviden: innodb insertnél fsync et meghívja, ami btrfsnél sokkal lassabb, mint mondjuk ext4nél. A valóságban ez azt jelenti, hogy nagyságrendileg, egy tömeges insert innodbbe tetszőleges finomhangolással (buffer méret stb.) mondjuk 15 perc btrfsnél. Kb. 5 perc ext4nél, ami még mindig sok szvsz, ezért én azt csináltam, hogy a mysql init scriptbe beraktam a libeatmydata libet, ami kihagyja az fsyncet, és így az idő lement 30 mp alá... Na és ez az amiért nem akartam ezt kiírni, ha nincs rá külön érdeklődés, mert itt mindenki lehülyéz, hogy ezzel oda az adatbiztonság, amire viszont leírom:
1.: nincs olyan adatbázis hosztolva nálam, ahol kritikus lenne egy tranzakció rögzítése. Attól, hogy minden fostos wordpress oldal innodbt meg tranzakciot, garantált lemezre írást használ, és ettől erőforrás igényes is, attól még nem lesz fontos, hogy a debug logjába bekerül e egy kínai login kísérlet vagy nem. :D
2.: replikálva van a mysql, és egy szabálytalan leállás után a korábbi slave lesz a master, és az első szabáyltalanul leállított mysql adatai mennek a kukába, ha az "új" slaveről sikerül visszaállítani a jó állapotot. Tehát nincs jelentősége, hogy egy elszállt szerveren konzisztens állapot marad-e (ami egyébként tapasztalat szerint így van), mert úgyis felül lesz írva az élő adattal.
> A panaszkodason kivul nalam gondot nem okoz, a boot folyamat folytatodik rendben.
Ez tény, és azt a rinyát is ki lehet kapcsolni, viszont két oka van, hogy nem szoktam mégse:
1.: 1 gigás boot partíció kb tökmind1 hogy milyen fs, nem oszt nem szoroz, se sebesség, se méret
2.: ez gentoon nem probléma, viszont ubuntunál igen, és mivel én ubuntut nem használok, csak másoknak telepítgetem, meg optimalizálom (pl. btrfs-re alakítással) ezért ott zavaró, ha egy frissítés után pl. újra jön a press any key rinya boot előbb. Ez nagyon kis probléma, de azért gondoltam megemlítem.