On Tue, May 10, 2016 at 09:29:23AM -0600, Eric Blake wrote: > On 05/10/2016 09:08 AM, Alex Bligh wrote: > > Eric, > > > >> Hmm. The current wording of the experimental block size additions does > >> NOT allow the client to send a NBD_CMD_TRIM with a size larger than the > >> maximum NBD_CMD_WRITE: > >> https://github.com/yoe/nbd/blob/extension-info/doc/proto.md#block-size-constraints > > > > Correct > > > >> Maybe we should revisit that in the spec, and/or advertise yet another > >> block size (since the maximum size for a trim and/or write_zeroes > >> request may indeed be different than the maximum size for a read/write). > > > > I think it's up to the server to either handle large requests, or > > for the client to break these up. > > But the question at hand here is whether we should permit servers to > advertise multiple maximum block sizes (one for read/write, another one > for trim/write_zero, or even two [at least qemu tracks a separate > maximum trim vs. write_zero sizing in its generic block layer]), or > merely stick with the current wording that requires clients that honor > maximum block size to obey the same maximum for ALL commands, regardless > of amount of data sent over the wire. > > > > > The core problem here is that the kernel (and, ahem, most servers) are > > ignorant of the block size extension, and need to guess how to break > > things up. In my view the client (kernel in this case) should > > be breaking the trim requests up into whatever size it uses as the > > maximum size write requests. But then it would have to know about block > > sizes which are in (another) experimental extension. > > Correct - no one has yet patched the kernel to honor block sizes > advertised through what is currently an experimental extension. (We > have ioctl(NBD_SET_BLKSIZE) which can be argued to set the kernel's > minimum block size, but I haven't audited whether the kernel actually > guarantees that all client requests are sent aligned to the value passed > that way - but we have nothing to set the maximum size, and are at the > mercy of however the kernel currently decides to split large requests).
I don't actually think it does that at all, tbh. There is an "integrityhuge" test in the reference server test suite which performs a number of large requests (up to 50M), and which was created by a script that just does direct read requests to /dev/nbdX. It just so happens that most upper layers (filesystems etc) don't make requests larger than about 32MiB, but that's not related. > 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). My question above only applies to > clients that use the experimental block size extensions. Right. [...] -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12