ext4 wrote extents on ext2 fs?

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

I'm running - on an oldish kernel 3.14.26 - an ext2 filesystem with the
ext4 module, on a 1GB USB pendrive. Today the system failed to come up
properly (it's a small router providing my internet connectivity) and
this is what e2fsck had to say about the filesystem:

# e2fsck /dev/sdb1 
e2fsck 1.42.12 (29-Aug-2014)
extroot contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 15817 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15818 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15819 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15820 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15821 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15822 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15823 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 15824 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes

Deleted inode 31403 has zero dtime.  Fix<y>? yes
Pass 2: Checking directory structure
Entry 'screenrc' in /etc (15701) has deleted/unused inode 15820.  Clear<y>? yes
Entry 'usb-serial' in /etc/modules.d (15742) has deleted/unused inode 15817.  Clear<y>? yes
Entry '09-llc' in /etc/modules.d (15742) has deleted/unused inode 15818.  Clear<y>? yes
Entry '51-ltq-vdsl-vr9' in /etc/modules.d (15742) has deleted/unused inode 15821.  Clear<y>? yes
Entry '50-ltq-vdsl-vr9-mei' in /etc/modules.d (15742) has deleted/unused inode 15822.  Clear<y>? yes
Entry 'nf-conntrack' in /etc/modules.d (15742) has deleted/unused inode 15823.  Clear<y>? yes
Entry '10-ltq-ifxos' in /etc/modules.d (15742) has deleted/unused inode 15824.  Clear<y>? yes
Entry 'root' in /etc/crontabs (15874) has deleted/unused inode 15819.  Clear<y>? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -734 -(2673--2688) -(3120--3167) -(3200--3207) -68107 -68144 -(165465--165470)
Fix<y>? yes
Free blocks count wrong for group #0 (28194, counted=28267).
Fix<y>? yes
Free blocks count wrong for group #2 (30626, counted=30628).
Fix<y>? yes
Free blocks count wrong for group #5 (31297, counted=31303).
Fix<y>? yes
Free blocks count wrong (238639, counted=238720).
Fix<y>? yes
Inode bitmap differences:  -(15817--15824) -31403
Fix<y>? yes
Free inodes count wrong for group #2 (7533, counted=7541).
Fix<y>? yes
Free inodes count wrong for group #4 (7779, counted=7780).
Fix<y>? yes
Free inodes count wrong (60825, counted=60834).
Fix<y>? yes
extroot: ***** FILE SYSTEM WAS MODIFIED *****
extroot: 1886/62720 files (5.8% non-contiguous), 12160/250880 blocks


As you can see, the inodes that somehow ended up with extents were
deleted in the process of this - perhaps this shouldn't actually have
been a problem for ext4 reading the filesystem? However, based on the
symptoms of the device failure I reckon that the contents of those files
was corrupted.

I'd normally write it off to unreliable USB storage and the unreliable
system in general, however, losing 8 continuous inodes with the exact
same symptom has me a bit reluctant to do so.

Unfortunately, even though I could have, I didn't capture the filesystem
in the corrupted state, nor did I even mount it with ext4 and verify
that the files really were empty/corrupted, however I'm sure that at
least the *ltq* ones weren't usable by the system as intended.

Perhaps this is just a consequence of check ordering though - maybe if
the inode flags get corrupted then the EXTENTS flag is just the first
one that will be tested in the e2fsck code?

Anyway - make of it what you will. I might convert the filesystem to
full ext4 just in case though :-)

johannes