[gpfsug-discuss] data integrity documentation

[Aaron Knister]

I think it would be a huge advantage to support these mysterious
nsdChecksum settings for us non GNR folks. Even if the checksums aren't
being stored on disk I would think the ability to protect against
network-level corruption would be valuable enough to warrant its
support. I've created RFE 109269 to request this. We'll see what IBM
says. If this is valuable to other folks then please vote for the RFE.

-Aaron


On 8/2/17 5:53 PM, Stijn De Weirdt wrote:
> hi steve,
>
>> The nsdChksum settings for none GNR/ESS based system is not officially 
>> supported.    It will perform checksum on data transfer over the network 
>> only and can be used to help debug data corruption when network is a 
>> suspect.
> i'll take not officially supported over silent bitrot any day.
>
>> Did any of those "Encountered XYZ checksum errors on network I/O to NSD 
>> Client disk" warning messages resulted in disk been changed to "down" 
>> state due to IO error? 
> no.
>
>  If no disk IO error was reported in GPFS log,
>> that means data was retransmitted successfully on retry. 
> we suspected as much. as sven already asked, mmfsck now reports clean
> filesystem.
> i have an ibdump of 2 involved nsds during the reported checksums, i'll
> have a closer look if i can spot these retries.
>
>> As sven said, only GNR/ESS provids the full end to end data integrity.
> so with the silent network error, we have high probabilty that the data
> is corrupted.
>
> we are now looking for a test to find out what adapters are affected. we
> hoped that nsdperf with verify=on would tell us, but it doesn't.
>
>> Steve Y. Xiao
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> gpfsug-discuss mailing list
>> gpfsug-discuss at spectrumscale.org
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss