>>>>> "Bart" == Bart Van Assche <bart.vanassche@xxxxxxxxxxx> writes: Bart, Bart> There is something that should be discussed further, namely what Bart> the behavior of the BLKDISCARD and BLKSECDISCARD ioctls should be Bart> if the start and/or end sectors are not aligned on a discard Bart> boundary. Should such requests fail with an error code, should the Bart> non-aligned head and tail be zeroed or should the non-aligned Bart> parts be left unmodified? I think the problem with your changes is that they mix upward and downward-facing behaviors. >From a filesystem/ioctl perspective, BLKDISCARD is a hint. We should not be rounding off or aligning anything. DM or the thin provisioned device may or may not ignore parts of the request. Their business. And since discard is there to alleviate write amplification, it absolutely should never cause any media writing to happen. BLKZEROOUT, on the other hand, needs to provide hard guarantees. It is up to the filesystem or ioctl caller to indicate whether allocation or deallocation is preferred in this case. And then that should get turned into a mix of WRITE, WRITE SAME or DISCARD commands based on alignment, granularity and discard_zeroes_data reported by the device. Darrick has been trying to clean all this up and I would like to see the explicit distinction between allocate(anchor), deallocate(discard/unmap) and zeroout (write same, unmap) in the upward-facing interfaces. And then have those interfaces use WRITE SAME, DISCARD and ANCHOR to implement their functionality based on the parameters reported by the underlying device. -- 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
