1<!--$Id: remote.so,v 11.12 2005/06/24 05:04:09 mjc Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Remote filesystems</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a><a name="3"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Environment</dl></b></td> 14<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> 15</td></tr></table> 16<p align=center><b>Remote filesystems</b></p> 17<p>When Berkeley DB database environment shared memory regions are backed by the 18filesystem, it is a common application error to create database 19environments backed by remote filesystems such as the Network File 20System (NFS), Windows network shares (SMB/CIFS) or the Andrew File 21System (AFS). Remote filesystems rarely support mapping files into 22process memory, and even more rarely support correct semantics for 23mutexes if the mapping succeeds. For this reason, we recommend database 24environment directories be created in a local filesystem.</p> 25<p>For remote filesystems that do allow remote files to be mapped into 26process memory, database environment directories accessed via remote 27filesystems cannot be used simultaneously from multiple clients (that 28is, from multiple computers). No commercial remote filesystem of which 29we're aware supports coherent, distributed shared memory for 30remote-mounted files. As a result, different machines will see 31different versions of these shared region files, and the behavior is 32undefined.</p> 33<p>Databases, log files, and temporary files may be placed on remote 34filesystems, as long as the remote filesystem fully supports standard 35POSIX filesystem semantics (although the application may incur a 36performance penalty for doing so). Further, read-only databases on 37remote filesystems can be accessed from multiple systems simultaneously. 38However, it is difficult (or impossible) for modifiable databases on 39remote filesystems to be accessed from multiple systems simultaneously. 40The reason is the Berkeley DB library caches modified database pages, and when 41those modified pages are written to the backing file is not entirely 42under application control. If two systems were to write database pages 43to the remote filesystem at the same time, database corruption could 44result. If a system were to write a database page back to the remote 45filesystem at the same time as another system read a page, a core dump 46in the reader could result.</p> 47<br> 48<b>FreeBSD note:</b><ul compact><li>Some historic FreeBSD releases will return ENOLCK from fsync and close 49calls on NFS-mounted filesystems, even though the call has succeeded. 50To support Berkeley DB on these releases, the Berkeley DB code should be modified 51to ignore ENOLCK errors, or no Berkeley DB files should be placed on 52NFS-mounted filesystems on these systems. Note that current FreeBSD 53releases do not suffer from this problem.</ul> 54<b>Linux note:</b><ul compact><li>Some historic Linux releases do not support complete semantics for the 55POSIX fsync call on NFS-mounted filesystems. No Berkeley DB files should be 56placed on NFS-mounted filesystems on these systems. Note that current 57Linux releases do not suffer from this problem.</ul> 58<br> 59<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> 60</td></tr></table> 61<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 62</body> 63</html> 64
