Administrace komentářů

Tohle je naprostý nesmysl a naprosté nepochopení, k čemu u starých a špatných souborových systému (ne)sloužil fsck.

Já si myslím, že fsck slouží ke zjištění a opravě (potenciálně se ztrátou dotčených souborů, které si obnovíš ze zálohy) souborového systému, u kterého se poškodily invarianty datových struktur (že listy stromů a pointery hashtables neukazují na nesmyslná místa, že jsou všechny bloky označené jako alokované dostupné, a já nevím co vlastně FS dělá). Koneckonců teď jsem si otevřel manuál k btrfs fsck a tam se píše přesně tohle:

The filesystem checker is used to verify structural integrity of a filesystem and attempt to repair it if requested. The structural integrity check verifies if internal filesystem objects or data structures satisfy the constraints, point to the right objects or are correctly connected together. There are several cross checks that can detect wrong reference counts of shared extents, backreferences, missing extents of inodes, directory and inode connectivity etc.

No a problém je v tom, že se na té stejné stránce píše taky

Warning

Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.

Jako možná už to funguje, už jsem to nějakou dobu nezkoušel. Ale s těmi varováními to nepůsobí moc důvěryhodně. Samozřejmě je možné, že autoři btrfs mají jinou hranici toho, před čím považují za nutné varovat, a ve skutečnosti to funguje stejně dobře jako fsck klasických fs.

A kdy třeba se takový fsck může použít? Třeba když máš filesystém, který projde scrubem, a přitom se na něm děje tohle:

root@ferda:~/psql_bonanza_backup# ls pg_stat_tmp/
db_0.stat  db_0.stat  db_0.stat  db_0.stat    global.stat  global.stat	global.stat  global.stat  global.tmp  global.tmp  global.tmp  global.tmp
db_0.stat  db_0.stat  db_0.stat  global.stat  global.stat  global.stat	global.stat  global.tmp   global.tmp  global.tmp  global.tmp
root@ferda:~/psql_bonanza_backup# ls -l pg_stat_tmp/
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
total 0
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp

Jak to mohlo vzniknout? Třeba softwarovým bugem (race condition…), hardwarovým bugem disku (HW kecá co už zapsal a co ještě ne a přehazuje pořadí zápisů) nebo hardwarovým bugem paměti či procesoru (stroj nemá ECC, na stroji se přehřívá CPU a dělá chyby).

S čím tady srovnáváme? Co je baseline? Takže, co přesně je ten svatý grál, který funguje lépe než Btrfs a ZFS?

Baseline je, že na ext4 pustím fsck, a ono se to ve většině případů dostane do konzistentního stavu. Možná to přijde o pár souborů, ty obnovím ze zálohy. Pokud to bylo fakt hodně špatný, tak pak je samozřejmě lepší FS zrušit a vytvořit znova.

S Ext4 bude tahle „nahranost“ mnohem horší a pravděpodobnost rozbití mnohem vyšší.

Nebo nebude, protože je jednodušší a tak tam je méně věcí co se můžou rozbít (to není výtka na btrfs, pokud chceš mít všechny ty funkce, co btrfs poskytuje, tak to prostě složité být musí). Nebo nebude protože je víc otestovaný. A nebo samozřejmě bude, pokud je tvým problémem zrovna ten typ selhání disku který zachytí btrfs checksum.