<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Remember too that in a traditional GPFS setup, the NSD servers are effectively merely data routers (since the clients know exactly where the block is going to be written) and as such NSD servers can be previous generation hardware.<div>By contrast GNR needs cpu cycles and plenty of memory, so ESS nodes are naturally big and fast (as well as benefitting from parallel threads working together on the GNR).  <br><br><div dir="ltr" id="AppleMailSignature"><div style="margin-bottom: 0.0001pt; line-height: normal;"><span style="background-color: rgba(255, 255, 255, 0);">Daniel</span></div><div style="margin-bottom: 0.0001pt; line-height: normal;"><span style="background-color: rgba(255, 255, 255, 0);"><img alt="/spectrum_storage-banne" src="http://ausgsa.ibm.com/projects/t/tivoli_visual_design/public/2015/Spectrum-Storage/Email-signatures/Storage/spectrum_storage-banner.png" width="432.5" height="auto" style="width: 601px; height: 5px;"></span></div><div style="margin-bottom: 0.0001pt; line-height: normal;"><span style="background-color: rgba(255, 255, 255, 0);"><br> </span></div><table border="0" cellpadding="0" cellspacing="0" style="font-family: sans-serif;"><tbody><tr style="word-wrap: break-word; max-width: 447.5px;"><td style="word-wrap: break-word; max-width: 447.5px; width: 201px; padding: 0cm;"><div style="margin-bottom: 0.0001pt; line-height: normal;"></div><div style="margin-bottom: 0.0001pt; line-height: normal;"><br></div><div style="margin-bottom: 0.0001pt; line-height: normal;"><table align="left" border="0" cellpadding="0" cellspacing="0" style="-webkit-text-size-adjust: auto;"><tbody><tr><td style="width: 130px; padding: 0cm;"><div style="margin-bottom: 0.0001pt; line-height: normal;"><a href="https://www.youracclaim.com/user/danel-kidger" target="_blank" style="-webkit-text-size-adjust: none; background-color: rgba(255, 255, 255, 0);"><font color="#000000" face=".SFUIDisplay"><img alt="IBM Storage Professional Badge" src="cid:" style="width: 120px; height: 120px; float: left;"></font></a></div></td><td style="width: 140px; padding: 0cm;"><a href="https://www.youracclaim.com/user/danel-kidger" style="-webkit-text-size-adjust: none; background-color: rgba(255, 255, 255, 0);"><font color="#000000" face=".SFUIDisplay"><img alt="" src="https://www.ibm.com/volunteers/images/resources/IBM_Volunteers_Silver_v6.png" style="width: 120px; height: 120px;"></font></a></td><td style="width: 0px; padding: 0cm;"><font face=".SFUIDisplay"><span style="-webkit-text-size-adjust: none; background-color: rgba(255, 255, 255, 0);"> </span></font></td><td style="width: 0px; padding: 0cm;"><font face=".SFUIDisplay"><span style="-webkit-text-size-adjust: none; background-color: rgba(255, 255, 255, 0);"> </span></font></td><td style="width: 0px; padding: 0cm;"><font face=".SFUIDisplay"><span style="-webkit-text-size-adjust: none; background-color: rgba(255, 255, 255, 0);"> </span></font></td><td style="width: 240px; padding: 0cm;"><div style="margin-bottom: 0.0001pt; line-height: normal;"><font face=".SFUIDisplay"><span style="-webkit-text-size-adjust: none; background-color: rgba(255, 255, 255, 0);"><strong>Dr Daniel Kidger</strong><br>IBM Technical Sales Specialist<br>Software Defined Solution Sales<br><br><a href="tel:+44-7818%20522%20266" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="1">+</a><a href="tel:+44-7818%20522%20266" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="1">44-(0)7818 522 266</a> <br><a href="mailto:daniel.kidger@uk.ibm.com" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">daniel.kidger@uk.ibm.com</a></span></font></div></td></tr></tbody></table></div></td><td style="word-wrap: break-word; max-width: 447.5px; width: 21px; padding: 0cm;"><font face=".SFUIDisplay"><span style="background-color: rgba(255, 255, 255, 0);"> </span></font></td><td style="word-wrap: break-word; max-width: 447.5px; width: 202px; padding: 0cm;"><br></td></tr></tbody></table><br></div><div dir="ltr"><br>On 30 Oct 2018, at 00:53, Andrew Beattie <<a href="mailto:abeattie@au1.ibm.com">abeattie@au1.ibm.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"><div dir="ltr">Stephen,</div><div dir="ltr"> </div><div dir="ltr">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. </div><div dir="ltr"> </div><div dir="ltr">As such it is entirely possible that older or lower spec hardware, or even virtualised NSD Servers with even lower resources per virtual node,  will have potential issues when running the nsdChksumTraditional=yes flag,  As such IBM has a duty of care to provide a warning that you may experience issues if you turn the additional workload on.</div><div dir="ltr"> </div><div dir="ltr">Beyond this i'm not seeing why there is an issue, if you turn the flag on in a non ESS scenario the process is Serialised, if you turn it on in an ESS Scenario you get to take advantage of the fact that Scale Native Raid does a significant amount of the work in a parallelised method, one is less resource intensive than the other, because the process is handled differently depending on the type of NSD Servers doing the work.</div><div dir="ltr"> </div><div dir="ltr"> </div><div dir="ltr"> </div><div dir="ltr"><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr" style="margin-top: 20px;"><div style="font-size: 12pt; font-weight: bold; font-family: sans-serif; color: #7C7C5F;">Andrew Beattie</div><div style="font-size: 10pt; font-weight: bold; font-family: sans-serif;">Software Defined Storage  - IT Specialist</div><div style="font-size: 8pt; font-family: sans-serif; margin-top: 10px;"><div><span style="font-weight: bold; color: #336699;">Phone: </span>614-2133-7927</div><div><span style="font-weight: bold; color: #336699;">E-mail: </span><a href="mailto:abeattie@au1.ibm.com" style="color: #555">abeattie@au1.ibm.com</a></div></div></div></div></div></div></div><div dir="ltr"> </div><div dir="ltr"> </div><blockquote data-history-content-modified="1" data-history-expanded="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px">----- Original message -----<br>From: Stephen Ulmer <<a href="mailto:ulmer@ulmer.org">ulmer@ulmer.org</a>><br>Sent by: <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a><br>To: gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>><br>Cc:<br>Subject: Re: [gpfsug-discuss] NSD network checksums (nsdCksumTraditional)<br>Date: Tue, Oct 30, 2018 10:39 AM<br> <br><!--Notes ACF

