<div dir="ltr"><div><div>In all seriousness, I'd love to be wrong about this. I'm not sure which part(s) of what I said was 
inaccurate-- the vendor lock in and/or that GNR is the only way to get end 
to end checksums.<br><br></div>When I say end to end checksums I mean that from the moment an FS write is submitted to mmfsd a checksum is calculated that is passed through every layer (memory, network, sas, fibre channel etc.) down to individual disk drives (understanding that the RAID controller may need to derive the checksum based on whatever RAID algorithm it's using). It's my understanding that the only way to achieve this with GPFS today is with GNR which is only available via purchasing a GSS or ESS solution from IBM/Lenovo. One is of course free to by hardware from any vendor but you don't get GNR. I should really have said "if you want GNR you have to buy hardware from IBM or Lenovo" which to me is being locked in to a vendor as long as you'd like end to end checksums. <br><br></div><div>If there's another way to get end-to-end checksums, could you help me understand how?<br><br></div><div>Regarding DIF/DIX, it's my understanding that I can/could use T10-DIF today (with the correct hardware) without purchasing any standards which would checksum data from the HBA to the RAID controller (and in theory disks). However, in an environment with NSD servers the origin of a read/write could in theory be quite a bit further away from the HBA in terms of hops. T10-DIF would be completely separate from GPFS as I understand it. I'm not aware of any integration (T10-DIF + DIX). What I'm really looking for, I think, is T10-DIF + DIX where the application (GPFS) generates protection information that's then passed along to the layers below it. <br><br></div><div>-Aaron<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 7:19 AM, Jonathan Buzzard <span dir="ltr"><<a href="mailto:jonathan@buzzard.me.uk" target="_blank">jonathan@buzzard.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2017-03-15 at 20:52 -0400, Aaron Knister wrote:<br>
> *drags out soapbox*<br>
><br>
><br>
> Sorry in advance for the rant, this is one of my huge pet peeves :)<br>
><br>
><br>
><br>
> There are some serious blockers for GNR adoption in my environment. It<br>
> drives me up a wall that the only way to get end to end checksums in<br>
> GPFS is with vendor hardware lock-in.<br>
<br>
</span>As I understand it that is a factually inaccurate statement.<br>
<br>
You are free to use a DIF/DIX solution which is part of the T10 SCSI<br>
specification and as such an open(ish) standard. That is if you pay a<br>
suitable amount you will get a copy of the standard and are free to<br>
implement it. It is arguably more open than ZFS that has licensing<br>
issues.<br>
<br>
Further as I understand it the DIF/DIX solution is actually better than<br>
the ZFS solution on a number of counts, that revolve around it being<br>
baked into the hardware.<br>
<br>
JAB.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Jonathan A. Buzzard                 Email: jonathan (at) <a href="http://buzzard.me.uk" rel="noreferrer" target="_blank">buzzard.me.uk</a><br>
Fife, United Kingdom.<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>