Bug 196677
Summary: | fsck.ext4: unable to set superblock flags, even after mounting ok | ||
---|---|---|---|
Product: | File System | Reporter: | Adam Nielsen (a.nielsen) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.12.4 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Adam Nielsen
2017-08-16 08:14:26 UTC
On Wed, Aug 16, 2017 at 08:14:26AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > > Just had a Raspberry Pi crash, and upon reboot fsck.ext4 was unable to repair > the filesystem. Moving the SD card to a PC and running fsck there showed the > same behaviour. I am not sure what exactly you need to know so please advise > if you need anything else. This is a e2fsprogs bugs, not a kernel bug, but it's fine to discuss it here. Can you send me the output of "dumpe2fs /dev/sdb2", "debugfs -R 'stat <8>' /dev/sdb2", and "debugfs -R logdump /dev/sdb2"? Also could you run: debugfs -R 'dump_inode <8> /tmp/journal.dat' /dev/sdb2 and then send me a copy of /tmp/journal.dat? I'm guessing the journal must be corrupted in some interesting way, since what should have happened if it was just a case of the journal data being present but the superblock flags not being set sould have been: e2fsck 1.43.5 (04-Aug-2017) /tmp/foo.img: recovering journal 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 Free blocks count wrong (26854, counted=24490). Fix? yes Free inodes count wrong (8181, counted=7281). Fix? yes /tmp/foo.img: ***** FILE SYSTEM WAS MODIFIED ***** /tmp/foo.img: 911/8192 files (0.0% non-contiguous), 8278/32768 blocks Cheers, - Ted Just to follow up on this, after performing a couple of troubleshooting steps suggested by Ted, it became apparent that the SD card containing the ext4 filesystem has become read only. Writes succeed without error, but the original data is always returned unmodified. For the benefit of anyone else finding their way here, I was able to verify the problem by making a copy of the filesystem on another device and running fsck on the copy, which succeeded. To avoid needing a lot of disk space for the copy, I used e2image to copy the metadata into a sparse file: $ e2image -r /dev/sdb2 sdb2.e2i e2image 1.43.4 (31-Jan-2017) $ fsck.ext4 sdb2.e2i e2fsck 1.43.4 (31-Jan-2017) sdb2.e2i: recovering journal Setting free inodes count to 902960 (was 903626) Setting free blocks count to 2918014 (was 2920347) sdb2.e2i: clean, 69984/972944 files, 967554/3885568 blocks This only took 180MB of on-disk space instead of the full 15GB. So the underlying cause of this bug is a hardware failure on the SD card. It appears to have gone into some sort of failsafe read-only mode, but unfortunately it doesn't reject write operations, it just discards them. This means the host (and also the user, thanks to caching) does not realise there is a problem unless, like fsck, a program does a verify-after-write and reveals the issue. |