On 04/04/2016 10:58 PM, Alex Bligh wrote: > 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. > 'dirty' could come after the data was 'trimmed' from the region! thus we could have dirty unallocated data.
>> 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 > > > > ------------------------------------------------------------------------------ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
