On Fri, Feb 21, 2020 at 04:52:33PM -0800, Satya Tangirala wrote: > > What is the rationale for this limitation? Restricting unrelated > > features from being used together is a pretty bad design pattern and > > should be avoided where possible. If it can't it needs to be documented > > very clearly. > > > My understanding of blk-integrity is that for writes, blk-integrity > generates some integrity info for a bio and sends it along with the bio, > and the device on the other end verifies that the data it received to > write matches up with the integrity info provided with the bio, and > saves the integrity info along with the data. As for reads, the device > sends the data along with the saved integrity info and blk-integrity > verifies that the data received matches up with the integrity info. Yes, a device supporting inline encryption and integrity will have to update the guard tag to match the encrypted data as well. That alone is a good enough reason to reject the combination for now until it is fully supported. It needs to be properly document, and I think we should also do it at probe time if possible, not when submitting I/O.
