2

In this answer the user @psusi shows a use of e2fsck that I could not find in the documentation: e2fsck /dev/sdc1?offset=2048.

I am trying to use it to check a device (manually failed and removed) from a raid array. Long story short: I know that starting from offset 67108864 of /dev/sdb2 there is an ext4 filesystem, which was not properly unmounted. I have tried the following (always reverting /dev/sdb2 to the same content between different tests).

  1. Running mount /dev/sdb2 -o loop,offset=67108864 /tmp/mnt works fine and I can see using dmesg | tail that it deleted 5 orphaned inodes, fully recovered the filesystem, and mounted it:

    EXT4-fs: 5 orphan inodes deleted
    EXT4-fs: recovery complete
    EXT4-fs: mounted filesystem with ordered data mode. Opts: (null)
    
  2. Similarly, losetup /dev/loop0 --offset 67108864 /dev/sdb2 && e2fsck -n /dev/loop0:

    root: recovering journal
    root: Clearing orphaned inode 1179687 (uid=1000, gid=1000, mode=0100600, size=16384)
    root: Clearing orphaned inode 1179686 (uid=1000, gid=1000, mode=0100600, size=16384)
    root: Clearing orphaned inode 1179685 (uid=1000, gid=1000, mode=0100600, size=32768)
    root: Clearing orphaned inode 1179684 (uid=1000, gid=1000, mode=0100600, size=32768)
    root: Clearing orphaned inode 1179683 (uid=1000, gid=1000, mode=0100600, size=65536)
    root: clean, 225936/4882432 files, 2664100/19514624 blocks
    
  3. I thought that e2fsck -p /dev/sdb2?offset=67108864 would be equivalent to the approach above (using losetup) but instead I get:

    root: recovering journal
    e2fsck: Bad magic number in super-block while trying to re-open root
    root: ********** WARNING: Filesystem still has errors **********
    

    I am sure that e2fsck finds the partition because if I put the wrong value in offset (e.g., 0) I get an error that the filesystem could not be found. Also, if I use e2fsck -p /dev/sdb2?offset=67108864 after any of the approaches 1 or 2, it prints root: clean, ....

I wonder if someone could point me to the documentation for the offset option of e2fsck or help me understand what it does exactly and how this differs from mounting the loopback device with a given offset.

Thanks.

EDIT: Additional information. I can reproduce this behaviour as follows:

dd if=/dev/zero of=/tmp/disk bs=1M count=100
mkfs -t ext4 -E offset=70000000 /tmp/disk
sudo mount -o loop,offset=70000000 /tmp/disk /mnt/
ps > /mnt/test
cp /tmp/disk /tmp/disk2
cp /tmp/disk2 /tmp/disk2.copy
sudo umount /mnt 
e2fsck -p /tmp/disk2?offset=70000000
# /tmp/disk2: recovering journal
# e2fsck: Bad magic number in super-block while trying to re-open /tmp/disk2
# /tmp/disk2: ********** WARNING: Filesystem still has errors **********
sudo mount -o loop,offset=70000000 /tmp/disk2.copy /mnt/
dmesg | tail
# [240760.866274] EXT4-fs (loop3): mounted filesystem with ordered data mode. Opts: (null)
# [240770.516865] EXT4-fs (loop3): recovery complete
# [240770.516869] EXT4-fs (loop3): mounted filesystem with ordered data mode. Opts: (null)
sudo umount /mnt
e2fsck -n /tmp/disk2?offset=70000000
# e2fsck 1.42.13 (17-May-2015)
# Warning: skipping journal recovery because doing a read-only filesystem check.
# /tmp/disk2: clean, 11/25688 files, 8896/102400 blocks
e2fsck -n /tmp/disk2.copy?offset=70000000
# e2fsck 1.42.13 (17-May-2015)
# /tmp/disk2.copy: clean, 11/25688 files, 8896/102400 blocks

As we can see mounting the file recovers the journal (and the file system is then reported as clean by e2fsck), while e2fsck -p throws an error and does not recover the journal.

If this can be useful, here is the difference between the two disk images.

Luca Citi
  • 201

0 Answers0