<div dir="ltr">Also beware there are 2 different linux NFS "async" settings. A client side setting (mount -o async), which still cases sync on file close() -- and a server (knfs) side setting (/etc/exports) that violates NFS protocol and returns requests before data has hit stable storage.<div><br></div><div><br></div><div>  -jf</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 9:41 AM Tomer Perry <<a href="mailto:TOMP@il.ibm.com">TOMP@il.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">Hi,</font><br><br><font size="2" face="sans-serif">Without going into to much details,
AFAIR, Ontap integrate NVRAM into the NFS write cache ( as it was developed
as a NAS product).</font><br><font size="2" face="sans-serif">Ontap is using the STABLE bit which
kind of tell the client "hey, I have no write cache at all, everything
is written to stable storage - thus, don't bother with commits ( sync)
commands - they are meaningless".</font><br><br><font size="2" face="sans-serif"><br>Regards,<br><br>Tomer Perry<br>Scalable I/O Development (Spectrum Scale)<br>email: <a href="mailto:tomp@il.ibm.com" target="_blank">tomp@il.ibm.com</a><br>1 Azrieli Center, Tel Aviv 67021, Israel<br>Global Tel:    +1 720 3422758<br>Israel Tel:      +972 3 9188625<br>Mobile:         +972 52 2554625<br></font><br><br><br><br><font size="1" color="#5f5f5f" face="sans-serif">From:      
 </font><font size="1" face="sans-serif">"Keigo Matsubara"
<<a href="mailto:MKEIGO@jp.ibm.com" target="_blank">MKEIGO@jp.ibm.com</a>></font><br><font size="1" color="#5f5f5f" face="sans-serif">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" color="#5f5f5f" face="sans-serif">Date:      
 </font><font size="1" face="sans-serif">17/10/2018 16:35</font><br><font size="1" color="#5f5f5f" face="sans-serif">Subject:    
   </font><font size="1" face="sans-serif">Re: [gpfsug-discuss]
Preliminary conclusion: single client, single thread, small files - native
Scale vs NFS</font><br><font size="1" color="#5f5f5f" face="sans-serif">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><br><hr noshade><br><br><br><font size="2">I also wonder how many products actually exploit NFS async
mode to improve I/O performance by sacrificing the file system consistency
risk:</font><font size="3"><br></font><tt><font size="2"><br><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank">gpfsug-discuss-bounces@spectrumscale.org</a> wrote on 2018/10/17 22:26:52:<br>>               Using this option
usually improves performance, but at<br>> the cost that an unclean server restart (i.e. a crash) can cause <br>> data to be lost or corrupted."</font></tt><font size="3"><br></font><font size="2"><br>For instance, NetApp, at the very least FAS 3220 running Data OnTap 8.1.2p4
7-mode which I tested with, would forcibly *promote* async mode to sync
mode.<br>Promoting means even if NFS client requests async mount mode, the NFS server
ignores and allows only sync mount mode.</font><font size="3"><br></font><font size="2"><br>Best Regards,<br>---<br>Keigo Matsubara, Storage Solutions Client Technical Specialist, IBM Japan<br>TEL: +81-50-3150-0595, T/L: 6205-0595</font><font size="3"><br></font><tt><font size="2">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><tt><font size="2">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></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" 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/listinfo/gpfsug-discuss</a><br>
</blockquote></div>