Move NFS section into "Creating Cluster" documentation section because

it seems more logical there.

diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index 4c5406673482e32bfd330d28b8e318cc5254f6e1..bc128ec3a71c65f86d8f75092822ba8b4c4ae5e4 100644 (file)
--- a/doc/src/sgml/manage-ag.sgml
+++ b/doc/src/sgml/manage-ag.sgml
@@ -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>

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 1276b7b1fa8591ff44918c11662be9acccad7821..0f8ed5eef9c0da9c79dd73bb371019f6b13c3677 100644 (file)
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -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>