|
  
|
Remote filesystems
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.
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.
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). 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.
- Linux note:
- 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.
|
|