On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote: > On 05/10/2016 09:41 AM, Alex Bligh wrote: > > > > On 10 May 2016, at 16:29, Eric Blake <ebl...@redhat.com> 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? >
It was fairly reproducible here, we just used a random qcow2 image with some Debian minimal system pre-installed, mounted that qcow2 image through qemu-nbd then compiled a whole kernel inside it. Then you can make clean and run fstrim on the mount point. I'm assuming you can go faster than that by just writing a big file to the qcow2 image mounted without -o discard, delete the big file, then remount with -o discard + run fstrim. Quentin
