* More inline data oddities @ 2017-05-01 17:40 George Spelvin 2017-05-01 22:00 ` Andreas Dilger 0 siblings, 1 reply; 4+ messages in thread From: George Spelvin @ 2017-05-01 17:40 UTC (permalink / raw) To: linux-ext4, tytso; +Cc: linux 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: More inline data oddities 2017-05-01 17:40 More inline data oddities George Spelvin @ 2017-05-01 22:00 ` Andreas Dilger 2017-05-03 13:15 ` Zheng Liu 0 siblings, 1 reply; 4+ messages in thread From: Andreas Dilger @ 2017-05-01 22:00 UTC (permalink / raw) To: George Spelvin, Zheng Liu; +Cc: linux-ext4, tytso [-- Attachment #1: Type: text/plain, Size: 5630 bytes --] Add the original inline data author Zheng Liu <wenqing.lz@taobao.com>. On May 1, 2017, at 11:40 AM, George Spelvin <linux@sciencehorizons.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 [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: More inline data oddities 2017-05-01 22:00 ` Andreas Dilger @ 2017-05-03 13:15 ` Zheng Liu 2017-05-06 16:41 ` Damien Guibouret 0 siblings, 1 reply; 4+ messages in thread From: Zheng Liu @ 2017-05-03 13:15 UTC (permalink / raw) To: Andreas Dilger; +Cc: George Spelvin, Zheng Liu, linux-ext4, tytso Hello Andreas, Thanks for letting me know this. Hello George, I have tried to create a ext4 file system with inline_data feature, and try to create a directory hierarchy like you described in the mail. But unfortunately I couldn't reproduce your issue. That would be great if you could provide more details to me, such as the output of the following command. $ debugfs ${DEV} -R 'stats' >From this command I can know which features are enabled in your ext4 file system and that would help me to reproduce the problem. Further, could you please tell me your kernel version? On Mon, May 01, 2017 at 04:00:02PM -0600, Andreas Dilger wrote: > Add the original inline data author Zheng Liu <wenqing.lz@taobao.com>. > > On May 1, 2017, at 11:40 AM, George Spelvin <linux@sciencehorizons.net> wrote: > > [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 It seems that the space is full in inline data and the kernel could not expand it to a new block. From the following message I guess during this process kernel tries to allocate a new block for this directory and then an error is encountered that causes flags 0x10000000 could not have a chance to be cleared. So this inode has flag 0x10000000 and blockcount is 8. > > > > > > 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 ^^^^^^^^^^^^^^^^^ It means that this directory contains inline data > > Generation: 927521379 Version: 0x00000000:00000007 > > User: 1000 Group: 11 Project: 0 Size: 132 > > File ACL: 1496481792 Directory ACL: 0 > > Links: 3 Blockcount: 8 ^^^^^^^^^^^^^ It seems that this directory is currupted because a directory with inline data should be 0. That is why e2fsck wants to fix this issue in first round. I will take a closer look at this problem later, and thanks for reporting this. Regards, - Zheng > > 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 > > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: More inline data oddities 2017-05-03 13:15 ` Zheng Liu @ 2017-05-06 16:41 ` Damien Guibouret 0 siblings, 0 replies; 4+ messages in thread From: Damien Guibouret @ 2017-05-06 16:41 UTC (permalink / raw) To: Zheng Liu; +Cc: Andreas Dilger, Zheng Liu, linux-ext4, tytso Hello, You can quite easily create a directory with inline_data and an not zero block count. Just create a directory and set on it several posix ACL (40 in my case for a 512 bytes inode). Then you get something like: Inode: 12 Type: directory Mode: 0775 Flags: 0x10000000 Generation: 3148309105 Version: 0x00000000:00000006 User: 1000 Group: 1000 Project: 0 Size: 384 File ACL: 7978 Directory ACL: 0 Links: 7 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x590dccec:a9cc6410 -- Sat May 6 15:17:32 2017 atime: 0x590dc07d:1f9f101c -- Sat May 6 14:24:29 2017 mtime: 0x590dccec:a9cc6410 -- Sat May 6 15:17:32 2017 crtime: 0x590dc069:de64cc44 -- Sat May 6 14:24:09 2017 Size of extra inode fields: 32 Extended attributes: system.data (324) system.posix_acl_access (340) Size of inline data: 384 This does not seems an error and in my case e2fsck does not complain. Both inline data content and ACL block are correct. So perhaps is there something else wrong in George's case. Perhaps getting block 1496481792 content could help to check if it has some ACL header or not. Regards, Damien PS: I got some error on George's domain so add to remove it from recipient, hope he could seen it on the list and this one was no sent twice Zheng Liu wrote: > Hello Andreas, > > Thanks for letting me know this. > > Hello George, > > I have tried to create a ext4 file system with inline_data feature, > and try to create a directory hierarchy like you described in the > mail. But unfortunately I couldn't reproduce your issue. That would > be great if you could provide more details to me, such as the output > of the following command. > > $ debugfs ${DEV} -R 'stats' > >>From this command I can know which features are enabled in your ext4 > file system and that would help me to reproduce the problem. Further, > could you please tell me your kernel version? > > On Mon, May 01, 2017 at 04:00:02PM -0600, Andreas Dilger wrote: > >>Add the original inline data author Zheng Liu <wenqing.lz@taobao.com>. >> >>On May 1, 2017, at 11:40 AM, George Spelvin <linux@sciencehorizons.net> wrote: >> >>>[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 > > > It seems that the space is full in inline data and the kernel could not > expand it to a new block. From the following message I guess during > this process kernel tries to allocate a new block for this directory > and then an error is encountered that causes flags 0x10000000 could not > have a chance to be cleared. So this inode has flag 0x10000000 and > blockcount is 8. > > >>> >>>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 > > ^^^^^^^^^^^^^^^^^ > It means that this directory contains inline data > > >>>Generation: 927521379 Version: 0x00000000:00000007 >>>User: 1000 Group: 11 Project: 0 Size: 132 >>>File ACL: 1496481792 Directory ACL: 0 >>>Links: 3 Blockcount: 8 > > ^^^^^^^^^^^^^ > It seems that this directory is currupted because a directory with > inline data should be 0. That is why e2fsck wants to fix this issue > in first round. > > I will take a closer look at this problem later, and thanks for > reporting this. > > Regards, > - Zheng > > >>>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 >> >> >> >> >> > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-06 16:38 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-01 17:40 More inline data oddities George Spelvin 2017-05-01 22:00 ` Andreas Dilger 2017-05-03 13:15 ` Zheng Liu 2017-05-06 16:41 ` Damien Guibouret
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).