Re: Update section on NFS

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Update section on NFS
Дата
Msg-id CA+hUKGKNrexjyqtZXrXp7MT9_Q=cYaObMQpv4hE1gyQ0nCkouA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Update section on NFS  (Joe Conway <mail@joeconway.com>)
Ответы Re: Update section on NFS
Список pgsql-docs
On Wed, Apr 24, 2019 at 11:17 PM Joe Conway <mail@joeconway.com> wrote:
> On 4/24/19 4:54 AM, Peter Eisentraut wrote:
> > On 2019-04-23 18:53, Tom Lane wrote:
> >> Peter Eisentraut <peter.eisentraut@2ndquadrant.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



В списке pgsql-docs по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: SET ROLE documentation not entirely correct
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Update section on NFS