xfs
[Top] [All Lists]

Re: [PATCH 17/18] xfs: implement pnfs export operations

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 17/18] xfs: implement pnfs export operations
From: Christoph Hellwig <hch@xxxxxx>
Date: Wed, 14 Jan 2015 11:08:27 +0100
Cc: Christoph Hellwig <hch@xxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, Jeff Layton <jlayton@xxxxxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150112030401.GA29484@destitution>
References: <1420561721-9150-1-git-send-email-hch@xxxxxx> <1420561721-9150-18-git-send-email-hch@xxxxxx> <20150107002434.GG31508@dastard> <20150107104010.GD28783@xxxxxx> <20150107211140.GC25000@dastard> <20150108124327.GA15222@xxxxxx> <20150108210405.GG25000@dastard> <20150109114159.GA25728@xxxxxx> <20150112030401.GA29484@destitution>
User-agent: Mutt/1.5.17 (2007-11-01)
On Mon, Jan 12, 2015 at 02:04:01PM +1100, Dave Chinner wrote:
> Ok, so:
> 
> client                                server
> 
> get layout
> dev id == 0
>                               grow
>                               gen++ (=1)
>                               crash
>                               ....
>                               gen = 0 (initialised after boot)
> 
> commit layout
> dev id == 0
>                               server executes op, even though
>                               device has changed....
> 
> What prevents this? Shouldn't the server be rejecting the commit
> layout operation as there was a grow operation between the client
> operations?

There is no need to reject the commit.  Grows for the block layout
driver never invalidate existing layouts, as they are purely grow
operation.  The only reason to bother with the generation is
to ensure that new layouts might point into areas the client
didn't previously known about.  So the interesting variation of your
scenario above is:

client                          server

                                grow
                                gen++ (=1)

get layout
dev id == (x, 1)
                                crash
                                ....
                                gen = 0 (initialised after boot)
 
commit layout
id == 1

Which will be rejected, and the client either choses to get a
new layout / deviceID, or just writes the data back through normal
I/O.

Now one interesting case would be a resize that completed in
memory, gets a layout refering to it send out, but not commited to disk,
and then anothe resize to a smaller size before the commit.  Not
really practical, but if it happend we could get writes beyond the
end of the filesystem.

I didn't assume this was possible as I assumed growfs to be synchronous,
but it turns out while we do various synchronous buffer writes the
transaction isn't actually commited synchronously.

I think we should just make growfs commit the transaction
synchronously to avoid both the pnfs problem, as well as the
problem of growfs potentially updating the secondary superblocks
before the transaction hit the disk.

<Prev in Thread] Current Thread [Next in Thread>