<html><body><p><font size="2">Stephen,</font><br><br><font size="2">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 block is broken into smaller pieces. On non-GNR environments (when nsdCksumTraditional is set), the checksum is computed sequentially on the server.</font><br><br><font size="2"> Felipe</font><br><br><font size="2">----<br>Felipe Knop knop@us.ibm.com<br>GPFS Development and Security<br>IBM Systems<br>IBM Building 008<br>2455 South Rd, Poughkeepsie, NY 12601<br>(845) 433-9314 T/L 293-9314<br><br></font><br><br><img width="16" height="16" src="cid:1__=8FBB09A6DFE6EB6B8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Stephen Ulmer ---10/29/2018 04:52:40 PM---So the ESS checksums that are highly touted as "protecting "><font size="2" color="#424282">Stephen Ulmer ---10/29/2018 04:52:40 PM---So the ESS checksums that are highly touted as "protecting all the way to the disk surface" complete</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Stephen Ulmer <ulmer@ulmer.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">gpfsug main discussion list <gpfsug-discuss@spectrumscale.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">10/29/2018 04:52 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [gpfsug-discuss] NSD network checksums (nsdCksumTraditional)</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>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 disk (and in staging buffers, etc.)<br><br>I’m asking because your explanation completely ignores calculating anything on the NSD client and implies that the client could not participate, given that it does not know about the structure of the vdisks under the NSD — but that has to be a performance factor for both types if the transfer is protected starting at the client — which it is in the case of nsdCksumTraditional which is what we are comparing to ESS checksumming.<br><br>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.<br><br>-- <br>Stephen<br><br><br>
<ul><ul>On Oct 29, 2018, at 3:56 PM, Kumaran Rajaram <<a href="mailto:kums@us.ibm.com"><u><font color="#0000FF">kums@us.ibm.com</font></u></a>> wrote:<br><br><font size="2" face="Arial">Hi,</font><br><font size="2" face="Arial"><br>>>How can it be that the I/O performance degradation warning only seems to accompany the nsdCksumTraditional setting and not GNR?<br>>>Why is there such a penalty for "traditional" environments?</font><br><font size="2" face="Arial"><br>In GNR IO/NSD servers (ESS IO nodes), the checksums are computed in parallel for a NSD (storage volume/vdisk) across the threads handling each pdisk/drive (that constitutes the vdisk/volume). This is possible since the GNR software on the ESS IO servers is tightly integrated with underlying storage and is aware of the vdisk DRAID configuration (strip-size, pdisk constituting vdisk etc.) to perform parallel checksum operations. </font><br><font size="2" face="Arial"><br>In non-GNR + external storage model, the GPFS software on the NSD server(s) does not manage the underlying storage volume (this is done by storage RAID controllers) and the checksum is computed serially. This would contribute to increase in CPU usage and I/O performance degradation (depending on I/O access patterns, I/O load etc).</font><br><font size="2" face="Arial"><br>My two cents.</font><br><font size="2" face="Arial"><br>Regards,<br>-Kums</font><br><br><br><br><br><font size="2" color="#5F5F5F"><br>From: </font><font size="2">Aaron Knister <</font><a href="mailto:aaron.s.knister@nasa.gov"><u><font size="2" color="#0000FF">aaron.s.knister@nasa.gov</font></u></a><font size="2">></font><font size="2" color="#5F5F5F"><br>To: </font><font size="2">gpfsug main discussion list <</font><a href="mailto:gpfsug-discuss@spectrumscale.org"><u><font size="2" color="#0000FF">gpfsug-discuss@spectrumscale.org</font></u></a><font size="2">></font><font size="2" color="#5F5F5F"><br>Date: </font><font size="2">10/29/2018 12:34 PM</font><font size="2" color="#5F5F5F"><br>Subject: </font><font size="2">[gpfsug-discuss] NSD network checksums (nsdCksumTraditional)</font><font size="2" color="#5F5F5F"><br>Sent by: </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><u><font size="2" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><br><hr width="100%" size="2" align="left" noshade><br><br><tt><font size="2"><br>Flipping through the slides from the recent SSUG meeting I noticed that <br>in 5.0.2 one of the features mentioned was the nsdCksumTraditional flag. <br>Reading up on it it seems as though it comes with a warning about <br>significant I/O performance degradation and increase in CPU usage. I <br>also recall that data integrity checking is performed by default with <br>GNR. How can it be that the I/O performance degradation warning only <br>seems to accompany the nsdCksumTraditional setting and not GNR? As <br>someone who knows exactly 0 of the implementation details, I'm just <br>naively assuming that the checksum are being generated (in the same <br>way?) in both cases and transferred to the NSD server. Why is there such <br>a penalty for "traditional" environments?<br><br>-Aaron<br><br>-- <br>Aaron Knister<br>NASA Center for Climate Simulation (Code 606.2)<br>Goddard Space Flight Center<br>(301) 286-2776<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at </font></tt><a href="http://spectrumscale.org"><tt><u><font size="2" color="#0000FF">spectrumscale.org</font></u></tt></a><u><font color="#0000FF"><br></font></u><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><u><font size="2" color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></tt></a><tt><font size="2"><br></font></tt><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org"><u><font color="#0000FF">spectrumscale.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><u><font color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a></ul></ul><tt><font size="2">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2"><br></font></tt><br><br><BR>
</body></html>