Move NFS section into "Creating Cluster" documentation section because

it seems more logical there.

doc/src/sgml/manage-ag.sgml

@@ -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>

doc/src/sgml/runtime.sgml

@@ -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>