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 ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
