[gpfsug-discuss] NSD network checksums (nsdCksumTraditional)

Tue Oct 30 12:30:20 GMT 2018

I’m guessing IBM doesn’t generally spend huge amounts of money on things that are superfluous...although *cough*RedHat*cough*.

TCP does of course perform checksumming, but I see the NSD checksums as being at a higher “layer”, if you will. The layer at which I believe the NSD checksums operate sits above the complex spaghetti monster of queues, buffers, state machines, kernel/user space communication inside of GPFS as well as networking drivers that can suck (looking at you Intel, Mellanox), and high speed networking hardware all of which I’ve seen cause data corruption (even though the data on the wire was in some cases checksummed correctly).

-Aaron

On October 30, 2018 at 05:03:26 EDT, Jonathan Buzzard <jonathan.buzzard at strath.ac.uk> wrote:
On 29/10/2018 20:47, Stephen Ulmer wrote:

[SNIP]

>
> If ESS checksumming doesn’t protect on the wire I’d say that marketing
> has run amok, because that has *definitely* been implied in meetings for
> which I’ve been present. In fact, when asked if Spectrum Scale provides
> checksumming for data in-flight, IBM sales has used it as an ESS up-sell
> opportunity.
>
Noting that on a TCP/IP network anything passing over a TCP connection
is checksummed at the network layer. Consequently any addition
checksumming is basically superfluous.

JAB.

--
Jonathan A. Buzzard                         Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20181030/8da6462d/attachment-0002.htm>