From: Alex Buell <alex.buell@munted.org.uk>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.27 BUG at fs/inode.c:263 with ext4
Date: Thu, 15 Jan 2009 00:02:19 +0000 [thread overview]
Message-ID: <20090115000219.3959ea80@lithium.local.net> (raw)
In-Reply-To: <20090114215430.GK6222@mit.edu>
On Wed, 14 Jan 2009 16:54:30 -0500, I waved a wand and this message
magically appears in front of Theodore Tso:
> On Wed, Jan 14, 2009 at 09:01:43PM +0000, Alex Buell wrote:
> > I've been testing ext4 with some spare disks, tonight I created an
> > ext4fs on a USB 60GB hard disk, and backed up my /home partition
> > onto it with rsync.
> >
> > After umounting the device, and switching off the USB connection I
> > got the following in my /var/log/messages.
> >
> > What would this suggest? I'd be happy to supply further information
> > if required.
>
> Can you reproduce this error?
I've just tried with another PATA hard disk over USB. Although there wasn't a BUG, I noticed this in the logs:
Jan 14 23:04:34 lithium usb 1-3.3: USB disconnect, address 14
Jan 14 23:04:34 lithium udevd-event[17345]: unlink_secure: chmod(/dev/bus/usb/001/014, 0000) failed: No such file or directory
Which makes me wonder if you might be right in that it might be a problem with udevd.
> ... and it's apparently coming from udevd when it deletes the device
> node from /dev, which looks like is a tempfs filesystem. That would
> explain the call stack, which shows that clear_inode() was apparently
> called from shmem_delete_inode():
>
> > Jan 14 20:50:00 lithium [<c0157c55>] shmem_delete_inode+0x0/0xae
> > Jan 14 20:50:00 lithium [<c016b6e3>] generic_delete_inode+0x91/0xf9
> > Jan 14 20:50:00 lithium [<c016ae1d>] iput+0x48/0x4a
> > Jan 14 20:50:00 lithium [<c0163a44>] do_unlinkat+0xb0/0x11f
> > Jan 14 20:50:00 lithium [<c0112ace>] do_page_fault+0x23c/0x54a
> > Jan 14 20:50:00 lithium [<c0102cb1>] sysenter_do_call+0x12/0x25
>
> That would imply that there were pages from the block device still in
> the page cache, which I suspect means they were left over from mke2fs
> or fsck, or some other program directly accessing the block device
> directly. I wonder if this BUG can be triggered if a process has an
> open file descriptor on the device at the time when it's powered off,
> or pulled from the system?
After that message in the /var/log/messages file, I tried a couple of times, could not reproduce anything at all. I think that this probably is a udevd problem. But I do add that before I used the disks, I did run mkfs.ext4 to create the filesystem, and also a few fsck.ext4 runs, all of which completed without problems.
I am currently running another rsync task with the disk at the moment.
--
http://www.munted.org.uk
Fearsome grindings.
prev parent reply other threads:[~2009-01-15 0:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-14 21:01 2.6.27 BUG at fs/inode.c:263 with ext4 Alex Buell
2009-01-14 21:54 ` Theodore Tso
2009-01-15 0:02 ` Alex Buell [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=20090115000219.3959ea80@lithium.local.net \
--to=alex.buell@munted.org.uk \
--cc=linux-kernel@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 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.