###

Berkeley DB Reference Guide:
  Environment

# Remote filesystems

When regions are backed by the filesystem, it is a common error to attempt to create Berkeley DB environments backed by remote file systems 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 file systems that do allow system files to be mapped into process memory, home directories accessed via remote file systems cannot be used simultaneously from multiple clients. None of the commercial remote file systems 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 (and therefore from more than one system), at a time since 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.

Copyright Sleepycat Software