Re: Update section on NFS - Mailing list pgsql-docs
From | Thomas Munro |
---|---|
Subject | Re: Update section on NFS |
Date | |
Msg-id | CA+hUKGKNrexjyqtZXrXp7MT9_Q=cYaObMQpv4hE1gyQ0nCkouA@mail.gmail.com Whole thread Raw |
In response to | Re: Update section on NFS (Joe Conway <mail@joeconway.com>) |
Responses |
Re: Update section on NFS
|
List | 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 by date: