>>>>> "Christoph" == Christoph Hellwig <hch@xxxxxxxxxxxxx> writes: Christoph> To properly support discard on SCSI Arrays we need to take Christoph> the discard granularity and the first aligned discard LBA Christoph> into account. This patch adds block limits for both of them, Christoph> and trims down dicard requests to fit into these limits in Christoph> blkdev_issue_discard. We also make sure the alignment offset Christoph> is properly adjust for partitions and add sysfs files to Christoph> expose the limits to userspaced. Do we know for sure that this is really needed? The reason I'm asking is that in my first attempt I also exposed all this up the stack. However, it sucks to keep this in sync and would require the same level of topology stacking magic as the rest of the queue limits. My brain melted at the thought of LVM/MD volumes striped or mirrored between devices with different unmap granularity and alignment. So I talked to a variety of array folks. And regardless of whether they implement WRITE SAME or UNMAP they all appear to handle misaligned requests just fine. I.e. there may be some mapped residue at the beginning and end of an unmap request but any full allocation units in between will be correctly unmapped. They all told me the alignment and granularity parameters were purely informational and intended as hints for laying out data. Not as hard limits for issuing I/O. Consequently I gutted all the alignment stuff from my thin provisioning tree. I also changed mt scsi_debug code to unmap allocations similar to the way the arrays work (my first attempt completely ignored misaligned requests). 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... -- 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
