| To: | Christoph Hellwig <hch@xxxxxx> |
|---|---|
| Subject: | Re: panic on 4.20 server exporting xfs filesystem |
| From: | Tom Haynes <thomas.haynes@xxxxxxxxxxxxxxx> |
| Date: | Sun, 8 Mar 2015 06:08:57 -0700 |
| Cc: | Dave Chinner <david@xxxxxxxxxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, "linux-nfs@xxxxxxxxxxxxxxx" <linux-nfs@xxxxxxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx> |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20150305131901.GB16235@xxxxxx> |
| References: | <20150303221033.GB19439@xxxxxxxxxxxx> <20150303224456.GV4251@dastard> <20150304020826.GD19439@xxxxxxxxxxxx> <20150304044141.GQ18360@dastard> <20150305131901.GB16235@xxxxxx> |
> On Mar 5, 2015, at 5:19 AM, Christoph Hellwig <hch@xxxxxx> wrote: > >> On Wed, Mar 04, 2015 at 03:41:41PM +1100, Dave Chinner wrote: >> As I understand it, nothing will prevent this - if you don't change >> the UUID on the filesystem when you clone it, then the UUID will >> still match and writes can be directed to any block deice with a >> matching offset/UUID pair. > > Unfortunately that's the case indeed. The whole discovery part of > the block layout protocol is fundamentally flawed, as is the recall > part. This is my attempt to fix it, but I have no idea how to proceed > from posting my draft to the IETF to actually making it a standard: > > http://tools.ietf.org/html/draft-hellwig-nfsv4-scsi-layout-00 Let's be sure to talk about this at LSF... |
| Previous by Date: | Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur, Ingo Molnar |
|---|---|
| Next by Date: | Re: panic on 4.20 server exporting xfs filesystem, Christoph Hellwig |
| Previous by Thread: | Re: panic on 4.20 server exporting xfs filesystem, J. Bruce Fields |
| Next by Thread: | Re: panic on 4.20 server exporting xfs filesystem, J. Bruce Fields |
| Indexes: | [Date] [Thread] [Top] [All Lists] |