Message-Id: <044ADDD7-D7C0-4E27-B9E7-E576CDEDD1C4@dilger.ca>
Date:   Wed, 12 Jun 2019 14:40:18 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>,
        Li Dongyang <dongyangli@....com>
Subject: Re: fsck doesn't seem to understand inline directories

On Jun 12, 2019, at 8:07 AM, Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> 
> Doing a forced check on an ext4 file system with inline_data results in
> lots of warnings - and I think answering yes to "fixing" those would
> actually corrupt the fs.

Rasmus,
This definitely seems like a bug in e2fsck.  It isn't totally surprising, since
the inline_data feature is not widely used.  We are currently investigating using
it for regular files, but it doesn't seem worthwhile for directories to me.

Would you be interested to take a look at fixing this?  It seems like it would be
mostly a matter of adding checks for the EXT2_INLINE_DATA_FL in the various parts
of e2fsck that are generating the errors, then encapsulating the test script below
into a new test case for e2fsck.

While there are a few test cases for inline_data (tests/f_inline{data,dir}_*),
it seems they are all checking for corrupted inline files or directories, and
not for "valid" inline directories.

It _may_ also be that this is a recent regression, so it wouldn't hurt to try
your test case with an older version (e.g. 1.43.1 or 1.42.13) to see if it was
working, and if yes use "git bisect" to track it down.  That would make it pretty
urgent to fix, since the new e2fsck-1.45.2 release would suddenly corrupt any
existing inline_data filesystems.

If this didn't work in 1.43.1 or 1.42.13 then it seems unlikely that anyone is
using inline_data at all, so while it would be good to fix this bug it isn't
nearly as urgent.

Cheers, Andreas

> To reproduce:
> 
> truncate -s 100000000 ext4.img
> misc/mke2fs -t ext4 -b 4096 -I 512 -O
> '^dir_nlink,extra_isize,filetype,^huge_file,inline_data,large_file,large_dir,^meta_bg,^project,^quota,^resize_inode,sparse_super,64bit,metadata_csum_seed,metadata_csum'
> -U random -v ext4.img
> mkdir m
> sudo mount ext4.img m
> sudo chown $USER:$USER m
> mkdir m/aa
> echo 123 > m/aa/123
> touch m/aa/empty
> seq 10000 > m/aa/largefile
> mkdir m/aa/bb
> mkdir m/cc
> sudo umount m
> e2fsck/e2fsck -f -n ext4.img
> 
> The last command gives this output:
> 
> -----
> e2fsck 1.45.2 (27-May-2019)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> '..' in /aa (12) is <The NULL inode> (0), should be / (2).
> Fix? no
> 
> Unconnected directory inode 16 (/aa/bb)
> Connect to /lost+found? no
> 
> '..' in /cc (17) is <The NULL inode> (0), should be / (2).
> Fix? no
> 
> Pass 4: Checking reference counts
> Inode 2 ref count is 5, should be 3.  Fix? no
> 
> Inode 12 ref count is 3, should be 1.  Fix? no
> 
> Unattached inode 13
> Connect to /lost+found? no
> 
> Unattached zero-length inode 14.  Clear? no
> 
> Unattached inode 14
> Connect to /lost+found? no
> 
> Unattached inode 15
> Connect to /lost+found? no
> 
> Unattached inode 16
> Connect to /lost+found? no
> 
> Inode 17 ref count is 2, should be 1.  Fix? no
> 
> Pass 5: Checking group summary information
> 
> ext4.img: ********** WARNING: Filesystem still has errors **********
> 
> ext4.img: 17/24416 files (5.9% non-contiguous), 4096/24414 blocks
> -----
> 
> Am I doing something wrong? The kernel mounting the fs above is 4.15, in
> case that matters.
> 
> Rasmus


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)

Powered by blists - more mailing lists