On Tue, 29 Nov 2016 10:39:39 -0600
Eric Van Hensbergen <ericvh@xxxxxxxxx> wrote:
> Any idea of what xfstests is doing at this point in time? I'd be a
> bit worried about some sort of loop in the namespace since it seems to
> be in path traversal. Could also be some sort of resource leak or
> fragmentation, I'll admit that many of the regression tests we do are
> fairly short in duration. Another approach would be to look at doing
> this with a different server (over a network link instead of virtio)
> to isolate it as a client versus server side problem (although from
> the looks of things this does seem to be a client issue).
The xfstests part where it hangs is either of these loops:
FILES=1000
for i in `seq 0 1 $FILES`; do
(
sleep 5
xfs_io -f -c "truncate 10485760" $SCRATCH_MNT/testfile.$i
dd if=/dev/zero of=$SCRATCH_MNT/testfile.$i bs=4k conv=notrunc
) > /dev/null 2>&1 &
done
wait
for i in `seq 0 1 $FILES`; do
dd of=/dev/null if=$SCRATCH_MNT/testfile.$i bs=512k iflag=direct > /dev/null 2>&1 &
done
wait
So all what's happening on the 9p is a bunch of reads+opens
on the binaries (sleep, xfs_io, dd) and their .so dependencies
(which includes some readlinks as well apparently).
I also tried building QEMU with tracing support enabled and
according to its own 9p event log the server did end up replying
to each client request (i.e. each v9fs_foo with a given tag was
was matched up with a v9fs_foo_return or a v9fs_rerror)...
so yes, looking more like a client problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
