From: Damien Guibouret <damien.guibouret@partition-saving.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: George Spelvin <linux@sciencehorizons.net>, linux-ext4@vger.kernel.org
Subject: Re: kernel BUG at fs/ext4/inline.c:1943!
Date: Fri, 20 Jan 2017 20:14:29 +0100 [thread overview]
Message-ID: <58826195.60004@partition-saving.com> (raw)
In-Reply-To: <20170119225830.ihoia75rhy2em27x@thunk.org>
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@vger.kernel.org
> 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?
Regards,
Damien
next prev parent reply other threads:[~2017-01-20 19:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 3:49 [PATCH 0/4] ext4 inline cleanup patches Theodore Ts'o
2017-01-12 3:49 ` [PATCH 1/4] ext4: add debug_want_extra_isize mount option Theodore Ts'o
2017-01-12 19:19 ` Andreas Dilger
2017-01-13 2:58 ` Theodore Ts'o
2017-01-12 3:49 ` [PATCH -v2] overlay: stress test changes to top and bottom layers simultaneously Theodore Ts'o
2017-01-12 3:54 ` Theodore Ts'o
2017-01-12 3:49 ` [PATCH 2/4] ext4: fix deadlock between inline_data and ext4_expand_extra_isize_ea() Theodore Ts'o
2017-01-20 13:53 ` Jan Kara
2017-01-22 22:25 ` Theodore Ts'o
2017-01-24 12:27 ` Jan Kara
2017-01-25 1:32 ` Theodore Ts'o
2017-01-12 3:49 ` [PATCH 3/4] ext4: avoid calling ext4_mark_inode_dirty() under unneeded semaphores Theodore Ts'o
2017-01-20 13:37 ` Jan Kara
2017-01-12 3:49 ` [PATCH 4/4] ext4: propagate error values from ext4_inline_data_truncate() Theodore Ts'o
2017-01-20 13:39 ` Jan Kara
2017-01-12 9:12 ` [PATCH 0/4] ext4 inline cleanup patches George Spelvin
2017-01-12 14:46 ` Theodore Ts'o
2017-01-18 8:21 ` kernel BUG at fs/ext4/inline.c:1943! George Spelvin
2017-01-19 17:50 ` ext4_iget:4740: inode #%ld: block 48: comm find: invalid block George Spelvin
2017-01-19 22:58 ` kernel BUG at fs/ext4/inline.c:1943! Theodore Ts'o
2017-01-20 19:14 ` Damien Guibouret [this message]
2017-01-20 19:17 ` Andreas Dilger
2017-01-20 22:24 ` Damien Guibouret
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58826195.60004@partition-saving.com \
--to=damien.guibouret@partition-saving.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux@sciencehorizons.net \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).