On Fri, Oct 23, 2009 at 08:02:08PM +0200, Jan Engelhardt wrote:
> 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?