Dotaz: Poškození souborového systému nedetekovatelné při bootu pomocí fsck

[vasek]

Ahoj. Systém CentOS 6.2 32-bit. / jako LVM oddíl. VG je na /dev/md1. Při vytváření lvm snapshotu jsem si všiml v dmesg opravy osiřelých inodů. Provedl tedy na souborovém systému RO fsck test a dopadl takto:

LANG=C e2fsck -n -f /dev/data/system
e2fsck 1.41.12 (17-May-2010)
Warning!  /dev/data/system is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 394505 was part of the orphaned inode list.  IGNORED.
Inode 394506 was part of the orphaned inode list.  IGNORED.
Deleted inode 524293 has zero dtime.  Fix? no

Inode 524294 was part of the orphaned inode list.  IGNORED.
Inode 524295 was part of the orphaned inode list.  IGNORED.
Inode 524296 was part of the orphaned inode list.  IGNORED.
Inode 524297 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (31459038, counted=31459005).
Fix? no

Inode bitmap differences:  -(394505--394506) -(524293--524297)
Fix? no

Free inodes count wrong (8039856, counted=8039814).
Fix? no


/dev/data/system: ********** WARNING: Filesystem still has errors **********

/dev/data/system: 29264/8069120 files (0.2% non-contiguous), 796962/32256000 blocks

Touch /forcefsck nezabralo, systém ten soubor "jen" odstranil. Proto jsem si upravil /etc/rc.d/rc.sysinit a přidal tam ručně "e2fsck -f -y /dev/data/system", jehož výstup přesměrovávám na předem rw připojený jiný oddíl. Výstup tohoto příkazu je

e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/data/system: 29264/8069120 files (0.2% non-contiguous), 796962/32256000 blocks

tj. jako by byl souborový systém v pořádku. Avšak RO fsck v běžícím systému zase ukáže stejný špatný inody. Přijde mi, že se systém zbláznil, v čem může být problém?

---

---

Odpovědi

[vasek]

A tak ono to dělá j na jiných strojích při kombinaci root filesystem jako rw / ext4. Vadí mi to z toho důvodu, že se vytváří poškozený lvm snapshot. Je nějaká možnost udělat konzistentní snapshot?

[Jack]

Nemuzes delat konktrolu na pripojenem FS! I kdyz je read only, tak zurnaly nejsou zapsany kompletne a podobne dalsi veci - to je duvod proc ti to hazi chyby, pokud chces mit jistotu, nastartuj z live cd a udelej konktrolu na odmountovanem FS!

[vasek]

Takže konzistentní snapshot není možné udělat?

[Jack]

Ale ten snapshot bude normalne v pohode. Si to zkus - udelej snapshot, pak nahod live, obnov snapshot a udelej fsck. Jde proste o to, ze nemuzes kontrolovat jestli je FS konzistentni kdyz se s nim pracuje, data jsou ctena, ev. zapisovana, zurnaluje se, atp.

[vasek]

Však já to zkoušel. Udělal jsem snapshot a připojil ho ro. Pokaždé když toho udělám, tak se opravují stejné inody ve zhotoveném snapshotu.

EXT4-fs (dm-3): orphan cleanup on readonly fs
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 394506
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 394505
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524297
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524296
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524295
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524294
EXT4-fs (dm-3): ext4_orphan_cleanup: deleting unreferenced inode 524293
EXT4-fs (dm-3): 7 orphan inodes deleted
EXT4-fs (dm-3): recovery complete

[Petr Šobáň]

A to proto že to máš ro a nemůže se tam zapisovat.

[vasek]

Když to připojím rw, chová se to stejně.

[Jack]

Nepripojuj to a udelej konktrolu na odpojenem svazku, jak do dubu.

[Petr Šobáň]

Prostě hledá chybu kde není.

[Šangala]

Asi by to chtělo zkusit vícekrát na RW svazku, a jak se to tím celé po..zí|re, tak konečně poslechnete a příště to už budete provádět na odpojeném svazku…

[vasek]

Ale já na snapshotu vůbec neprovádím kontrolu. Tohle se do dmesg zapíše automaticky po připojení toho snapshotu. Podle předchozí odpovědi "Ale ten snapshot bude normalne v pohode. Si to zkus - udelej snapshot, pak nahod live..." jsem pochopil, že by se to stávat nemělo a proto se taky tady ptám.

[Jack]

Hod sem prikazy a vystupy toho jak to pripojujes, resp jak tam nahazujes ten snapshot.

[vasek]

$ sync // toto jsem přidal dodatečně
$ lvcreate -s -L 4G -n system_snapshot /dev/data/system
  Logical volume "system_snapshot" created
$ e2fsck -fy /dev/data/system_snapshot // toto jsem přidal dodatečně
e2fsck 1.41.12 (17-May-2010)
Clearing orphaned inode 394506 (uid=0, gid=0, mode=0100600, size=0)
Clearing orphaned inode 394505 (uid=0, gid=0, mode=0100600, size=0)
Clearing orphaned inode 524297 (uid=27, gid=27, mode=0100600, size=0)
Clearing orphaned inode 524296 (uid=27, gid=27, mode=0100600, size=0)
Clearing orphaned inode 524295 (uid=27, gid=27, mode=0100600, size=0)
Clearing orphaned inode 524294 (uid=27, gid=27, mode=0100600, size=133)
Clearing orphaned inode 524293 (uid=27, gid=27, mode=0100600, size=0)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/data/system_snapshot: ***** FILE SYSTEM WAS MODIFIED *****
/dev/data/system_snapshot: 29321/8069120 files (0.2% non-contiguous), 797174/32256000 blocks
$ mount -o ro /dev/data/system_snapshot /lvm_partitions_ro/system

[vasek]

uid=27, gid=27 má mysql

[michich]

Orphaned inodes nepředstavují žádný problém. Viz např. vysvětlení od Stephena Tweedieho z jednom starém bugreportu.

[R]

Je to normalne.