[Twg] T10 End-to-End Data Integrity HLD

Alexey Lyashkov alexey_lyashkov at xyratex.com
Thu Apr 19 17:57:30 UTC 2012


On Apr 19, 2012, at 01:55, Andreas Dilger wrote:
> 
> 
>>>> From a technical point of view, the tradeoff here is between transmitting a small amount of data (4k per 1MB) and recalculating that data on the servers.  Depending on where/how often we re-verify the checksums, we could remove the recalculation from the server entirely.
>>> 
>>> That is potentially true, but if the checksums are not verified until you get down to the disk, if there ever is a real checksum error you won't have any idea where the error is being introduced.
>> 
>> That's a question about debugging really.  Just as today many sites run without checksums at all due to server CPU loading, it makes sense to me to make intermediate verifications optional.
> 
> Based on the data in LU-1201, I think with Nehalem CPUs and multi-threaded ptlrpcd the checksum overhead will become a non-issue, and people will happily leave it enabled all the time.  The unfortunate thing is that the CRC16 used by T10-DIF has such poor software performance that I agree there is no option but to leave the verification to the hardware.
> 
Based on Xyratex test results - crc32c HW implementation isn't best choose, and multi thread ptlrpcd isn't help to improve a  OST side loading.
yes, main problem is OST side, not a client side checksumming.

Typical speed is less 1Gb/s for crc32c hw, and it's less speed then adler may provide.
Current top speed list - adler, crc32 hw based on (not crc32c), crc32c hw, both crc32c table implementation.




--------------------------------------------
Alexey Lyashkov
alexey_lyashkov at xyratex.com





More information about the Twg mailing list