Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 9. - The Berkeley DB Environment -	Chapter 9. The Berkeley DB Environment	Next

@@ -38,54 +36,74 @@

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.

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.

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.

+ 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. +

+ 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. +

+ 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. +

FreeBSD note:: 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.; + 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. +
Linux note:: 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.; + 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. +