Stephen,
I think you also need to take into consideration that IBM does not control what infrastructure users may chose to deploy Spectrum scale on outside of ESS hardware.
As such it is entirely possible that older or lower spec hardware, or even virtualised NSD Servers with even lower
The point of the original question was to discover why there is a warning about
performance for nsdChksumTraditional=yes, but that warning doesn’t seem to
apply to an ESS environment.
Your reply was that checksums in an ESS environment are calculated in parallel
on the NSD server based on the
In non-GNR setup, nsdCksumTraditional=yes enables data-integrity checking
between a traditional NSD client node and its NSD server, at the network
level only.
The ESS storage supports end-to-end checksum, NSD client to the ESS IO
servers (at the network level) as well as from ESS IO servers
Stephen,
ESS does perform checksums in the transfer between NSD clients and NSD
servers. As Kums described below, the difference between the checksums
performed by GNR and those performed with "nsdCksumTraditional" is that GNR
checksums are computed in parallel on the server side, as a large FS
So the ESS checksums that are highly touted as "protecting all the way to the
disk surface" completely ignore the transfer between the client and the NSD
server? It sounds like you are saying that all of the checksumming done for GNR
is internal to GNR and only protects against bit-flips on the
Hi,
>>How can it be that the I/O performance degradation warning only seems to
accompany the nsdCksumTraditional setting and not GNR?
>>Why is there such a penalty for "traditional" environments?
In GNR IO/NSD servers (ESS IO nodes), the checksums are computed in
parallel for a NSD (storage
