Hi Eric, (side note: my mutt tells me that the signature on your message does not validate. Not sure what's going on, but something you might want to look into...)
On Thu, Jan 12, 2017 at 12:45:56PM -0600, Eric Blake wrote: > For resize smaller, things are a lot trickier - how do you block access > to a portion of a file that the client still thinks exist, but which the > server has truncated away? Maybe the easy way out is to state that the > server MUST NOT resize smaller. I would prefer something along the lines of "the server MUST NOT activate the 'resize smaller' command (which it received out of band from whereever) until the client asked for and was told the new size of the device." That is (with A & X being offsets, and B & Y being sizes, A+B < X): client server server mgmt READ A,B no error resize to X READ X,Y no error reread sizes READ X,Y ENOSPC READ A,B no error In that scenario, it should be the responsibility of the server to ensure there are no more readers; servers could implement that (if they don't want to do the required bookkeeping and keep such requests as pending) by simply sending ESHUTDOWN or some such. > > What about an active `resize` request from the client? Considering some NBD > > servers might have the capability to do instant resizing, not applying to > > LVM or host block device, of course... > > And perhaps the 're-read size' command can serve a dual purpose. Since > all NBD commands already include space for size and offset parameters, > we could define that if the client passes 0/0 for size and offset, it > wants to read the server's current size; if it passes 0/non-zero, it is > asking the server to resize to the new non-zero size (and the server's > success or error response tells whether the resize happened). I agree with Alex that adding an active resize command to the NBD protocol feels like a layering violation. We should probably not do that. > Should I spend time turning this idea into a more formal spec, along the > lines of other NBD extension proposals? Feel free. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12