ext2, readonly-mount, not clean - ezt hogy?

Naplózó filerendszerek (journaling)

Sziasztok!

Egy beagyazott ge'p cf-kartyajan van egy ext2 filerendszer, ami normal esetben csak olvashato modon van felcsatolva (mount -o ro ...). Megy is a rendszer. Namost, dd + netcat + ... kombo'val csinalok egy klo'nt errol a rendszerro"l (mondjuk egy masik cf-kartyara, vagy egy sima file-ba lementem egy mezei hdd-re, mindegy). Ez is jo. Nomost, a miheztartas ve'gu"tt, az o"rdo"g nem alszik alapon raengedek erre a klo'nra egy fsck-t. Ez meg azt mondja hogy "fs was not cleanly unmounted, check forced".

A kerdes, roviden: ezt igy hogy? Nem tiszta egy readonly mount?

A.

  • 5313 megtekintés

( bucko | 2013. 11. 21., cs – 21:02 )

Hát ugye megy a rendszer => nem volt umount. Azaz igazat mond a gép.

Csak ott a dolog szépséghibája, hogy normális körülmények között egy read only opcióval mountolt fájlrendszerre nem lenne szabad írnia az op.rendszernek.
Márpedig a jelek szerint beleírt.
(nekem vannak kétségeim - gyanítom, az eredetit felejtették el umountolni még amikor íródott -> image fájllal kipróbáltam, nem produkált semmi hasonlót)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Végeredményben az a "dirty flag" (vagy mi a neve) is a fs része.
Hasogathatjuk a szőrszálakat, ettől még a lényeg megmarad: a fájlrendszeren nem lenne szabad nyomot hagynia az op.rendszernek, ha ro mountoltad.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Szóval akkor érthető, hogy senki sem állította, hogy ÍRT valaki.
Pl.:
(rendszer indul)
mount -o ro
mount -o rw -o remount
írunk vagy sem
mount -o ro -o remount
kikapcs
...
bekapcs
állítás: nem volt umount, nem tudjuk írt-e valaki, nézzük meg nem maradt-e hiba!
Ezt jelenti az üzenet. Nem állítja, hogy írtak, vagy hiba lenne. És talán nincs olyan history, ami a
fenti eseménysort rögzíti, tehát nem tudjuk - ezért kell ellenőrzni. (Mert mintha az ext2 nem journaling lenne.)

Végül a válasz az alapkérdésre: Ellenőrizne kell az fs-t, de ha mountolás során biztosan nincs lehetőség írásra, akkor nem is lesz hiba.

A jelenség ismerős, Van egy pfsense (FreeBSD) tűzfalam, amely ro. Készítettem egy + fs-t. Ha elmegy a villany, arra kell az fsck.

De, valaki írt. Különben honnan tudná az fsck, hogy nem volt umount?
Megesküldni nem mernék rá, de ha egy "-o rw,remount" után kiadsz egy "-o ro,remount"-ot, akkor azt úgy kezeli, mintha megtörtént volna az umount.

"the ext2 filesystem has a special marker in its superblock that tells whether the filesystem was unmounted properly after the previous mount."

http://www.tldp.org/LDP/sag/html/filesystems.html

ui: a "superblock" nem jutott eszembe az előbb.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

The s_state variable is used by the kernel to pass the identification result to third party utilities:

bit 0 of s_state is reset when the partition is mounted and set when the partition is unmounted. Thus, a value of 0 on an unmounted filesystem means that the filesystem was not unmounted properly - The filesystem is not "clean" and probably contains errors.
bit 1 of s_state is set by the kernel when it detects an error in the filesystem. A value of 0 doesn't mean that there isn't an error in the filesystem, just that the kernel didn't find any.
http://www.osdever.net/documents/Ext2fs-overview-0.1.pdf

Ez itt nem írja az ro lehetőséget csak annyit, hogy a kernel mount esetén törli a bitet. Nyelvészkedjünk: a hibaüzenet annyit jelent, amit bele írtak. Aki írta az fs-t: a kernel mount-kor.

