[PATCH 17/18] xfs: implement pnfs export operations
Dave Chinner
david at fromorbit.com
Sun Jan 11 21:04:01 CST 2015
On Fri, Jan 09, 2015 at 12:41:59PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 09, 2015 at 08:04:05AM +1100, Dave Chinner wrote:
> > > If the client sends the opaqueue device ID that contains the generation
> > > after the grow to a server that had crashed / restarted the server
> > > will reject it as the server starts at zero. The causes the client
> > > to get a new, valid device ID from the server.
> >
> > But if the server fs has a generation number of zero when it
> > crashes, how does the client tell that it needs a new device ID from
> > the server?
> >
> > > Unlike the NFS file hadles which are persistent the device IDs are volatile
> > > handles that can go away (and have really horrible life time rules..).
> >
> > Right. How the clients detect that "going away" when the device
> > generation is zero both before and after a server crash is the
> > question I'm asking....
>
> The server tells the client by rejecting the operation using the
> device ID.
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?
Cheers,
Dave.
--
Dave Chinner
david at fromorbit.com
More information about the xfs
mailing list