>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes:
Tom> Nevertheless, I don't really quite get the sense of the original Tom> commit anyway. Isn't discard granularity the minimum size we can Tom> discard? In that case why would it have anything to do with "read Tom> zeroes"? On devices that guarantee returning zeroes after discard we use the feature to clear block ranges (for filesystem metadata, etc.). A filesystem that clears a block range obviously needs every logical block to be properly zeroed. And not just the portion that are a certain size and aligned to a certain boundary. Tom> Suppose we are handling a device reports a discard granularity of Tom> 4096 bytes, while logical block size and physical block size are Tom> both 512 bytes. For such a device, a single 512-byte discard Tom> request should simply be rejected because it's not allowed by the Tom> device. Discard is advisory, the command will not get rejected. Tom> When it's rejected, it doesn't mean that "the 512-byte block does Tom> not read zeroes after being discarded"; instead, it's just "we did Tom> not discard the 512-byte block as per requested because it's not Tom> allowed". We only honor discard_zeroes_data for devices that support WRITE SAME w/ UNMAP. And WRITE SAME will manually write any block that it can not deprovision so you are guaranteed reliable results. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
