mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Move NFS section into "Creating Cluster" documentation section because

Browse Source 
it seems more logical there.
This commit is contained in:
Bruce Momjian 2007-11-08 15:21:03 +00:00
parent 4c726d5c11
commit 5db1c58a1a
2 changed files with 30 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/src/sgml/manage-ag.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.56 2007/11/04 21:40:02 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.57 2007/11/08 15:21:03 momjian Exp $ -->
<chapter id="managing-databases">
<title>Managing Databases</title>
@ -495,31 +495,5 @@ SELECT spcname FROM pg_tablespace;
the old tablespace locations.)
</para>
<sect2 id="manage-ag-tablespaces-nfs">
<title>Network File Systems</title>
<indexterm zone="manage-ag-tablespaces-nfs">
<primary>Network File Systems</primary>
</indexterm>
<indexterm><primary><acronym>NFS</></><see>Network File Systems</></>
<indexterm><primary>Network Attached Storage (<acronym>NAS</>)</><see>Network File Systems</></>
<para>
Many installations create tablespace on network file systems.
Sometimes this is done directly via <acronym>NFS</>, or by using a
Network Attached Storage (<acronym>NAS</>) device that uses
<acronym>NFS</> internally. <productname>PostgreSQL</> does nothing
special for <acronym>NFS</> file systems, meaning it assumes
<acronym>NFS</> behaves exactly like locally-connected drives. If
client and server <acronym>NFS</> implementations have non-standard
semantics, this can cause reliability problems (see <ulink
url="http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html"></ulink>).
Specifically, delayed (asynchonous) writes to the <acronym>NFS</>
server can cause reliability problems; if possible, mount
<acronym>NFS</> file systems synchonously to avoid this.
</para>
</sect2>
</sect1>
</chapter>

34
doc/src/sgml/runtime.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.384 2007/11/04 21:50:28 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.385 2007/11/08 15:21:03 momjian Exp $ -->
<chapter Id="runtime">
<title>Operating System Environment</title>
@ -160,10 +160,34 @@ postgres$ <userinput>initdb -D /usr/local/pgsql/data</userinput>
locale setting. For details see <xref linkend="multibyte">.
</para>
<para>
If using non-local (network) file systems, see <xref
linkend="manage-ag-tablespaces-nfs">.
</para>
<sect2 id="creating-cluster-nfs">
<title>Network File Systems</title>
<indexterm zone="creating-cluster-nfs">
<primary>Network File Systems</primary>
</indexterm>
<indexterm><primary><acronym>NFS</></><see>Network File Systems</></>
<indexterm><primary>Network Attached Storage (<acronym>NAS</>)</><see>Network File Systems</></>
<para>
Many installations create database clusters on network file systems.
Sometimes this is done directly via <acronym>NFS</>, or by using a
Network Attached Storage (<acronym>NAS</>) device that uses
<acronym>NFS</> internally. <productname>PostgreSQL</> does nothing
special for <acronym>NFS</> file systems, meaning it assumes
<acronym>NFS</> behaves exactly like locally-connected drives
(<acronym>DAS</>, Direct Attached Storage). If client and server
<acronym>NFS</> implementations have non-standard semantics, this can
cause reliability problems (see <ulink
url="http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html"></ulink>).
Specifically, delayed (asynchonous) writes to the <acronym>NFS</>
server can cause reliability problems; if possible, mount
<acronym>NFS</> file systems synchonously (without caching) to avoid
this. (Storage Area Networks (<acronym>SAN</>) use a low-level
communication protocol rather than <acronym>NFS</>.)
</para>
</sect2>
</sect1>