From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Joe Conway <mail@joeconway.com>
Cc: pgsql-docs <pgsql-docs@postgresql.org>
Subject: Re: Update section on NFS
Date: Wed, 24 Apr 2019 10:54:44 +0200
Message-ID: <80bb96e0-be09-c2f5-0ce6-1c3b33de65c3@2ndquadrant.com> (raw)
In-Reply-To: <28322.1556038397@sss.pgh.pa.us>
References: <e90f24bb-5423-6abb-58ec-501176eb4afc@2ndquadrant.com>
<83a5bea3-57cd-e820-83eb-4a9c64082c19@joeconway.com>
<9c9c8a4c-5d69-cdbd-60c8-442ff7906d5b@2ndquadrant.com>
<950271f0-d8f3-a367-14b7-1f91e4d15e40@joeconway.com>
<bfb2bb68-c4f1-bf11-b4b8-07f68027e4e9@2ndquadrant.com>
<28322.1556038397@sss.pgh.pa.us>
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
From 5891e07a42017ee2b80e25c05b7b89bf7e5fe605 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 24 Apr 2019 10:53:40 +0200
Subject: [PATCH v2] doc: Update section on NFS
---
doc/src/sgml/runtime.sgml | 94 ++++++++++++++++++++++++++-------------
1 file changed, 63 insertions(+), 31 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgmlindex 388dc7e966..4ec80ccc0b 100644--- a/doc/src/sgml/runtime.sgml+++ b/doc/src/sgml/runtime.sgml@@ -229,42 +229,74 @@ <title>Use of Secondary File Systems</title>
</sect2>
- <sect2 id="creating-cluster-nfs">- <title>Use of Network File Systems</title>-- <indexterm zone="creating-cluster-nfs">- <primary>Network File Systems</primary>- </indexterm>- <indexterm><primary><acronym>NFS</acronym></primary><see>Network File Systems</see></indexterm>- <indexterm><primary>Network Attached Storage (<acronym>NAS</acronym>)</primary><see>Network File Systems</see></indexterm>+ <sect2 id="creating-cluster-filesystem">+ <title>File Systems</title>
<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.+ Generally, any file system with POSIX semantics can be used for+ PostgreSQL. Users prefer different file systems for a variety of reasons,+ including vendor support, performance, and familiarity. Experience+ suggests that, all other things being equal, one should not expect major+ performance or behavior changes merely from switching file systems or+ making minor file system configuration changes.
</para>
- <para>- Storage Area Networks (<acronym>SAN</acronym>) typically use communication- protocols other than <acronym>NFS</acronym>, and may or may not be subject- to hazards of this sort. It's advisable to consult the vendor's- documentation concerning data consistency guarantees.- <productname>PostgreSQL</productname> cannot be more reliable than- the file system it's using.- </para>+ <sect3 id="creating-cluster-nfs">+ <title>NFS</title>++ <indexterm zone="creating-cluster-nfs">+ <primary>NFS</primary>+ </indexterm>++ <para>+ It is possible to use an <acronym>NFS</acronym> file system for storing+ the <productname>PostgreSQL</productname> data directory.+ <productname>PostgreSQL</productname> does nothing special for+ <acronym>NFS</acronym> file systems, meaning it assumes+ <acronym>NFS</acronym> behaves exactly like locally-connected drives.+ <productname>PostgreSQL</productname> does not use any functionality that+ is known to have nonstandard behavior on <acronym>NFS</acronym>, such as+ file locking.+ </para>+ <para>+ The only firm requirement for using <acronym>NFS</acronym> with+ <productname>PostgreSQL</productname> 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 configuration will+ require a careful monitoring setup. The <literal>soft</literal> option+ will interrupt system calls in case of network problems, but+ <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.+ </para>++ <para>+ 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.+ </para>++ <para>+ In some cases, an external storage product can be accessed either via NFS+ or a lower-level protocol such as iSCSI. In the latter case, the storage+ appears as a block device and any available file system can be created on+ it. That approach might relieve the DBA from having to deal with some of+ the idiosyncrasies of NFS, but of course the complexity of managing+ remote storage then happens at other levels.+ </para>+ </sect3>
</sect2>
</sect1>
--
2.21.0
Attachments:
[text/plain] v2-0001-doc-Update-section-on-NFS.patch (5.8K, ../80bb96e0-be09-c2f5-0ce6-1c3b33de65c3@2ndquadrant.com/2-v2-0001-doc-Update-section-on-NFS.patch)
download | inline diff:
From 5891e07a42017ee2b80e25c05b7b89bf7e5fe605 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 24 Apr 2019 10:53:40 +0200
Subject: [PATCH v2] doc: Update section on NFS
---
doc/src/sgml/runtime.sgml | 94 ++++++++++++++++++++++++++-------------
1 file changed, 63 insertions(+), 31 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgmlindex 388dc7e966..4ec80ccc0b 100644--- a/doc/src/sgml/runtime.sgml+++ b/doc/src/sgml/runtime.sgml@@ -229,42 +229,74 @@ <title>Use of Secondary File Systems</title>
</sect2>
- <sect2 id="creating-cluster-nfs">- <title>Use of Network File Systems</title>-- <indexterm zone="creating-cluster-nfs">- <primary>Network File Systems</primary>- </indexterm>- <indexterm><primary><acronym>NFS</acronym></primary><see>Network File Systems</see></indexterm>- <indexterm><primary>Network Attached Storage (<acronym>NAS</acronym>)</primary><see>Network File Systems</see></indexterm>+ <sect2 id="creating-cluster-filesystem">+ <title>File Systems</title>
<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.+ Generally, any file system with POSIX semantics can be used for+ PostgreSQL. Users prefer different file systems for a variety of reasons,+ including vendor support, performance, and familiarity. Experience+ suggests that, all other things being equal, one should not expect major+ performance or behavior changes merely from switching file systems or+ making minor file system configuration changes.
</para>
- <para>- Storage Area Networks (<acronym>SAN</acronym>) typically use communication- protocols other than <acronym>NFS</acronym>, and may or may not be subject- to hazards of this sort. It's advisable to consult the vendor's- documentation concerning data consistency guarantees.- <productname>PostgreSQL</productname> cannot be more reliable than- the file system it's using.- </para>+ <sect3 id="creating-cluster-nfs">+ <title>NFS</title>++ <indexterm zone="creating-cluster-nfs">+ <primary>NFS</primary>+ </indexterm>++ <para>+ It is possible to use an <acronym>NFS</acronym> file system for storing+ the <productname>PostgreSQL</productname> data directory.+ <productname>PostgreSQL</productname> does nothing special for+ <acronym>NFS</acronym> file systems, meaning it assumes+ <acronym>NFS</acronym> behaves exactly like locally-connected drives.+ <productname>PostgreSQL</productname> does not use any functionality that+ is known to have nonstandard behavior on <acronym>NFS</acronym>, such as+ file locking.+ </para>+ <para>+ The only firm requirement for using <acronym>NFS</acronym> with+ <productname>PostgreSQL</productname> 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 configuration will+ require a careful monitoring setup. The <literal>soft</literal> option+ will interrupt system calls in case of network problems, but+ <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.+ </para>++ <para>+ 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.+ </para>++ <para>+ In some cases, an external storage product can be accessed either via NFS+ or a lower-level protocol such as iSCSI. In the latter case, the storage+ appears as a block device and any available file system can be created on+ it. That approach might relieve the DBA from having to deal with some of+ the idiosyncrasies of NFS, but of course the complexity of managing+ remote storage then happens at other levels.+ </para>+ </sect3>
</sect2>
</sect1>
--
2.21.0
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: peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us, mail@joeconway.com
Subject: Re: Update section on NFS
In-Reply-To: <80bb96e0-be09-c2f5-0ce6-1c3b33de65c3@2ndquadrant.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