Andreas Dilger wrote:
On Jan 20, 2017, at 12:14 PM, Damien Guibouret <damien.guibouret@xxxxxxxxxxxxxxxxxxxx> wrote:
Theodore Ts'o wrote:
On Wed, Jan 18, 2017 at 03:21:28AM -0500, George Spelvin wrote:
I was trying to rmdir an empty directory in lost+found that accumulated
during my recent problems.
EXT4-fs (md3): mounted filesystem with writeback data mode. Opts: data=writeback,delalloc
$ cd /mountpoint/lost+found
$ rmdir \#1625089/
------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:1943!
debugfs: stat <1625089>
Inode: 1625089 Type: directory Mode: 0775 Flags: 0x10000000
Generation: 927350643 Version: 0x00000000:00000004
User: 1000 Group: 161 Project: 0 Size: 132
File ACL: 1664090185 Directory ACL: 0
Links: 0 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x587f2034:472c74ec -- Wed Jan 18 02:58:44 2017
atime: 0x56b9e2f8:b68a7658 -- Tue Feb 9 08:00:40 2016
mtime: 0x56c1bc4b:a7765de8 -- Mon Feb 15 06:53:47 2016
crtime: 0x56ba9eb4:a51d90ac -- Tue Feb 9 21:21:40 2016
Size of extra inode fields: 32
Extended attributes:
system.data (72)
Inode checksum: 0xe2f12fc5
Size of inline data: 132
OK, so the problem seems the inode in question has the INLINE_DATA
flag set, but i_blocks is non-zero. And it looks like the data was
actually stored in an exernal data block, and the in-line xattr wasn't
present.
e2fsck should be checking and complaining if this is the case. If
not, it's a bug in e2fsck.
And the kernel certainy shouldn't be BUG'ing when it comes across
what is clearly a case of file system corruption.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
Perhaps I am wrong, but as the inode has a file ACL, the blockcount should be
different from 0? So it seems valid on this point. Or is there something that
prevent inlined file to have ACL?
The "File ACL" label is misleading. ACLs are stored as xattrs, (along with other
xattrs like SELinux labels), and also inline data. However, unless the ACL is
very large it would also be stored inside the inode itself. If there isn't space
inside the inode to store both the inline data and other xattrs, the inline data
should be bumped to an external block first (i.e. stored as a regular file),
since there is no benefit to doing the reverse.
Cheers, Andreas
I certainly do not have a complete knowledge on how it works, but the
ext4_xattr_set_handle function does not try to move inline data to a block
before allocating a new block for the extended attribute (or reusing a block if
there is one with similar content). And some of its call tree does not clear
inline data before.
A case could be some directory creation that inherits big posix ACL from its
parent (ACL goes to a block, potentially the same than the one of its parent)
and the directory is created with inline data.
In the ext4_getattr function there is also some comment that says it can happen
"If there is inline data in the inode, the inode will normally not have data
blocks allocated (it may have an external xattr block)."
Regards,
Damien
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
