fsck doesn't seem to understand inline directories

fsck doesn't seem to understand inline directories

[Rasmus Villemoes]

Hi

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. 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

Re: fsck doesn't seem to understand inline directories

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]

On Jun 12, 2019, at 8:07 AM, Rasmus Villemoes <linux@rasmusvillemoes.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






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: fsck doesn't seem to understand inline directories

[Theodore Ts'o]

On Wed, Jun 12, 2019 at 02:40:18PM -0600, Andreas Dilger wrote:
> On Jun 12, 2019, at 8:07 AM, Rasmus Villemoes <linux@rasmusvillemoes.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.

It looks like the problem is the combination of large_dir and
inline_data, and it does look like the problem is in e2fsck (as
opposed to the kernel).

Large_dir is a new feature (even newer than inline_data, and it looks
like the support for large_dir didn't handle the combination with
inline_data correctly).

							- Ted

# mke2fs -t ext4 -O inline_data -Fq /tmp/ext4.img 1G
/tmp/ext4.img contains a ext4 file system
	last mounted on Wed Jun 12 21:47:25 2019
# mount /tmp/ext4.img /mnt ; mkdir /mnt/aa ; umount /mnt
# e2fsck -fn /tmp/ext4.img
e2fsck 1.45.2 (27-May-2019)
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
/tmp/ext4.img: 12/65536 files (0.0% non-contiguous), 12954/262144 blocks

### So everything is fine with just inline_data, but when you
### enable the large_dir features, and rerun e2fsck....

# debugfs -w -R "features large_dir" /tmp/ext4.img 
debugfs 1.45.2 (27-May-2019)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg large_dir inline_data sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
# e2fsck -fn /tmp/ext4.img
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

Pass 4: Checking reference counts
Inode 2 ref count is 4, should be 3.  Fix? no

Inode 12 ref count is 2, should be 1.  Fix? no

Pass 5: Checking group summary information

/tmp/ext4.img: ********** WARNING: Filesystem still has errors **********

/tmp/ext4.img: 12/65536 files (0.0% non-contiguous), 12954/262144 blocks

Re: fsck doesn't seem to understand inline directories

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On Jun 12, 2019, at 7:50 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> 
> On Wed, Jun 12, 2019 at 02:40:18PM -0600, Andreas Dilger wrote:
>> On Jun 12, 2019, at 8:07 AM, Rasmus Villemoes <linux@rasmusvillemoes.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.
> 
> It looks like the problem is the combination of large_dir and
> inline_data, and it does look like the problem is in e2fsck (as
> opposed to the kernel).
> 
> Large_dir is a new feature (even newer than inline_data, and it looks
> like the support for large_dir didn't handle the combination with
> inline_data correctly).

Strange.

Artem, any chance you could look into this?

Cheers, Andreas

> # mke2fs -t ext4 -O inline_data -Fq /tmp/ext4.img 1G
> /tmp/ext4.img contains a ext4 file system
> 	last mounted on Wed Jun 12 21:47:25 2019
> # mount /tmp/ext4.img /mnt ; mkdir /mnt/aa ; umount /mnt
> # e2fsck -fn /tmp/ext4.img
> e2fsck 1.45.2 (27-May-2019)
> 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
> /tmp/ext4.img: 12/65536 files (0.0% non-contiguous), 12954/262144 blocks
> 
> ### So everything is fine with just inline_data, but when you
> ### enable the large_dir features, and rerun e2fsck....
> 
> # debugfs -w -R "features large_dir" /tmp/ext4.img
> debugfs 1.45.2 (27-May-2019)
> Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg large_dir inline_data sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
> # e2fsck -fn /tmp/ext4.img
> 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
> 
> Pass 4: Checking reference counts
> Inode 2 ref count is 4, should be 3.  Fix? no
> 
> Inode 12 ref count is 2, should be 1.  Fix? no
> 
> Pass 5: Checking group summary information
> 
> /tmp/ext4.img: ********** WARNING: Filesystem still has errors **********
> 
> /tmp/ext4.img: 12/65536 files (0.0% non-contiguous), 12954/262144 blocks
> 
> 


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]