From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: ext4_xattr_ibody_find:2180: inode #2669312: comm systemd-journal: corrupted in-inode xattr
Date: Wed, 14 Jul 2021 13:56:02 -0400 [thread overview]
Message-ID: <YO8lMpNOUsLjBqIG@mit.edu> (raw)
In-Reply-To: <CAMdYzYroicgDkWuiQ7Xaw_5aYD9mLkrz8qvE9WwS6mPw9uWe8g@mail.gmail.com>
On Tue, Jul 13, 2021 at 04:52:11PM -0400, Peter Geis wrote:
> > This seems to have fallen through the cracks. Have you managed to fix your
> > filesystem? If not, please obtain filesystem image using e2image (it will
> > contain only fs metadata, not any data), compress it and put it somewhere for
> > download so that we can better diagnose the issue. Thanks!
>
> Unfortunately no I don't have the file system anymore.
> I put about two weeks into trying to fix it, but in the end I had to
> nuke it from orbit.
Sorry we didn't get back to you right away. As Jan said, if this
happens again, it would be really helpful to use e2image. There is a
discussion about this in the e2fsck man page, in the "REPORTING BUGS"
section.
In this specific case where there was an inode with a corrupted
extended attribute stored in the inode, you can use debugfs to print
out the inode data structure:
debugfs: inode_dump testfile
0000 a481 0000 0000 0000 cf23 ef60 d523 ef60 .........#.`.#.`
0020 cf23 ef60 0000 0000 0000 0100 0000 0000 .#.`............
0040 0000 0800 0100 0000 0af3 0000 0400 0000 ................
0060 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
0140 0000 0000 6867 c27f 0000 0000 0000 0000 ....hg..........
0160 0000 0000 0000 0000 0000 0000 9fbc 0000 ................
0200 2000 e8f9 34cc 39ec fcaf ee61 fcaf ee61 ...4.9....a...a
0220 cf23 ef60 fcaf ee61 0000 0000 0000 0000 .#.`...a........
0240 0000 02ea 0401 5400 0000 0000 0600 0000 ......T.........
0260 0000 0000 7465 7374 0000 0000 0000 0000 ....test........
0300 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
0360 0000 0000 0000 0000 7473 7476 616c 0000 ........tstval..
debugfs: inode_dump -x testfile
magic = ea020000, length = 96, value_start =4
offset = 4 (0004), name_len = 4, name_index = 1
value_offset = 84 (0130), value_inum = 0, value_size = 6
name = test
value = tstval
last entry found at offset 24 (0030)
(And if you don't have the pathname to the file, you can also specify
the inode using the inode number in angle brackers, e.g., "inode_dump <12>")
Hopefully this won't happen to you again, but if it does, please do
let us know.
Cheers,
- Ted
prev parent reply other threads:[~2021-07-14 17:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 12:36 ext4_xattr_ibody_find:2180: inode #2669312: comm systemd-journal: corrupted in-inode xattr Peter Geis
2021-07-13 15:43 ` Jan Kara
2021-07-13 20:52 ` Peter Geis
2021-07-14 17:56 ` Theodore Y. Ts'o [this message]
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=YO8lMpNOUsLjBqIG@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pgwipeout@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.