>>>>> "Christoph" == Christoph Hellwig <hch@xxxxxxxxxxxxx> writes: >> ACS-2 doesn't currently have a notion of unmap granularity and all >> array vendors I have talked to appear to happily process any unmap >> request we throw at them. So I'm leaning towards keeping things >> simple and just sending things down verbatim... Christoph> We have all the granularity and alignment information Christoph> avilable and keeping track of it is simple enough. That's not the issue. Nothing prevents you from submitting a misaligned read/write request to the array. If you do, the array may be slower in servicing the request. But the entire request will still be serviced. Similarly, nothing prevents you from submitting a misaligned unmap request. If you do, the array will just ignore the portions that do not constitute entire allocation units. Your code is taking what is a hint and turning it into a hard limit. Note that it's called OPTIMAL UNMAP GRANULARITY, not REQUIRED UNMAP GRANULARITY. Every vendor I have talked to have asked us to always unmap the *entire* LBA range we're interested in freeing. No exceptions. We don't throw away the beginning/end of a read/write request because it's not properly aligned either, do we? Christoph> Yes md/dm will need to update the first aligned unmap sector, Christoph> but they'll also need to update the first aligned LBA for I/O Christoph> purposes and adding more more is simple enough. But with md and dm you can have devices with different unmap alignment and granularity. With read/write alignment we can throw our hands in the air and say that things will be slow. But we'll still submit all I/O. With heterogeneous md and dm devices there may not be a meaningful value to put in the discard granularity field. Then what? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
