XFS in a XFS locks up in xfs_ilock

XFS in a XFS locks up in xfs_ilock

[Jan Engelhardt]

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.

This has been observed on 2.6.29-2.6.31.4, probably even earlier.


thanks,
Jan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS in a XFS locks up in xfs_ilock

[Dave Chinner]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs