Sindbad~EG File Manager
<?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>Memory-only or Flash configurations</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="program.html" title="Chapter 16. Programmer Notes" />
<link rel="prev" href="program_namespace.html" title="Name spaces" />
<link rel="next" href="program_cache.html" title="Disk drive caches" />
</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">Memory-only or Flash
configurations</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="program_namespace.html">Prev</a> </td>
<th width="60%" align="center">Chapter 16. Programmer Notes </th>
<td width="20%" align="right"> <a accesskey="n" href="program_cache.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="program_ram"></a>Memory-only or Flash
configurations</h2>
</div>
</div>
</div>
<p>
Berkeley DB supports a variety of memory-based
configurations for systems where filesystem space is either
limited in availability or entirely replaced by some
combination of memory and Flash. In addition, Berkeley DB can
be configured to minimize writes to the filesystem when the
filesystem is backed by Flash memory.
</p>
<p>
There are four parts of the Berkeley DB database environment
normally written to the filesystem: the database environment
region files, the database files, the database environment log
files and the replication internal files. Each of these items
can be configured to live in memory rather than in the
filesystem:
</p>
<div class="variablelist">
<dl>
<dt>
<span class="term">The database environment region files:</span>
</dt>
<dd>
<p>
Each of the Berkeley DB subsystems in a
database environment is described by one or more
regions, or chunks of memory. The regions contain
all of the per-process and per-thread shared
information (including mutexes), that comprise a
Berkeley DB environment. By default, these regions
are backed by the filesystem. In situations where
filesystem backed regions aren't optimal,
applications can create memory-only database
environments in two different types of memory:
either in the application's heap memory or in
system shared memory.
</p>
<p>
To create the database environment in heap
memory, specify the <a href="../api_reference/C/envopen.html#envopen_DB_PRIVATE" class="olink">DB_PRIVATE</a> flag to the
<a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method. Note that database environments
created in heap memory are only accessible to the
threads of a single process, however.
</p>
<p>
To create the database environment in system
shared memory, specify the <a href="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM" class="olink">DB_SYSTEM_MEM</a> flag to
the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method. Database environments
created in system memory are accessible to
multiple processes, but note that database
environments created in system shared memory do
create a small (roughly 8 byte) file in the
filesystem, read by the processes to identify
which system shared memory segments to use.
</p>
<p>
For more information, see <a class="xref" href="env_region.html" title="Shared memory regions">Shared memory regions</a>.
</p>
</dd>
<dt>
<span class="term">The database files:</span>
</dt>
<dd>
<p>
By default, databases are periodically flushed
from the Berkeley DB memory cache to backing
physical files in the filesystem. To keep
databases from being written to backing physical
files, pass the <a href="../api_reference/C/mempset_flags.html#mpool_set_flags_DB_MPOOL_NOFILE" class="olink">DB_MPOOL_NOFILE</a> flag to the
<a href="../api_reference/C/mempset_flags.html" class="olink">DB_MPOOLFILE->set_flags()</a> method. This flag implies the
application's databases must fit entirely in the
Berkeley DB cache, of course. To avoid a database
file growing to consume the entire cache,
applications can limit the size of individual
databases in the cache by calling the
<a href="../api_reference/C/mempset_maxsize.html" class="olink">DB_MPOOLFILE->set_maxsize()</a> method.
</p>
</dd>
<dt>
<span class="term">The database environment log files:</span>
</dt>
<dd>
<p>
If a database environment is not intended to be
transactionally recoverable after application or
system failure (that is, if it will not exhibit
the transactional attribute of "durability"),
applications should not configure the database
environment for logging or transactions, in which
case no log files will be created. If the database
environment is intended to be durable, log files
must either be written to stable storage and
recovered after application or system failure, or
they must be replicated to other systems.
</p>
<p>
In applications running on systems without any
form of stable storage, durability must be
accomplished through replication. In this case,
database environments should be configured to
maintain database logs in memory, rather than in
the filesystem, by specifying the
<a href="../api_reference/C/envlog_set_config.html#log_set_config_DB_LOG_IN_MEMORY" class="olink">DB_LOG_IN_MEMORY</a> flag to the <a href="../api_reference/C/envlog_set_config.html" class="olink">DB_ENV->log_set_config()</a>
method.
</p>
</dd>
<dt>
<span class="term">The replication internal files:</span>
</dt>
<dd>
<p>
By default, Berkeley DB replication stores a
small amount of internal data in the filesystem.
To store this replication internal data in memory
only and not in the filesystem, specify the
<a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_INMEM" class="olink">DB_REP_CONF_INMEM</a> flag to the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method
before opening the database environment.
</p>
</dd>
</dl>
</div>
<p>
In systems where the filesystem is backed by Flash memory,
the number of times the Flash memory is written may be a
concern. Each of the four parts of the Berkeley DB database
environment normally written to the filesystem can be
configured to minimize the number of times the filesystem is
written:
</p>
<div class="variablelist">
<dl>
<dt>
<span class="term">The database environment region files:</span>
</dt>
<dd>
<p>
On a Flash-based filesystem, the database
environment should be placed in heap or system
memory, as described previously.
</p>
</dd>
<dt>
<span class="term">The database files:</span>
</dt>
<dd>
<p>
The Berkeley DB library maintains a cache of
database pages. The database pages are only
written to backing physical files when the
application checkpoints the database environment
with the <a href="../api_reference/C/txncheckpoint.html" class="olink">DB_ENV->txn_checkpoint()</a> method, when database
handles are closed with the <a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> method, or
when the application explicitly flushes the cache
with the <a href="../api_reference/C/dbsync.html" class="olink">DB->sync()</a> or <a href="../api_reference/C/mempsync.html" class="olink">DB_ENV->memp_sync()</a> methods.
</p>
<p>
To avoid unnecessary writes of Flash memory due
to checkpoints, applications should decrease the
frequency of their checkpoints. This is especially
important in applications which repeatedly modify
a specific database page, as repeatedly writing a
database page to the backing physical file will
repeatedly update the same blocks of the
filesystem.
</p>
<p>
To avoid unnecessary writes of the filesystem
due to closing a database handle, applications
should specify the <a href="../api_reference/C/dbclose.html#dbclose_DB_NOSYNC" class="olink">DB_NOSYNC</a> flag to the
<a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> method.
</p>
<p>
To avoid unnecessary writes of the filesystem
due to flushing the cache, applications should not
explicitly flush the cache under normal conditions
– flushing the cache is rarely if ever
needed in a normally-running application.
</p>
</dd>
<dt>
<span class="term">The database environment log files:</span>
</dt>
<dd>
<p>
The Berkeley DB log files do not repeatedly
overwrite the same blocks of the filesystem as the
Berkeley DB log files are not implemented as a
circular buffer and log files are not re-used. For
this reason, the Berkeley DB log files should not
cause any difficulties for Flash memory
configurations.
</p>
<p>
However, as Berkeley DB does not write log
records in filesystem block sized pieces, it is
probable that sequential transaction commits (each
of which flush the log file to the backing
filesystem), will write a block of Flash memory
twice, as the last log record from the first
commit will write the same block of Flash memory
as the first log record from the second commit.
Applications not requiring absolute durability
should specify the <a href="../api_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a> or
<a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">DB_TXN_NOSYNC</a> flags to the <a href="../api_reference/C/envset_flags.html" class="olink">DB_ENV->set_flags()</a> method
to avoid this overwrite of a block of Flash
memory.
</p>
</dd>
<dt>
<span class="term">The replication internal files:</span>
</dt>
<dd>
<p>
On a Flash-based filesystem, the replication
internal data should be stored in memory only, as
described previously.
</p>
</dd>
</dl>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="program_namespace.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="program.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="program_cache.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Name spaces </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Disk drive caches</td>
</tr>
</table>
</div>
</body>
</html>
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists