Re: Update section on NFS

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-docs <pgsql-docs(at)postgresql(dot)org>
Subject: Re: Update section on NFS
Date: 2019-04-26 07:41:47
Message-ID: CA+hUKGKNrexjyqtZXrXp7MT9_Q=cYaObMQpv4hE1gyQ0nCkouA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Wed, Apr 24, 2019 at 11:17 PM Joe Conway <mail(at)joeconway(dot)com> wrote:
> On 4/24/19 4:54 AM, Peter Eisentraut wrote:
> > On 2019-04-23 18:53, Tom Lane wrote:
> >> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> 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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Eisentraut 2019-04-26 09:52:55 Re: Update section on NFS
Previous Message Joe Conway 2019-04-25 22:54:39 Re: SET ROLE documentation not entirely correct