Administrace komentářů

Proč bych to dělal?

Protože přepsání jedné strany mirroru nulami nebo náhodnými daty je ve skutečnosti dost dobrý příklad toho, co se ve skutečnosti často děje. Obvykle je to nějaká varianta jednoho z následujících scénářů:

1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.

2) LUN, který je součástí mirroru je vyexportovaný z nějakého inteligentního pole, které podporuje klonování LUN, různé snapshoty. No a "admin" se jednoho dne prostě uklikne a místo dalšího snapshotu udělá rollback, nebo si splete směr klonování...

Proč místo toho radši nepřepsat kus paměti náhodnými daty

Vytvořit prakticky nasaditelný (souborový) systém, odolný vůči tomuto vektoru je hodně težké, ale máte pravdu, bylo by krásné ho mít.

nespustit rm -rf --no-preserve-root /

Tak od toho jsou snapshoty, případně další věci jako immutable zony atp.

scrub zkontroluje checksum bloku s metadaty, ale už nezkontroluje, že ta metadata dávají smysl, tj. třeba že to je pořád validní b-strom, že ty pointry neukazují třeba někam dopryč, že jsou pořád dosažitelné všechny soubory atd.

Ano, předpokládáný model je, že souborový systém generuje správná data a ta se případně poškodí pozdějí (na disku, ale i v storage stacku, v transportu atd). U ZFS se předpokládá, že bloky se správným checksumem mají i správný obsah.

fsck u extN atp. musí kontrolovat konzistenci metadata sémanticky, protože nemá jiný způsob, jak ověřit, že jsou správná. To sebou samozřejmě nese mnoho problém - to že nějaký blok vypadá jako uzel b-stromu ještě nemusí nutně znamenat, že to je opravdu správný a aktuální uzel toho správného b-stromu atd.

Samozřejmě, že se může stát (a stává), že je chyba v kódu ovladače souborového systém, ta se ale hladá jinak a jinými nástroji. Když v produkci pomocí fsck zjistíte, že místo b-stromu ovladač vygeneroval graf s cyklem, stejně s tím už toho reálně mnoho nenaděláte.