Eric, > Nothing requires the two uses to report at the same granularity. THe > NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descriptors > as it sees fit (so it could report holes at a 4k granularity, but > dirtiness only at a 64k granularity) - all that matters is that when all > the descriptors have been sent, they total up to the length of the > original client request. So by itself, granularity does not require > another command. Sure, but given you can't report dirtiness without also reporting allocation, if they are are at different blocksize I'd rather they were in different commands, because otherwise the code to report block size needs to work at two different granularities. > At this point, I was just trying to rebase the proposal as originally > made by Denis and Pavel; perhaps they will have more insight on how they > envisioned using the command, or on whether we should try harder to make > this more of a two-way protocol (where the client can tell the server > when to mark something as clean, or when to start tracking whether > something is dirty). I'm not sure it needs to be a two way protocol (see my strawman) but I'd like to know it's at least possibly useful. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail