From: Dave Chinner <david@fromorbit.com> To: "J. Bruce Fields" <bfields@fieldses.org> Cc: linux-nfs@vger.kernel.org, Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com Subject: Re: panic on 4.20 server exporting xfs filesystem Date: Wed, 4 Mar 2015 09:44:56 +1100 [thread overview] Message-ID: <20150303224456.GV4251@dastard> (raw) In-Reply-To: <20150303221033.GB19439@fieldses.org> 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@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: "J. Bruce Fields" <bfields@fieldses.org> Cc: Christoph Hellwig <hch@lst.de>, linux-nfs@vger.kernel.org, xfs@oss.sgi.com Subject: Re: panic on 4.20 server exporting xfs filesystem Date: Wed, 4 Mar 2015 09:44:56 +1100 [thread overview] Message-ID: <20150303224456.GV4251@dastard> (raw) In-Reply-To: <20150303221033.GB19439@fieldses.org> 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@fromorbit.com
next prev parent reply other threads:[~2015-03-03 22:45 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-03 22:10 panic on 4.20 server exporting xfs filesystem J. Bruce Fields 2015-03-03 22:10 ` J. Bruce Fields 2015-03-03 22:44 ` Dave Chinner [this message] 2015-03-03 22:44 ` Dave Chinner 2015-03-04 2:08 ` J. Bruce Fields 2015-03-04 2:08 ` J. Bruce Fields 2015-03-04 4:41 ` Dave Chinner 2015-03-04 4:41 ` Dave Chinner 2015-03-05 13:19 ` Christoph Hellwig 2015-03-05 13:19 ` Christoph Hellwig 2015-03-05 15:21 ` J. Bruce Fields 2015-03-05 15:21 ` J. Bruce Fields 2015-03-08 13:08 ` Tom Haynes 2015-03-08 13:08 ` Tom Haynes 2015-03-04 15:54 ` J. Bruce Fields 2015-03-04 15:54 ` J. Bruce Fields 2015-03-04 22:09 ` Dave Chinner 2015-03-04 22:09 ` Dave Chinner 2015-03-04 22:27 ` J. Bruce Fields 2015-03-04 22:27 ` J. Bruce Fields 2015-03-04 22:45 ` Dave Chinner 2015-03-04 22:45 ` Dave Chinner 2015-03-04 22:49 ` Eric Sandeen 2015-03-04 22:49 ` Eric Sandeen 2015-03-04 22:56 ` Dave Chinner 2015-03-04 22:56 ` Dave Chinner 2015-03-05 4:08 ` J. Bruce Fields 2015-03-05 4:08 ` J. Bruce Fields 2015-03-05 13:17 ` Christoph Hellwig 2015-03-05 13:17 ` Christoph Hellwig 2015-03-05 15:01 ` J. Bruce Fields 2015-03-05 15:01 ` J. Bruce Fields 2015-03-05 17:02 ` J. Bruce Fields 2015-03-05 17:02 ` J. Bruce Fields 2015-03-05 20:47 ` J. Bruce Fields 2015-03-05 20:47 ` J. Bruce Fields 2015-03-05 20:59 ` Dave Chinner 2015-03-05 20:59 ` Dave Chinner 2015-03-06 20:47 ` J. Bruce Fields 2015-03-06 20:47 ` J. Bruce Fields 2015-03-19 17:27 ` Christoph Hellwig 2015-03-19 17:27 ` Christoph Hellwig 2015-03-19 18:47 ` J. Bruce Fields 2015-03-19 18:47 ` J. Bruce Fields 2015-03-20 6:49 ` Christoph Hellwig 2015-03-20 6:49 ` Christoph Hellwig 2015-03-08 15:30 ` Christoph Hellwig 2015-03-08 15:30 ` Christoph Hellwig 2015-03-09 19:45 ` J. Bruce Fields 2015-03-09 19:45 ` J. Bruce Fields 2015-03-20 4:06 ` Kinglong Mee 2015-03-20 4:06 ` Kinglong Mee 2015-03-20 6:50 ` Christoph Hellwig 2015-03-20 6:50 ` Christoph Hellwig 2015-03-20 7:56 ` [PATCH] NFSD: Fix infinite loop in nfsd4_cb_layout_fail() Kinglong Mee 2015-03-20 7:56 ` Kinglong Mee 2015-03-15 12:58 ` panic on 4.20 server exporting xfs filesystem Christoph Hellwig 2015-03-15 12:58 ` Christoph Hellwig 2015-03-16 14:27 ` J. Bruce Fields 2015-03-16 14:27 ` J. Bruce Fields 2015-03-17 10:30 ` Christoph Hellwig 2015-03-17 10:30 ` Christoph Hellwig 2015-03-18 10:50 ` Christoph Hellwig 2015-03-18 10:50 ` Christoph Hellwig 2015-03-27 10:41 ` Christoph Hellwig 2015-03-27 14:50 ` Jeff Layton 2015-03-30 16:44 ` Christoph Hellwig 2015-03-27 15:13 ` J. Bruce Fields 2015-04-26 16:19 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150303224456.GV4251@dastard \ --to=david@fromorbit.com \ --cc=bfields@fieldses.org \ --cc=hch@lst.de \ --cc=linux-nfs@vger.kernel.org \ --cc=xfs@oss.sgi.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.