<meta http-equiv="Content-Type" content="text/html; charset=utf8" >--><!--Notes ACF

<div> </div><div>Your reply was that checksums in an ESS environment are calculated in parallel on the NSD server based on the physical storage layout used underneath the NSD, and is thus faster. My point was that if there is never a checksum calculated by the NSD client, then how does the NSD server know that it got uncorrupted data?

<div> </div><div>The link you referenced below (thank you!) indicates that, in fact, the NSD client DOES calculate a checksum and forward it with the data to the NSD server. The server validates the data (necessitating a re-calculation of the checksum), and then GNR stores the data, A CHECKSUM[1], and some block metadata to media. </div><div> </div><div>So this leaves us with a checksum calculated by the client and then validated (re-calculated) by the server — IN BOTH CASES. For the GNR case, another checksum in calculated and stored with the data for another purpose, but that means that the nsdChksumTraditional=yes case is exactly like the first phase of the GNR case. So why is that case slower when it does less work? Slow enough to merit a warning, no less!</div><div> </div><div>I’m really not trying to be a pest, but I have a logic problem with either the question or the answer — they aren’t consistent (or I can’t rationalize them to be so).</div><div> </div><div><div><div>-- <br>Stephen<br> 

<div>[1] The document is vague (I believe intentionally, because it could have easily been made clear) as to whether this is the same checksum or a different one. Presumably the server-side-new-checksum is calculated in parallel and protects the chunklets or whatever they're called. This is all consistent with what you said!</div><div> </div></div></div><div> </div><div> 

<blockquote type="cite"><div>On Oct 29, 2018, at 5:29 PM, Kumaran Rajaram <<a href="mailto:kums@us.ibm.com" target="_blank">kums@us.ibm.com</a>> wrote:</div> 

