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).
Running
mount /dev/sdb2 -o loop,offset=67108864 /tmp/mnt
works fine and I can see usingdmesg | 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)
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
I thought that
e2fsck -p /dev/sdb2?offset=67108864
would be equivalent to the approach above (usinglosetup
) 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 usee2fsck -p /dev/sdb2?offset=67108864
after any of the approaches 1 or 2, it printsroot: 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.