<div dir="ltr"><div><div><div>*drags out soapbox*<br><br></div><div>Sorry in advance for the rant, this is one of my huge pet peeves :)<br></div><div><br></div>There are some serious blockers for GNR adoption in my environment. It drives me up a wall that the only way to get end to end checksums in GPFS is with vendor hardware lock-in. I find it infuriating. Lustre can do this for free with ZFS. Historically it has also offered various other features too like eating your data so I guess it's a tradeoff ;-) I believe that either GNR should be available for any hardware that passes a validation suite or GPFS should support checksums on non-GNR NSDs either by leveraging T10-PI information or by checksumming blocks/subblocks and storing that somewhere. I opened an RFE for this and it was rejected and I was effectively told to go use GNR/ESS, but well... can't do GNR.<br><br></div>But lets say I could run GNR on any hardware of my choosing after perhaps paying some modest licensing fee and passing a hardware validation test there's another blocker for me. Because GPFS doesn't support anything like an LNet router I'm fairly limited on the number of high speed verbs rdma fabrics I can connect GNR to. Furthermore even if I had enough PCIe slots the configuration may not be supported (e.g. a site with an OPA and an IB fabric that would like to use rdma verbs on both). There could even be a situation where a vendor of an HPC solution requires a specific OFED version for support purposes that's not the version running on the GNR nodes. If an NSD protocol router were available I could perhaps use ethernet as a common medium to work around this.<br><br></div><div>I'd really like IBM to *do* something about this situation but I've not gotten any traction on it so far.<br></div><div><br></div>-Aaron<br><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 15, 2017 at 8:26 PM, Steve Duersch <span dir="ltr"><<a href="mailto:duersch@us.ibm.com" target="_blank">duersch@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><font size="2">>></font><tt><font size="2">For me it's the protection against bitrot and added protection against silent data corruption</font></tt><br><font size="2">GNR has this functionality.  Right now that is available through ESS though.  Not yet as software only.  <br><br>Steve Duersch<br>Spectrum Scale<br><a href="tel:(845)%20433-7902" value="+18454337902" target="_blank">845-433-7902</a><br>IBM Poughkeepsie, New York<br><br><br></font><br><br><tt><font size="2"><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank">gpfsug-discuss-bounces@<wbr>spectrumscale.org</a> wrote on 03/15/2017 10:25:59 AM:<br><br><br>> <br>> Message: 6<br>> Date: Wed, 15 Mar 2017 14:25:41 +0000<br>> From: "Buterbaugh, Kevin L" <Kevin.Buterbaugh@Vanderbilt.<wbr>Edu><br>> To: gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank">gpfsug-discuss@spectrumscale.<wbr>org</a>><br>> Subject: Re: [gpfsug-discuss] mmcrfs issue<br>> Message-ID: <<a href="mailto:F5D928E7-5ADF-4491-A8FB-AF3885E9A8A3@vanderbilt.edu" target="_blank">F5D928E7-5ADF-4491-A8FB-<wbr>AF3885E9A8A3@vanderbilt.edu</a>><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Hi All,<br>> <br>> Since I started this thread I guess I should chime in, too ? for us <br>> it was simply that we were testing a device that did not have <br>> hardware RAID controllers and we were wanting to implement something<br>> roughly equivalent to RAID 6 LUNs.<br>> <br>> Kevin<br>> <br>> > On Mar 14, 2017, at 5:16 PM, Aaron Knister <<a href="mailto:aaron.s.knister@nasa.gov" target="_blank">aaron.s.knister@nasa.gov</a>> wrote:<br>> > <br>> > For me it's the protection against bitrot and added protection <br>> against silent data corruption and in theory the write caching <br>> offered by adding log devices that could help with small random <br>> writes (although there are other problems with ZFS + synchronous <br>> workloads that stop this from actually materializing).<br>> > <br>> > -Aaron<br>> > <br></font></tt><br>
</p></div>
<br>______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br></div>