Thread: Update section on NFS
Attached is a patch that rewrites the section on NFS. The old section was ancient and didn't seem very helpful. AFAIK, the only strict requirement for using NFS with PostgreSQL is the hard mount. Anything else we should mention? I also reorganized the sectioning so that information about other file systems can be added more easily. Can anyone suggest some succinct advice on what file systems are supported on Windows (see XXX in the patch)? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
El 23/4/19 a las 07:10, Peter Eisentraut escribió: > Attached is a patch that rewrites the section on NFS. The old section > was ancient and didn't seem very helpful. > > AFAIK, the only strict requirement for using NFS with PostgreSQL is the > hard mount. Anything else we should mention? Didn''t read the proposed patch, but would like to point out that I would also add that it has to be mounted without file attribute caching. Regards, -- Martín Marqués http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 4/23/19 6:10 AM, Peter Eisentraut wrote: > Attached is a patch that rewrites the section on NFS. The old section > was ancient and didn't seem very helpful. > > AFAIK, the only strict requirement for using NFS with PostgreSQL is the > hard mount. Anything else we should mention? > > I also reorganized the sectioning so that information about other file > systems can be added more easily. > <para> > - Many installations create their database clusters on network file > - systems. Sometimes this is done via <acronym>NFS</acronym>, or by using a > - Network Attached Storage (<acronym>NAS</acronym>) device that uses > - <acronym>NFS</acronym> internally. <productname>PostgreSQL</productname> does nothing > - special for <acronym>NFS</acronym> file systems, meaning it assumes > - <acronym>NFS</acronym> behaves exactly like locally-connected drives. > - If the client or server <acronym>NFS</acronym> implementation does not > - provide standard file system semantics, this can > - cause reliability problems (see <ulink > - url="https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html"></ulink>). > - Specifically, delayed (asynchronous) writes to the <acronym>NFS</acronym> > - server can cause data corruption problems. If possible, mount the > - <acronym>NFS</acronym> file system synchronously (without caching) to avoid > - this hazard. Also, soft-mounting the <acronym>NFS</acronym> file system is > - not recommended. <snip> > + <para> > + It is possible to use an NFS file system for storing the > + <productname>PostgreSQL</productname> data directory. The only > + requirement is that the file system is mounted using the > + <literal>hard</literal> option. With the <literal>hard</literal> option, > + processes can <quote>hang</quote> indefinitely if there are network > + problems, so this setup will require a careful monitoring setup. (The > + <literal>soft</literal> option will interrupt system calls in case of > + network problems, but the <productname>PostgreSQL</productname> will not > + repeat system calls interrupted in this way, so any such interruption > + will result in an I/O error being reported.) > + <productname>PostgreSQL</productname> does nothing special for > + <acronym>NFS</acronym> file systems, meaning it assumes > + <acronym>NFS</acronym> behaves exactly like locally-connected drives. > + </para> Looks like you dropped the advice WRT the asynchronous mount option. Isn't that is still relevant? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
On 2019-04-23 13:00, Martín Marqués wrote: > Didn''t read the proposed patch, but would like to point out that I > would also add that it has to be mounted without file attribute caching. Why? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-04-23 14:31, Joe Conway wrote: > Looks like you dropped the advice WRT the asynchronous mount option. > Isn't that is still relevant? I don't think that advice was correct. An async mounted NFS file system will flush data on fsync, which is what one wants. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/23/19 9:47 AM, Peter Eisentraut wrote: > On 2019-04-23 14:31, Joe Conway wrote: >> Looks like you dropped the advice WRT the asynchronous mount option. >> Isn't that is still relevant? > > I don't think that advice was correct. An async mounted NFS file system > will flush data on fsync, which is what one wants. > 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 Here is the relevant part of the solution as written by Red Hat: "Finally, note that, for writes over NFS, a subsequent commit request from the NFS client at file close time, or at fsync() time, will force the server to write any previously unwritten data/metadata to the disk, and the server will not reply to the client until this has been completed, as long as sync behavior is followed. If async is used, the commit is essentially a no-op, since the server once again lies to the client, telling the client that the data has been sent to stable storage. This again exposes the client and server to data corruption, since cached data may be discarded on the client due to its belief that the server now has the data maintained in stable storage." Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
On 2019-04-23 16:15, Joe Conway wrote: > On 4/23/19 9:47 AM, Peter Eisentraut wrote: >> On 2019-04-23 14:31, Joe Conway wrote: >>> Looks like you dropped the advice WRT the asynchronous mount option. >>> Isn't that is still relevant? >> >> I don't think that advice was correct. An async mounted NFS file system >> will flush data on fsync, which is what one wants. >> > > 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. You generally do want the sync option on the server so that an fsync from the client actually reaches the *disk*, not just the memory, of the NFS server. But you don't need the sync option on the client. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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. regards, tom lane
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. New version attached. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
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. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
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
On 2019-04-26 09:41, Thomas Munro wrote: > Those options are Linux-specific -- maybe just say so? committed with that change -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services