remote.so

berkeley db 4.6.21的源码。berkeley db是一个简单的数据库管理系统

m4_comment([$Id: remote.so,v 11.12 2005/06/24 05:04:09 mjc Exp $])

m4_ref_title(Environment,
    Remote filesystems,
    [remote @filesystems, NFS problems], env/encrypt, env/faq)

m4_p([dnl
When m4_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.])

m4_p([dnl
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.])

m4_p([dnl
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 m4_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.])

m4_tagbegin

m4_tag([FreeBSD note:], [dnl
Some historic FreeBSD releases will return ENOLCK from fsync and close
calls on NFS-mounted filesystems, even though the call has succeeded.
To support m4_db on these releases, the m4_db code should be modified
to ignore ENOLCK errors, or no m4_db files should be placed on
NFS-mounted filesystems on these systems.  Note that current FreeBSD
releases do not suffer from this problem.])

m4_tag([Linux note:], [dnl
Some historic Linux releases do not support complete semantics for the
POSIX fsync call on NFS-mounted filesystems.  No m4_db files should be
placed on NFS-mounted filesystems on these systems.  Note that current
Linux releases do not suffer from this problem.])

m4_tagend

m4_page_footer