root@testmachine:~# diff x.img z.img
root@testmachine:~# mount -o ro,loop x.img /mnt
root@testmachine:~# diff x.img z.img
root@testmachine:~# umount /mnt
root@testmachine:~# diff x.img z.img
root@testmachine:~# mount -o rw,loop x.img /mnt
root@testmachine:~# diff x.img z.img
Binary files x.img and z.img differ
root@testmachine:~# umount /mnt
root@testmachine:~# diff x.img z.img
Binary files x.img and z.img differ

Mondjuk ez csak annyit mutat, hogy a ro opció hatására egyetlen bit sem változik.

update: közben kicsit utánanéztem...
Az ext2 superblock az eszköz 1024. bájtjánál (offset 1024) kezdődik és 1024 byte hosszú.

Ennek megfelelően:
root@testmachine:~# cmp x.img z.img -bl
1073 117 O 207 M-^G
1074 165 u 164 t
1077 4 ^D 3 ^C
root@testmachine:~# mount -o rw,loop x.img /mnt
root@testmachine:~# cmp x.img z.img -bl
1073 41 ! 207 M-^G
1074 173 { 164 t
1077 5 ^E 3 ^C
1083 0 ^@ 1 ^A
root@testmachine:~# umount /mnt
root@testmachine:~# cmp x.img z.img -bl
1073 56 . 207 M-^G
1074 173 { 164 t
1077 5 ^E 3 ^C

Ha ro mountolod, akkor nem változik a superblock. Ha rw, akkor módosul a s_mtime, s_mnt_count, s_state mező (mount time, mount count, fs state), majd umount után a s_state értéke visszaíródik a mount előtti állapotra.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( apal v | 2013. 11. 21., cs – 22:03 )

Na, csinaltam most egy feltucat klonozast, csak ugy, hogy kicsit probaljak a vegere jarni, "hatha okosabbak leszunk" alapon.

Ugy tunik, az van hogy egy "orokletes" unclean allapot beragad akkor is, ha kozben egy (vagy tobb) remount,rw - remount,ro ciklus lemegy. Hiba ettol fuggetlenul nincs a filerendszerben, de attol me'g mert csak ugy felmountolom irasra, meg utana lecsatolom es/vagy atteszem readonly-ra, attol me'g megmarad ez a szoszerint: ``not cleanly unmounted'' statusz.

Kerdes most persze az, hogy ezen a konkret rendszeren hogyan lehet elve'gezni ezt a javitast, anelkul hogy fizikailag kiszedne'm a cf-kartyat. Mivel a rootfs-rol van szo, ezert csak ugy lecsatolni nem lehet... kerdes, hogy reaodnly-kent felcsatolt rendszer blkdev-je're ra lehet e engedni... nyilvan nem annyira egeszseges ;)

Ez úgy működik, hogy a kernel (+initrd) amikor megszerzi a rootfs-t, akkor még nincs mountolva, majd ro.
Eközben be lehet avatkozni és elindítani fsck-t. A másik megoldás meg pendrive, pl puppy linux és fsck.

A fenti hozzászólásom alapján ez teljesen felesleges. Ellenpróbát csak a "cleanly" leállított rendszer más eszközről elindításával lehetne megtenni. És akkor kiderülne, hogy mégis clean.

a nagykönyv szerint felcsatolt /-re nem engedünk rw fsck-t. :]

szerintem kiszedés nélkül esetleg olyat lehetne csinálni, *ha van mentés a kártyáról*, hogy az initrd-be bekerülő rootfs fsck scriptbe beleteszel egy direkt fsck parancsot, hogy mindenképp tisztítsa meg. (talán a /etc/rcS.d/S07checkfs.sh -> ../init.d/checkfs.sh lehet a jó hely erre.) majd utána update-initramfs vagy hasonló és reboot majd néma imák/mandalák ismétlése, amíg el nem kezd újra pingni.