On Thu, Jan 08, 2015 at 01:43:27PM +0100, Christoph Hellwig wrote:
> On Thu, Jan 08, 2015 at 08:11:40AM +1100, Dave Chinner wrote:
> > So what happens if a grow occurs, then the server crashes, and the
> > client on reboot sees the same generation as before the grow
> > occured?
> The client doesn't really see the generation. It's party of the deviceid,
> which is opaqueue to the client.
> 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
> 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....
> > > So that we can communicate if a device was grown to the client, which
> > > in this case needs to re-read the device information.
> > Why does it need to reread the device information? the layouts that
> > are handled to it are still going to be valid from the server POV...
> The existing layouts are still valid. But any new layout can reference the
> added size, so any new layout needs to point to the new device ID.
> Once the client sees the new device ID it needs to get the information for
> it, which causes it to re-read the device information.