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
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 |