<div><font size="2" face="Arial">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.</font><br><br><font size="2" face="Arial">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 to the disk/storage.  This is further detailed in the docs (link below):</font><br><br><a href="https://www.ibm.com/support/knowledgecenter/en/SSYSP8_5.3.1/com.ibm.spectrum.scale.raid.v5r01.adm.doc/bl1adv_introe2echecksum.htm" target="_blank"><font size="2" face="Arial" color="blue">https://www.ibm.com/support/knowledgecenter/en/SSYSP8_5.3.1/com.ibm.spectrum.scale.raid.v5r01.adm.doc/bl1adv_introe2echecksum.htm</font></a><br><br><font size="2" face="Arial">Best,</font><br><font size="2" face="Arial">-Kums</font><br><br><br><br><br><br><font size="1" face="sans-serif" color="#5f5f5f">From:        </font><font size="1" face="sans-serif">Stephen Ulmer <<a href="mailto:ulmer@ulmer.org" target="_blank">ulmer@ulmer.org</a>></font><br><font size="1" face="sans-serif" color="#5f5f5f">To:        </font><font size="1" face="sans-serif">gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank">gpfsug-discuss@spectrumscale.org</a>></font><br><font size="1" face="sans-serif" color="#5f5f5f">Date:        </font><font size="1" face="sans-serif">10/29/2018 04:52 PM</font><br><font size="1" face="sans-serif" color="#5f5f5f">Subject:        </font><font size="1" face="sans-serif">Re: [gpfsug-discuss] NSD network checksums (nsdCksumTraditional)</font><br><font size="1" face="sans-serif" color="#5f5f5f">Sent by:        </font><font size="1" face="sans-serif"><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a></font><hr noshade="noshade"><br><br><br><font size="3">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.)</font><br><br><font size="3">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.</font><br><br><font size="3">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.</font><br><br><font size="3">-- </font><br><font size="3">Stephen</font><br><br><br><br><font size="3">On Oct 29, 2018, at 3:56 PM, Kumaran Rajaram <</font><a href="mailto:kums@us.ibm.com" target="_blank"><font size="3" color="blue"><u>kums@us.ibm.com</u></font></a><font size="3">> wrote:</font><br><br><font size="2" face="Arial">Hi,</font><br><br><font size="2" face="Arial">>>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><br><font size="2" face="Arial">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><br><font size="2" face="Arial">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><br><font size="2" face="Arial">My two cents.</font><br><br><font size="2" face="Arial">Regards,<br>-Kums</font><br><br><br><br><br><br><font size="1" face="sans-serif" color="#5f5f5f">From:        </font><font size="1" face="sans-serif">Aaron Knister <</font><a href="mailto:aaron.s.knister@nasa.gov" target="_blank"><font size="1" face="sans-serif" color="blue"><u>aaron.s.knister@nasa.gov</u></font></a><font size="1" face="sans-serif">></font><br><font size="1" face="sans-serif" color="#5f5f5f">To:        </font><font size="1" face="sans-serif">gpfsug main discussion list <</font><a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank"><font size="1" face="sans-serif" color="blue"><u>gpfsug-discuss@spectrumscale.org</u></font></a><font size="1" face="sans-serif">></font><br><font size="1" face="sans-serif" color="#5f5f5f">Date:        </font><font size="1" face="sans-serif">10/29/2018 12:34 PM</font><br><font size="1" face="sans-serif" color="#5f5f5f">Subject:        </font><font size="1" face="sans-serif">[gpfsug-discuss] NSD network checksums (nsdCksumTraditional)</font><br><font size="1" face="sans-serif" color="#5f5f5f">Sent by:        </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><font size="1" face="sans-serif" color="blue"><u>gpfsug-discuss-bounces@spectrumscale.org</u></font></a><hr noshade="noshade"><br><br><br><tt><font size="3" face="">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/" target="_blank"><tt><font size="3" face="" color="blue"><u>spectrumscale.org</u></font></tt></a><br><tt><font size="3" face="" color="blue"><u><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></u></font></tt><br><br><br><br><font size="3">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at </font><a href="http://spectrumscale.org/" target="_blank"><font size="3" color="blue"><u>spectrumscale.org</u></font></a><br><font size="3" color="blue"><u><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></u></font><br><tt><font size="3" face="">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a></font></tt><br><tt><font size="3" face=""><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></div></blockquote></div></div></div><div><font size="2" face="Default Monospace,Courier New,Courier,monospace">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org">spectrumscale.org</a><br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></div></blockquote><div dir="ltr"> </div></div><br>

<pre>_______________________________________________

gpfsug-discuss mailing list

gpfsug-discuss at <a href="http://spectrumscale.org">spectrumscale.org</a><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></pre><br></div></blockquote></div>Unless stated otherwise above:<BR>

IBM United Kingdom Limited - Registered in England and Wales with number 741598. <BR>

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU<BR>

<BR>

</body></html>