From: Theodore Ts'o <tytso@mit.edu>
To: bugzilla-daemon@bugzilla.kernel.org
Cc: linux-ext4@vger.kernel.org, jfaulkne@ccs.neu.edu
Subject: Re: [Bug 61631] kernel BUG at fs/ext4/super.c:818 umounting md raid6 volume
Date: Thu, 19 Sep 2013 14:58:01 -0400 [thread overview]
Message-ID: <20130919185801.GA5677@thunk.org> (raw)
In-Reply-To: <bug-61631-13602-QH4wnakS4K@https.bugzilla.kernel.org/>
On Wed, Sep 18, 2013 at 10:27:02PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> FYI, this bug only appears after some period of usage. After a reboot, I can
> umount without error. After a reboot and an rsync of the gentoo portage tree
> to the filesystem, I can still umount without error. It seems the filesystem
> only fails to unmount after the filesystem has been in use for a while.
> However, it is quite consistent in failing to umount after several days of
> usage.
Hmm, can you say a bit more about what sort of files you store on the
file system and how the file system gets used? What looks like is
going on is that there is a whole series of inodes that have been left
stalled on the orpaned inode list. By the time we reach that point in
the unmount, the in-memory orphan list should have been cleared.
So here are a couple of things that would be really useful to try.
First of all, if you could try to reproduce the crash, and then before
you do the umount, run "dumpe2fs -h /dev/md1 > ~/dumpe2fs.md1.save;
sync". Then if the system crashes with the same BUG_ON, send us the
dumpe2fs.md1.save, along with the console output.
The thing which I am trying to determine is whether the on-disk
orphaned inode list is set at the time of the umount. If it is set,
it would be interesting if you could run sync, wait for things to
settle, check to see if dumpe2fs shows that the orphaned list is
empty, and then see if you can trigger the crash.
The other thing that would be useful is to grab one of the inodes
listed in the console, i.e.:
[642473.269223] inode md1:20289506 at ffff88000499aed0: mode 100644, nlink 0, next 20367069
... and then run the command: "debugfs -R 'stat <20289506>' /dev/md1"
What I am interested in is the inode's atime/ctime/dtime. It would be
interesting to see if the file was deleted right before the umount was
attempted.
Thanks for the bug report! Hopefully we'll be able to figure out why
you are seeing this.
Cheers,
- Ted
next prev parent reply other threads:[~2013-09-19 18:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-18 22:05 [Bug 61631] New: kernel BUG at fs/ext4/super.c:818 umounting md raid6 volume bugzilla-daemon
2013-09-18 22:06 ` [Bug 61631] " bugzilla-daemon
2013-09-18 22:07 ` bugzilla-daemon
2013-09-18 22:10 ` bugzilla-daemon
2013-09-18 22:27 ` bugzilla-daemon
2013-09-19 18:58 ` Theodore Ts'o [this message]
2013-09-19 0:58 ` bugzilla-daemon
2013-09-19 19:20 ` bugzilla-daemon
2013-09-20 22:41 ` bugzilla-daemon
2013-09-21 2:08 ` bugzilla-daemon
2013-09-21 2:11 ` bugzilla-daemon
2013-10-12 0:14 ` bugzilla-daemon
2013-10-12 0:17 ` bugzilla-daemon
2013-10-12 0:17 ` bugzilla-daemon
2013-10-12 0:19 ` bugzilla-daemon
2013-10-12 0:21 ` bugzilla-daemon
2013-10-15 7:58 ` bugzilla-daemon
2013-10-15 7:58 ` bugzilla-daemon
2013-10-15 7:58 ` bugzilla-daemon
2013-10-15 7:59 ` bugzilla-daemon
2013-10-15 8:04 ` bugzilla-daemon
2013-10-20 2:10 ` bugzilla-daemon
2013-10-20 22:32 ` bugzilla-daemon
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=20130919185801.GA5677@thunk.org \
--to=tytso@mit.edu \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=jfaulkne@ccs.neu.edu \
--cc=linux-ext4@vger.kernel.org \
/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).