From: David Chinner <dgc@sgi.com>
To: Balbir Singh <balbir@in.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Per-superblock unused dentry LRU lists V2
Date: Fri, 26 May 2006 10:24:05 +1000 [thread overview]
Message-ID: <20060526002405.GL8069029@melbourne.sgi.com> (raw)
In-Reply-To: <20060525081312.GE8069029@melbourne.sgi.com>
On Thu, May 25, 2006 at 06:13:12PM +1000, David Chinner wrote:
> On Thu, May 25, 2006 at 12:22:20PM +0530, Balbir Singh wrote:
> > On Thu, May 25, 2006 at 04:33:50PM +1000, David Chinner wrote:
> > > On Thu, May 25, 2006 at 04:15:53PM +1000, David Chinner wrote:
> > > >
> > > > FWIW, this create/unlink load has been triggering reliable "Busy
> > > > inodes after unmount" errors that I've slowly been tracking down.
> > > > After I fixed the last problem in XFS late last week, I've
> > > > been getting a failure that i think is the unmount/prune_dcache
> > > > races that you and Neil have recently fixed.
> > >
> > > I just had all 8 filesystems come up with:
> > >
> > > May 25 15:55:18 budgie kernel: XFS unmount got error 16
> > > May 25 15:55:18 budgie kernel: xfs_fs_put_super: vfsp/0xe00000b006339280 left dangling!
> > > May 25 15:55:18 budgie kernel: VFS: Busy inodes after unmount of dm-9. Self-destruct in 5 seconds. Have a nice day...
>
> .....
>
> > > On the second test iteration. On 2.6.16, it takes about 10 iterations to get one
> > > filesystem to do this. I'll need to look into this one further. I'm going to
> > > reboot the machine and run some dbench tests (which typically don't trigger
> > > this problem) and then come back to this one with added debugging....
> >
> > Is this with version 2 of your patch?
>
> That's with version 2 on -rc4-mm3.
>
> > Could you also try the -mm tree
> > and see if the problem goes away. We have a set of patches to address
> > exactly this problem.
>
> Well, the patches overlap and I thought that I had taken into account
> the fixes that were applied to the -mm tree.
>
> I'm rerunning on 2.6.16 with the s_umount locking fix so I know that it's
> not something else in -mm that is being tripped over....
2.6.16 ran all night on the above test with the s_umount locking fix in it.
The prune_dcache/unmount race was indeed the cause of the errors I have
been seeing over the last week.
I just found a bug in the -mm patch which broke shrink_dcache_parent().
This is the likely cause of the above problems, and I'm about to retest
the -mm kernel with the fixed patch.....
Cheers,
Dave.
--
Dave Chinner
R&D Software Enginner
SGI Australian Software Group
prev parent reply other threads:[~2006-05-26 0:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-24 11:00 [PATCH] Per-superblock unused dentry LRU lists V2 David Chinner
2006-05-24 11:00 ` David Chinner
2006-05-25 4:06 ` Balbir Singh
2006-05-25 4:06 ` Balbir Singh
2006-05-25 6:15 ` David Chinner
2006-05-25 6:15 ` David Chinner
2006-05-25 6:29 ` Balbir Singh
2006-05-25 6:33 ` David Chinner
2006-05-25 6:33 ` David Chinner
2006-05-25 6:52 ` Balbir Singh
2006-05-25 6:52 ` Balbir Singh
2006-05-25 8:13 ` David Chinner
2006-05-26 0:24 ` David Chinner [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=20060526002405.GL8069029@melbourne.sgi.com \
--to=dgc@sgi.com \
--cc=balbir@in.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 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.