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.
Starting out with $HOME being on xfs (truncate is coreutils 7+):
$ 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-220.127.116.11, probably even earlier.