From: Joe Conway <mail@joeconway.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: pgsql-docs <pgsql-docs@postgresql.org>
Subject: Re: Update section on NFS
Date: Tue, 23 Apr 2019 08:31:15 -0400
Message-ID: <83a5bea3-57cd-e820-83eb-4a9c64082c19@joeconway.com> (raw)
In-Reply-To: <e90f24bb-5423-6abb-58ec-501176eb4afc@2ndquadrant.com>
References: <e90f24bb-5423-6abb-58ec-501176eb4afc@2ndquadrant.com>
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
Attachments:
[application/pgp-signature] signature.asc (832B, ../83a5bea3-57cd-e820-83eb-4a9c64082c19@joeconway.com/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: mail@joeconway.com, peter.eisentraut@2ndquadrant.com
Subject: Re: Update section on NFS
In-Reply-To: <83a5bea3-57cd-e820-83eb-4a9c64082c19@joeconway.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox