>>>>> "James" == James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes:
James> No, I think you're confusing algorithms with protocols. DIF and
James> DIX are two names for protection envelopes. DIF verifies
James> integrity from the HBA to the device surface. DIX verifies
James> integrity from an application to the HBA.
Actually, DIX is a data integrity-aware HBA programming interface. We
have an implementation of that interface in the SCSI layer and in some
of the initiator drivers (lpfc, qla2xxx, mptNsas).
There is no single name for stuff above DIX. Other than "block layer
data integrity goo", "page cache black magic" and "let's add a few
fields to struct iocb".
James> So, the question is do we need to bother with DIX at all? No
James> filesystem uses it
...explicitly. Every filesystem uses it implicitly. There are only two
reasons for filesystems to want to be explicitly "block layer data
integrity goo"-aware:
1. To be able to use the application tag space for back pointers or
other metadata without requiring disk format changes.
2. To facilitate passthrough of protection information submitted
via the $TBD application programming interface.
I was hoping the extN folks would be interested in (1) but there were no
takers. (2) is hard but not forgotten. In any case the status quo is
that there is no point in filesystems manually generating protection
information when the block layer is going to do it for them when the bio
is submitted.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
