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