Document possible problems with NFS tablespaces.

doc/src/sgml/manage-ag.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.55 2007/11/04 19:43:33 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.56 2007/11/04 21:40:02 momjian Exp $ -->
 
 <chapter id="managing-databases">
  <title>Managing Databases</title>
@@ -495,5 +495,31 @@ 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>