On 05/10/2016 09:41 AM, Alex Bligh wrote: > > On 10 May 2016, at 16:29, Eric Blake <eblake@...696...> wrote: > >> So the kernel is currently one of the clients that does NOT honor block >> sizes, and as such, servers should be prepared for ANY size up to >> UINT_MAX (other than DoS handling). > > Interesting followup question: > > If the kernel does not fragment TRIM requests at all (in the > same way it fragments read and write requests), I suspect > something bad may happen with TRIM requests over 2^31 > in size (particularly over 2^32 in size), as the length > field in nbd only has 32 bits. > > Whether it supports block size constraints or not, it is > going to need to do *some* breaking up of requests. Does anyone have an easy way to cause the kernel to request a trim operation that large on a > 4G export? I'm not familiar enough with EXT4 operation to know what file system operations you can run to ultimately indirectly create a file system trim operation that large. But maybe there is something simpler - does the kernel let you use the fallocate(2) syscall operation with FALLOC_FL_PUNCH_HOLE or FALLOC_FL_ZERO_RANGE on an fd backed by an NBD device? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature