mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
131 lines
5.8 KiB
HTML
131 lines
5.8 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
<title>Remote filesystems</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
|
||
<link rel="up" href="env.html" title="Chapter 9. The Berkeley DB Environment" />
|
||
<link rel="prev" href="env_encrypt.html" title="Encryption" />
|
||
<link rel="next" href="env_faq.html" title="Environment FAQ" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 18.1.40</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Remote filesystems</th>
|
||
</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>
|
||
<td width="20%" align="right"> <a accesskey="n" href="env_faq.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title" style="clear: both"><a id="env_remote"></a>Remote filesystems</h2>
|
||
</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>
|
||
<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>
|
||
<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>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="env_encrypt.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="env.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="env_faq.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Encryption </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Environment FAQ</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|