diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/env_remote.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/env_remote.html')
| -rw-r--r-- | docs/programmer_reference/env_remote.html | 106 |
1 files changed, 62 insertions, 44 deletions
diff --git a/docs/programmer_reference/env_remote.html b/docs/programmer_reference/env_remote.html index 197c3f7a..fd257dff 100644 --- a/docs/programmer_reference/env_remote.html +++ b/docs/programmer_reference/env_remote.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="env_encrypt.html">Prev</a> </td> - <th width="60%" align="center">Chapter 9. - The Berkeley DB Environment - </th> + <th width="60%" align="center">Chapter 9. The Berkeley DB Environment </th> <td width="20%" align="right"> <a accesskey="n" href="env_faq.html">Next</a></td> </tr> </table> @@ -38,54 +36,74 @@ </div> </div> </div> - <p>When Berkeley DB database environment shared memory regions are backed by the -filesystem, it is a common application error to create database -environments backed by remote filesystems such as the Network File -System (NFS), Windows network shares (SMB/CIFS) or the Andrew File -System (AFS). Remote filesystems rarely support mapping files into -process memory, and even more rarely support correct semantics for -mutexes if the mapping succeeds. For this reason, we recommend database -environment directories be created in a local filesystem.</p> - <p>For remote filesystems that do allow remote files to be mapped into -process memory, database environment directories accessed via remote -filesystems cannot be used simultaneously from multiple clients (that -is, from multiple computers). No commercial remote filesystem of which -we're aware supports coherent, distributed shared memory for -remote-mounted files. As a result, different machines will see -different versions of these shared region files, and the behavior is -undefined.</p> - <p>Databases, log files, and temporary files may be placed on remote -filesystems, as long as the remote filesystem fully supports standard -POSIX filesystem semantics (although the application may incur a -performance penalty for doing so). Further, read-only databases on -remote filesystems can be accessed from multiple systems simultaneously. -However, it is difficult (or impossible) for modifiable databases on -remote filesystems to be accessed from multiple systems simultaneously. -The reason is the Berkeley DB library caches modified database pages, and when -those modified pages are written to the backing file is not entirely -under application control. If two systems were to write database pages -to the remote filesystem at the same time, database corruption could -result. If a system were to write a database page back to the remote -filesystem at the same time as another system read a page, a core dump -in the reader could result.</p> + <p> + When Berkeley DB database environment shared memory regions + are backed by the filesystem, it is a common application error + to create database environments backed by remote filesystems + such as the Network File System (NFS), Windows network shares + (SMB/CIFS) or the Andrew File System (AFS). Remote filesystems + rarely support mapping files into process memory, and even + more rarely support correct semantics for mutexes if the + mapping succeeds. For this reason, we recommend database + environment directories be created in a local + filesystem. + </p> + <p> + For remote filesystems that do allow remote files to be + mapped into process memory, database environment directories + accessed via remote filesystems cannot be used simultaneously + from multiple clients (that is, from multiple computers). No + commercial remote filesystem of which we're aware supports + coherent, distributed shared memory for remote-mounted files. + As a result, different machines will see different versions of + these shared region files, and the behavior is + undefined. + </p> + <p> + Databases, log files, and temporary files may be placed on + remote filesystems, as long as the remote filesystem fully + supports standard POSIX filesystem semantics (although the + application may incur a performance penalty for doing so). + Further, read-only databases on remote filesystems can be + accessed from multiple systems simultaneously. However, it is + difficult (or impossible) for modifiable databases on remote + filesystems to be accessed from multiple systems + simultaneously. The reason is the Berkeley DB library caches + modified database pages, and when those modified pages are + written to the backing file is not entirely under application + control. If two systems were to write database pages to the + remote filesystem at the same time, database corruption could + result. If a system were to write a database page back to the + remote filesystem at the same time as another system read a + page, a core dump in the reader could result. + </p> <div class="variablelist"> <dl> <dt> <span class="term">FreeBSD note:</span> </dt> - <dd>Some historic FreeBSD releases will return ENOLCK from fsync and close -calls on NFS-mounted filesystems, even though the call has succeeded. -To support Berkeley DB on these releases, 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. Note that current FreeBSD -releases do not suffer from this problem.</dd> + <dd> + Some historic FreeBSD releases will return + ENOLCK from fsync and close calls on NFS-mounted + filesystems, even though the call has succeeded. To + support Berkeley DB on these releases, 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. Note that current + FreeBSD releases do not suffer from this + problem. + </dd> <dt> <span class="term">Linux note:</span> </dt> - <dd>Some historic Linux releases do 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. Note that current -Linux releases do not suffer from this problem.</dd> + <dd> + Some historic Linux releases do 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. + Note that current Linux releases do not suffer from + this problem. + </dd> </dl> </div> </div> |