On 05/11/2016 03:38 AM, Paolo Bonzini wrote: > > > On 10/05/2016 18:23, Alex Bligh wrote: >>> 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. > > That's why SCSI for example has a limit to UNMAP and WRITE SAME requests > (actually it has three limits: number of ranges per unmap, which in NBD > and in SCSI WRITE SAME is 1; number of blocks per unmap descriptor; > number of blocks per WRITE SAME operation). These limits however are a > different one than the read/write limit, because you want to support > systems where TRIM is much faster than regular I/O (and possibly even > O(1) if trimming something that is already trimmed). Then I think I will propose a doc patch to the extension-info branch that adds new INFO items for NBD_INFO_TRIM_SIZE and NBD_INFO_WRITE_ZERO_SIZE (if requested by client and replied by server, then this can be larger than the normal maximum size in NBD_INFO_BLOCK_SIZE; if either side doesn't request the info, then assume any maximum in NBD_INFO_BLOCK_SIZE applies, otherwise UINT32_MAX; and the two infos are separate items because NBD_FLAG_SEND_TRIM and NBD_FLAG_SEND_WRITE_ZEROES are orthogonally optional). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature