From: "George Spelvin" <linux@sciencehorizons.net>
To: linux-ext4@vger.kernel.org, tytso@mit.edu
Cc: linux@sciencehorizons.net
Subject: ext4_iget:4740: inode #%ld: block 48: comm find: invalid block
Date: 19 Jan 2017 12:50:59 -0500 [thread overview]
Message-ID: <20170119175059.4570.qmail@ns.sciencehorizons.net> (raw)
In-Reply-To: <20170118082128.2402.qmail@ns.sciencehorizons.net>
This is part of the fallout of previous errors, so I don't know how
it happened, but repeated e2fsck runs (git master, e2fsck 1.43.3.1
(22-Dec-2016)) aren't fixing it, which is at least an error in e2fsck.
I think it's something to do with inline_data. The error is
} else if (!ext4_has_inline_data(inode)) {
if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
if ((S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
(S_ISLNK(inode->i_mode) &&
!ext4_inode_is_fast_symlink(inode))))
/* Validate extent which is part of inode */
ret = ext4_ext_check_inode(inode);
} else if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
(S_ISLNK(inode->i_mode) &&
!ext4_inode_is_fast_symlink(inode))) {
/* Validate block references which are part of inode */
4740--> ret = ext4_ind_check_inode(inode);
}
but I think the !ext4_has_inline_data() check is wrong. I.e. the inode
*does* have inline data but the test is not detecting it, leading
to -EFSCORRUPTED.
debugfs: stat <1171779>
Inode: 1171779 Type: directory Mode: 0775 Flags: 0x10000000
Generation: 2016668288 Version: 0x00000000:00000007
User: 1000 Group: 161 Project: 0 Size: 60
File ACL: 0 Directory ACL: 0
Links: 2 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x587eff35:6e19953c -- Wed Jan 18 00:37:57 2017
atime: 0x56d5943f:bb6e1344 -- Tue Mar 1 08:08:15 2016
mtime: 0x587eff35:6e19953c -- Wed Jan 18 00:37:57 2017
crtime: 0x56d388b6:533e9e7c -- Sun Feb 28 18:54:30 2016
Size of extra inode fields: 32
Inode checksum: 0x82a01dca
Size of inline data: 60
debugfs: ls <1171779>
1171779 (12) . 1171778 (12) .. 1171954 (12) 0 1171955 (12) 1
1171956 (12) 2 1171957 (20) 3
debugfs: ex <1171779>
<1171779>: does not uses extent block maps
debugfs: blocks <1171779>
(i.e. blank line)
It has no blocks allocated, but contains data... must be inline, no?
The EXT4_INODE_INLINE_DATA bit (bit 28) is set, so i_inline_off must
be zero. How could that arise?
Other info:
debugfs: ea_list <1171779>
debugfs: htree <1171779>
htree: Not a hash-indexed directory
debugfs: id <1171779>
0000 fd45 e803 3c00 0000 3f94 d556 35ff 7e58 .E..<...?..V5.~X
0020 35ff 7e58 0000 0000 a100 0200 0000 0000 5.~X............
0040 0000 0010 0700 0000 42e1 1100 f2e1 1100 ........B.......
0060 0c00 0101 3000 0000 f3e1 1100 0c00 0101 ....0...........
0100 3100 0000 f4e1 1100 0c00 0101 3200 0000 1...........2...
0120 f5e1 1100 1400 0101 3300 0000 0000 0000 ........3.......
0140 0000 0000 80ea 3378 0000 0000 0000 0000 ......3x........
0160 0000 0000 0000 0000 0000 0000 ca1d 0000 ................
0200 2000 a082 3c95 196e 3c95 196e 4413 6ebb ...<..n<..nD.n.
0220 b688 d356 7c9e 3e53 0000 0000 0000 0000 ...V|.>S........
0240 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
debugfs: dump <1171779> /tmp/empty
$ xxd /tmp/empty
00000000: 42e1 1100 f2e1 1100 0c00 0101 3000 0000 B...........0...
00000010: f3e1 1100 0c00 0101 3100 0000 f4e1 1100 ........1.......
00000020: 0c00 0101 3200 0000 f5e1 1100 1400 0101 ....2...........
00000030: 3300 0000 0000 0000 0000 0000 3...........
That data is clearly visible in the i_block area of the inode
(starting at offset 0050).
next prev parent reply other threads:[~2017-01-19 17:51 UTC|newest]
Thread overview: 25+ 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 ` George Spelvin [this message]
2017-01-19 22:58 ` Theodore Ts'o
2017-01-20 19:14 ` Damien Guibouret
2017-01-20 19:17 ` Andreas Dilger
2017-01-20 22:24 ` Damien Guibouret
-- strict thread matches above, loose matches on Subject: below --
2017-01-21 13:30 Ext4 deadlock (+lockdep splat) during rsync Theodore Ts'o
2017-01-21 16:45 ` ext4_iget:4740: inode #%ld: block 48: comm find: invalid block George Spelvin
2017-01-23 0:08 ` Theodore Ts'o
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=20170119175059.4570.qmail@ns.sciencehorizons.net \
--to=linux@sciencehorizons.net \
--cc=linux-ext4@vger.kernel.org \
--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).