On 10 May 2016, at 17:04, Quentin Casasnovas <[email protected]> wrote:
> Alright, I assumed by 'length of an NBD request', the specification was > talking about the length of.. well, the request as opposed to whatever is > in the length field of the request header. With NBD_CMD_TRIM the length in the header field is 32 bit and specifies the length of data to trim, not the length of the data transferred (which is none). > Is there a use case where you'd want to split up a single big TRIM request > in smaller ones (as in some hardware would not support it or something)? > Even then, it looks like this splitting up would be hardware dependant and > better implemented in block device drivers. Part of the point of the block size extension is to push such limits to the client. I could make up use cases (e.g. that performing a multi-gigabyte trim in a single threaded server will effectively block all other I/O), but the main reason in my book is orthogonality, and the fact the client needs to do some breaking up anyway. > I'm just finding odd that something that fits inside the length field can't > be used. That's a different point. That's Qemu's 'Denial of Service Attack' prevention, *not* maximum block sizes. It isn't dropping it because of a maximum block size parameter. If it doesn't support the block size extension which the version you're looking at does not, it's meant to handle requests up to 2^32-1 long EXCEPT that it MAY error requests so long as to cause a denial of service attack. As this doesn't fit into that case (it's a TRIM), it shouldn't be erroring it on that grounds. I agree Qemu should fix that. (So in a sense Eric and I are arguing about something irrelevant to your current problem, which is how this would work /with/ the block size extensions, as Eric is in the process of implementing them). > I do agree with your point number 3, obviously if the lenght > field type doesn't allow something bigger than a u32, then the kernel has > to do some breaking up in that case. -- Alex Bligh ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
