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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
