pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedUpdate section on NFS
12+ messages / 5 participants
[nested] [flat]
* Update section on NFS
@ 2019-04-23 10:10 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 11:00 ` Re: Update section on NFS Martín Marqués <martin@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
0 siblings, 2 replies; 12+ messages in thread
From: Peter Eisentraut @ 2019-04-23 10:10 UTC (permalink / raw)
To: pgsql-docs
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
From 6b9430b395997955be718244d0061eceb1319a9e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Tue, 23 Apr 2019 12:03:57 +0200
Subject: [PATCH] doc: Update section on NFS
---
doc/src/sgml/runtime.sgml | 71 ++++++++++++++++++++++-----------------
1 file changed, 40 insertions(+), 31 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 388dc7e966..7c76f5b8aa 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -229,42 +229,51 @@ <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. (On Windows, all standard Windows file systems are
+ supported. XXX?) 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 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>
+
+ <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] 0001-doc-Update-section-on-NFS.patch (4.6K, ../../e90f24bb-5423-6abb-58ec-501176eb4afc@2ndquadrant.com/2-0001-doc-Update-section-on-NFS.patch)
download | inline diff:
From 6b9430b395997955be718244d0061eceb1319a9e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Tue, 23 Apr 2019 12:03:57 +0200
Subject: [PATCH] doc: Update section on NFS
---
doc/src/sgml/runtime.sgml | 71 ++++++++++++++++++++++-----------------
1 file changed, 40 insertions(+), 31 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 388dc7e966..7c76f5b8aa 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -229,42 +229,51 @@ <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. (On Windows, all standard Windows file systems are
+ supported. XXX?) 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 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>
+
+ <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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2019-04-23 11:00 ` Martín Marqués <martin@2ndquadrant.com>
2019-04-23 13:45 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 1 reply; 12+ messages in thread
From: Martín Marqués @ 2019-04-23 11:00 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 11:00 ` Re: Update section on NFS Martín Marqués <martin@2ndquadrant.com>
@ 2019-04-23 13:45 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 0 replies; 12+ messages in thread
From: Peter Eisentraut @ 2019-04-23 13:45 UTC (permalink / raw)
To: Martín Marqués <martin@2ndquadrant.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2019-04-23 12:31 ` Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 1 reply; 12+ messages in thread
From: Joe Conway @ 2019-04-23 12:31 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
@ 2019-04-23 13:47 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2019-04-23 13:47 UTC (permalink / raw)
To: Joe Conway <mail@joeconway.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2019-04-23 14:15 ` Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Joe Conway @ 2019-04-23 14:15 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-docs
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
Attachments:
[application/pgp-signature] signature.asc (832B, ../../950271f0-d8f3-a367-14b7-1f91e4d15e40@joeconway.com/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
@ 2019-04-23 15:11 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 16:53 ` Re: Update section on NFS Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2019-04-23 15:11 UTC (permalink / raw)
To: Joe Conway <mail@joeconway.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2019-04-23 16:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-04-24 08:54 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2019-04-23 16:53 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Joe Conway <mail@joeconway.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 16:53 ` Re: Update section on NFS Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-04-24 08:54 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-24 11:17 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2019-04-24 08:54 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Joe Conway <mail@joeconway.com>; pgsql-docs
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.sgml
index 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.sgml
index 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 16:53 ` Re: Update section on NFS Tom Lane <tgl@sss.pgh.pa.us>
2019-04-24 08:54 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
@ 2019-04-24 11:17 ` Joe Conway <mail@joeconway.com>
2019-04-26 07:41 ` Re: Update section on NFS Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Joe Conway @ 2019-04-24 11:17 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs
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
Attachments:
[application/pgp-signature] signature.asc (832B, ../../b49cf673-c14b-094c-3059-39d3279fb635@joeconway.com/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 16:53 ` Re: Update section on NFS Tom Lane <tgl@sss.pgh.pa.us>
2019-04-24 08:54 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-24 11:17 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
@ 2019-04-26 07:41 ` Thomas Munro <thomas.munro@gmail.com>
2019-04-26 09:52 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Munro @ 2019-04-26 07:41 UTC (permalink / raw)
To: Joe Conway <mail@joeconway.com>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Tom Lane <tgl@sss.pgh.pa.us>; 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Update section on NFS
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 16:53 ` Re: Update section on NFS Tom Lane <tgl@sss.pgh.pa.us>
2019-04-24 08:54 ` Re: Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-24 11:17 ` Re: Update section on NFS Joe Conway <mail@joeconway.com>
2019-04-26 07:41 ` Re: Update section on NFS Thomas Munro <thomas.munro@gmail.com>
@ 2019-04-26 09:52 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 0 replies; 12+ messages in thread
From: Peter Eisentraut @ 2019-04-26 09:52 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; Joe Conway <mail@joeconway.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs
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
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2019-04-26 09:52 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-04-23 10:10 Update section on NFS Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 11:00 ` Martín Marqués <martin@2ndquadrant.com>
2019-04-23 13:45 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 12:31 ` Joe Conway <mail@joeconway.com>
2019-04-23 13:47 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 14:15 ` Joe Conway <mail@joeconway.com>
2019-04-23 15:11 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-23 16:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-04-24 08:54 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-04-24 11:17 ` Joe Conway <mail@joeconway.com>
2019-04-26 07:41 ` Thomas Munro <thomas.munro@gmail.com>
2019-04-26 09:52 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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