Re: Update section on NFS

Thomas Munro <[email protected]>
Newsgroups gmane.comp.db.postgresql.devel.documentation
Message-ID <CA+hUKGKNrexjyqtZXrXp7MT9_Q=cYaObMQpv4hE1gyQ0nCkouA@mail.gmail.com>
On Wed, Apr 24, 2019 at 11:17 PM Joe Conway <[email protected]> wrote:
> On 4/24/19 4:54 AM, Peter Eisentraut wrote:
> > On 2019-04-23 18:53, Tom Lane wrote:
> >> Peter Eisentraut <[email protected]> writes:
> >>> On 2019-04-23 16:15, Joe Conway wrote:
> >>>> I don't think so. Not sure if you have an account at Red Hat, but this
> >>>> ticket covers it:
> >>>> https://access.redhat.com/solutions/48199
> >>
> >>> That discusses the equally-named export options on the NFS server, not
> >>> the mount options on the NFS client.
> >>
> >> Well, the DBA might also be the NFS server's admin, so I think we ought
> >> to explain the correct settings on both ends.
> >
> > Right, the slight confusion in this thread indicates that this is worth
> > explaining further.
>
>
> And the confusion is aided by the fact that prior to NFS 3 sync *was*
> necessary on the client side.  Yeah I know, ancient, so maybe only old
> folks like me get confused ;-), but NFS 2 was probably current when this
> was originally written.
>
> See: http://nfs.sourceforge.net/
>      "safe asynchronous writes."
>
>
> > New version attached.
>
> Looks reasonable to me.

+     It is not necessary to use the <literal>sync</literal> mount option.  The
+     behavior of the <literal>async</literal> option is sufficient, since
+     <productname>PostgreSQL</productname> issues <literal>fsync</literal>
+     calls at appropriate times to flush the write caches.  (This is analogous
+     to how it works on a local file system.)  However, it is strongly
+     recommended to use the <literal>sync</literal> export option on the NFS
+     <emphasis>server</emphasis>.  Otherwise an <literal>fsync</literal> or
+     equivalent on the NFS client is not actually guaranteed to reach
+     permanent storage on the server, which could cause corruption similar to
+     running with the parameter <xref linkend="guc-fsync"/> off.  The defaults
+     of these mount and export options differs between vendors and versions,
+     so it is recommended to check and perhaps specify them explicitly in any
+     case to avoid any ambiguity.

Those options are Linux-specific -- maybe just say so?  The exports(5)
or share_nfs(2) man pages I checked on BSD-ish and Sun-ish systems
don't even have a "sync" option for the server, and according to
export(5) on Linux its ancient behaviour without "sync" violated the
spec, which might explain that.  Only HP-UX's version of share_nfs
(which says it came from Sun) seems to have sprouted (or not lost?) an
"async" option.  I didn't look into the client side of that, though
"hard" and "soft" are understood everywhere I looked.


--
Thomas Munro
https://enterprisedb.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.