Message-Id: <04BDD82D-B764-49A8-9F5B-71303BE96857@dilger.ca>
Date:   Mon, 1 May 2017 16:00:02 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     George Spelvin <linux@...encehorizons.net>,
        Zheng Liu <wenqing.lz@...bao.com>
Cc:     linux-ext4@...r.kernel.org, tytso@....edu
Subject: Re: More inline data oddities

Add the original inline data author Zheng Liu <wenqing.lz@...bao.com>.

On May 1, 2017, at 11:40 AM, George Spelvin <linux@...encehorizons.net> wrote:
> 
> The new e2fsck 1.43.4 (31-Jan-2017) has definitely helped, but I'm
> still seeing some flakiness with inline_data directories.  There's still
> a kernel problem, which is creating file systems that confuse e2fsck.
> 
> But I have more data on the e2fsck problem which is mis-correcting that
> problem so it takes a second run to get a clean file system.
> 
> Specifically, e2fsck is creating the missing system.date problem on one
> run and then zeroing out the directory on another.
> 
> The problem is occurring when I rsync to a small directory.  Consider
> the following directories:
> 
> 1461410  (12) .    1421827  (12) ..    1461583  (20) potd-800.jpg
> 1472133  (36) .xvpics    1461401  (72) .potd-800.jpg.4176
> 
> 1461314  (12) .    1421827  (12) ..    1461426  (20) potd-800.jpg
> 1463943  (36) .xvpics    1461400  (72) .potd-800.jpg.4176
> 
> During the rsync run, I got syslog complaints:
> 
> [255031.626936] EXT4-fs warning (device md3): ext4_dirent_csum_verify:352: inode #1461410: comm find: No space for directory leaf checksum. Please run e2fsck -D.
> [255031.626940] EXT4-fs error (device md3): ext4_readdir:198: inode #1461410: comm find: path $PATH1: directory fails checksum at offset 0
> [255035.720542] EXT4-fs warning (device md3): ext4_dirent_csum_verify:352: inode #1461314: comm find: No space for directory leaf checksum. Please run e2fsck -D.
> [255035.720547] EXT4-fs error (device md3): ext4_readdir:198: inode #1461314: comm find: path $PATH2: directory fails checksum at offset 0
> 
> 
> The inline data consists of two parts: 60 bytes in the block pointers which
> hold the first four entries, and 72 bytes in an ea, which holds the fifth and
> last entry.
> 
> debugfs on the directories reveals the following:
> Inode: 1461410   Type: directory    Mode:  0755   Flags: 0x10000000
> Generation: 927521379    Version: 0x00000000:00000007
> User:  1000   Group:    11   Project:     0   Size: 132
> File ACL: 1496481792    Directory ACL: 0
> Links: 3   Blockcount: 8
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> mtime: 0x55016b84:e7729ec8 -- Thu Mar 12 06:33:40 2015
> crtime: 0x56c1c093:0d01b4b4 -- Mon Feb 15 07:12:03 2016
> Size of extra inode fields: 32
> Extended attributes:
>  system.data (72)
> Inode checksum: 0x456bd90c
> Size of inline data: 132
> 
> Inode: 1461314   Type: directory    Mode:  0755   Flags: 0x10000000
> Generation: 927521364    Version: 0x00000000:00000004
> User:  1000   Group:    11   Project:     0   Size: 132
> File ACL: 1496383488    Directory ACL: 0
> Links: 3   Blockcount: 8
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> mtime: 0x55016b84:1670325c -- Thu Mar 12 06:33:40 2015
> crtime: 0x56c1c093:01161e74 -- Mon Feb 15 07:12:03 2016
> Size of extra inode fields: 32
> Extended attributes:
>  system.data (72)
> Inode checksum: 0x008d7abf
> Size of inline data: 132
> 
> 
> If I run e2fsck on that stat, it complains about two things:
> 
> Inode 1461314, i_blocks is 8, should be 0.  Fix<y>? yes
> Inode 1461410, i_blocks is 8, should be 0.  Fix<y>? yes
> i_file_acl for inode 1461314 ($PATH2) is 1496383488, should be zero.
> Clear<y>? yes
> i_file_acl for inode 1461410 ($PATH1) is 1496481792, should be zero.
> Clear<y>? yes
> 
> I don't really understand how those two errors were created in the
> first place.
> 
> However, after saying yes to those, the system.data ea is missing and the
> final entries in each directory get dropped, leading to being dumped
> in loat+found.
> 
> Here's the state after the first e2fsck run completes:
> 
> Inode: 1461410   Type: directory    Mode:  0755   Flags: 0x10000000
> Generation: 927521379    Version: 0x00000000:00000007
> User:  1000   Group:    11   Project:     0   Size: 132
> File ACL: 0    Directory ACL: 0
> Links: 3   Blockcount: 0
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> mtime: 0x55016b84:e7729ec8 -- Thu Mar 12 06:33:40 2015
> crtime: 0x56c1c093:0d01b4b4 -- Mon Feb 15 07:12:03 2016
> Size of extra inode fields: 32
> Inode checksum: 0xcd34b98c
> Size of inline data: 60
> 
> Inode: 1461314   Type: directory    Mode:  0755   Flags: 0x10000000
> Generation: 927521364    Version: 0x00000000:00000004
> User:  1000   Group:    11   Project:     0   Size: 132
> File ACL: 0    Directory ACL: 0
> Links: 3   Blockcount: 0
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> mtime: 0x55016b84:1670325c -- Thu Mar 12 06:33:40 2015
> crtime: 0x56c1c093:01161e74 -- Mon Feb 15 07:12:03 2016
> Size of extra inode fields: 32
> Inode checksum: 0x042ed119
> Size of inline data: 60
> 
> 
> This then leads to a second run complaining about
> 
> Inode 1461314 has INLINE_DATA_FL flag but extended attribute not found.  Truncate<y>?
> 
> If I instead fix it by "ea_set -f /dev/null <1461314> system.data", I get the
> directory back in a relatively unbroken state.  But why is system.data
> being deleted in the first place?


Cheers, Andreas






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

Powered by blists - more mailing lists