On Tue, Mar 03, 2015 at 05:10:33PM -0500, J. Bruce Fields wrote:
> I'm getting mysterious crashes on a server exporting an xfs filesystem.
>
> Strangely, I've reproduced this on
>
> 93aaa830fc17 "Merge tag 'xfs-pnfs-for-linus-3.20-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs
>
> but haven't yet managed to reproduce on either of its parents
> (24a52e412ef2 or 781355c6e5ae). That might just be chance, I'll try
> again.
I think you'll find that the bug is only triggered after that XFS
merge because it's what enabled block layout support in the server,
i.e. nfsd4_setup_layout_type() is now setting the export type to
LAYOUT_BLOCK_VOLUME because XFS has added the necessary functions to
it's export ops.
> I can also try a serial console or something, but for now I'm not
> getting a lot of information about the crashes.
Really need a stack trace - even a photo of the screen with the
stack trace on it will do for starters. ;)
> The filesystem in question isn't on a block device available to the
> client, but I'm still seeing occasional GETLAYOUT and GETDEVICEINFO
> calls; I suppose the client's getting that far, finding no devices it
> can use, and giving up?
I can't see anything in the XFS code that would obviously cause a
problem - its completely unaware to the state of the visibility
of the underlying block device to the pnfs clients or the error
handling paths that PNFS server/clients might take when the block
device is not visible at the client side....
> Sorry for the incomplete report, I'll pass along more when I have it.
No worries, good to have an early heads up. :)
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|