<!--$Id: remote.html,v 1.2 2004/03/30 01:22:51 jtownsen Exp $--> <!--Copyright 1997-2003 by Sleepycat Software, Inc.--> <!--All rights reserved.--> <!--See the file LICENSE for redistribution information.--> <html> <head> <title>Berkeley DB Reference Guide: Remote filesystem</title> <meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> <meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> </head> <body bgcolor=white> <a name="2"><!--meow--></a><a name="3"><!--meow--></a> <table width="100%"><tr valign=top> <td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Environment</dl></h3></td> <td align=right><a href="../env/encrypt.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../env/faq.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p> <h3 align=center>Remote filesystem</h3> <p>When regions are backed by the filesystem, it is a common error to attempt to create Berkeley DB environments backed by remote filesystems such as the Network File System (NFS) or the Andrew File System (AFS). Remote filesystems rarely support mapping files into process memory, and even more rarely support correct semantics for mutexes after the attempt succeeds. For this reason, we strongly recommend that the database environment directory reside in a local filesystem.</p> <p>For remote filesystems that do allow system files to be mapped into process memory, home directories accessed via remote filesystems cannot be used simultaneously from multiple clients. None of the commercial remote filesystems available today implement coherent, distributed shared memory for remote-mounted files. As a result, different machines will see different versions of these shared regions, and the system behavior is undefined.</p> <p>Databases, log files, and temporary files may be placed on remote filesystems, <b>as long as the remote filesystem fully supports standard POSIX filesystem semantics</b> (although the application may incur a performance penalty for doing so). Obviously, NFS-mounted databases cannot be accessed from more than one Berkeley DB environment at a time (and therefore from more than one system), because no Berkeley DB database may be accessed from more than one Berkeley DB environment at a time.</p> <p><dl compact> <p><dt>FreeBSD note:<dd>Some FreeBSD releases are known to return ENOLCK from fsync and close calls on NFS-mounted filesystems, even though the call has succeeded. The Berkeley DB code should be modified to ignore ENOLCK errors, or no Berkeley DB files should be placed on NFS-mounted filesystems on these systems. <p><dt>Linux note:<dd>Some Linux releases are known to not support complete semantics for the POSIX fsync call on NFS-mounted filesystems. No Berkeley DB files should be placed on NFS-mounted filesystems on these systems. </dl> <table width="100%"><tr><td><br></td><td align=right><a href="../env/encrypt.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../env/faq.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1><a href="../../sleepycat/legal.html">Copyright (c) 1996-2003</a> <a href="http://www.sleepycat.com">Sleepycat Software, Inc.</a> - All rights reserved.</font> </body> </html>