<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >That is correct. There is an "async" mount option which is related to Linux file systems. This has no effect at the NFS server. The default is "async". The other is "async" exports option which was invented to handle NFSv2 as the NFSv2 protocol doesn't have the notion of unstable writes and commits. People used "async" export option with NFSv2 at the cost of losing data for performance when the Server goes down.</div>
<div dir="ltr" > </div>
<div dir="ltr" >NFSv3 has unstable writes and commits baked into the protocol, so there is no reason (well, sort of) to use "async" export option with NFSv3. kNFS supports this option as it still supports NFSv2. Ganesha doesn't support NFSv2 and there is no need to support "async" export option.</div>
<div dir="ltr" > </div>
<div dir="ltr" >The fact that Linux NFS client (as well as many clients) use something called "close-to-open" semantics which forces them to COMMIT/SYNC all the file's dirty data as part of close(). Since fclose() is just a wrapper, it doesn't matter whether the application uses close() or fclose(). The NFS client will SYNC the files dirty data to the disk as part of close() system call.</div>
<div dir="ltr" > </div>
<div dir="ltr" >The "async" mount will NOT fix this! I never experimented with "nocto" mount option but it might help here. See "man 5 nfs" for details.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Regards, Malahal.</div>
<div dir="ltr" >PS: NFS </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Jan-Frode Myklebust <janfrode@tanso.net><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>Cc:<br>Subject: Re: [gpfsug-discuss] Preliminary conclusion: single client, single thread, small files - native Scale vs NFS<br>Date: Wed, Oct 17, 2018 7:20 PM<br>
<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> </div>
<div> </div>
<div> -jf</div></div>
<div><div dir="ltr" >On Wed, Oct 17, 2018 at 9:41 AM Tomer Perry <<a href="mailto:TOMP@il.ibm.com" target="_blank">TOMP@il.ibm.com</a>> wrote:</div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" ><font face="sans-serif" size="2" >Hi,</font><br><br><font face="sans-serif" size="2" >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 face="sans-serif" size="2" >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><br><font face="sans-serif" size="2" >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</font><br><br><br><br><br><font color="#5f5f5f" face="sans-serif" size="1" >From: </font><font face="sans-serif" size="1" >"Keigo Matsubara" <<a href="mailto:MKEIGO@jp.ibm.com" target="_blank">MKEIGO@jp.ibm.com</a>></font><br><font color="#5f5f5f" face="sans-serif" size="1" >To: </font><font face="sans-serif" size="1" >gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank">gpfsug-discuss@spectrumscale.org</a>></font><br><font color="#5f5f5f" face="sans-serif" size="1" >Date: </font><font face="sans-serif" size="1" >17/10/2018 16:35</font><br><font color="#5f5f5f" face="sans-serif" size="1" >Subject: </font><font face="sans-serif" size="1" >Re: [gpfsug-discuss] Preliminary conclusion: single client, single thread, small files - native Scale vs NFS</font><br><font color="#5f5f5f" face="sans-serif" size="1" >Sent by: </font><font face="sans-serif" size="1" ><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="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><br><br><tt><font face="" size="3" ><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><br><br><font size="2" >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><br><br><font size="2" >Best Regards,<br>---<br>Keigo Matsubara, Storage Solutions Client Technical Specialist, IBM Japan<br>TEL: +81-50-3150-0595, T/L: 6205-0595</font><br><tt><font face="" size="3" >_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a></font></tt><br><tt><font face="" size="3" ><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>_______________________________________________<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></blockquote></div>
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<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>