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). Paolo
