xfs
[Top] [All Lists]

Re: XFS in a XFS locks up in xfs_ilock

To: Jan Engelhardt <jengelh@xxxxxxxxxx>
Subject: Re: XFS in a XFS locks up in xfs_ilock
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 24 Oct 2009 13:41:24 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <alpine.LSU.2.00.0910231957570.5688@xxxxxxxxxxxxxxx>
References: <alpine.LSU.2.00.0910231957570.5688@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Fri, Oct 23, 2009 at 08:02:08PM +0200, Jan Engelhardt wrote:
> Hi,
> 
> 
> it seems that somewhere, locking is afoul in XFS so that having a 
> loopback XFS on an XFS causes a deadlock, first on the subvolume, then 
> on the real one. Sometimes that happens within writing a few MB to the 
> subvolume (the loop one), sometimes nothing happens and it can be used 
> for many months.
> 
> Suggested testcase:
> 
> Starting out with $HOME being on xfs (truncate is coreutils 7+):
> $ >disk
> $ truncate --size=$[3*1048576*1024] disk
> So it's actually sparse(!)
> $ mkfs.xfs disk
> # mount disk mnt -oloop
> 
> Start filling it with data, preferably something like installing a bunch 
> of rpm/debs into mnt, and hopefully soon enough, the thing will lock up.
> xfs_ilock I got from `ps xaf -o wchan` while a box was shortly before 
> dying - processes were stuck in D state. Not sure if this is related to 
> the sparseness of the file, but I would bet it's part of the problem.

Can you provide the output of sysrq-w (echo w > /proc/sysrq-trigger)
so we can see stacks of the threads stuck in D state?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>