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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
