3 .\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
4 .\" Generator: DocBook XSL Stylesheets v1.74.3 <http://docbook.sf.net/>
6 .\" Manual: Netatalk 2.0.4
7 .\" Source: Netatalk 2.0.4
10 .TH "CNID_DBD" "8" "2 Dec 2003" "Netatalk 2\&.0\&.4" "Netatalk 2.0.4"
11 .\" -----------------------------------------------------------------
12 .\" * set default formatting
13 .\" -----------------------------------------------------------------
14 .\" disable hyphenation
16 .\" disable justification (adjust text to left margin only)
18 .\" -----------------------------------------------------------------
19 .\" * MAIN CONTENT STARTS HERE *
20 .\" -----------------------------------------------------------------
22 cnid_dbd \- implement access to CNID databases through a dedicated daemon process
24 .HP \w'\fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR\ 'u
25 \fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR \fIdbdir\fR \fIctrlfd\fR \fIclntfd\fR
29 provides an interface for storage and retrieval of catalog node IDs (CNIDs) and related information to the
31 daemon\&. CNIDs are a component of Macintosh based file systems with semantics that map not easily onto Unix file systems\&. This makes separate storage in a database necessary\&.
42 is never started via the command line or system startup scripts but only by the
44 daemon\&. There is at most one instance of
46 per netatalk volume\&.
51 database library and optionally supports transactionally protected updates if the netatalk package is compiled with the appropriate options\&. Using the
53 backend without transactions will protect the CNID database against unexpected crashes of the
57 backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly\&.
60 uses the same on\-disk database format as the
62 backend\&. It is therefore possible to switch between the two backends as necessary\&.
65 inherits the effective userid and groupid from
67 on startup, which is normally caused by
69 serving a netatalk volume to a client\&. It changes to the
71 database home directory
73 that is associated with the volume\&. If the userid inherited from
77 will change userid and groupid to the owner and group of the database home directory\&. Otherwise, it will continue to use the inherited values\&.
79 will then attempt to open the database and start serving requests using filedescriptor
80 \fIclntfd\fR\&. Subsequent instances of
82 that want to access the same volume are redirected to the running
86 via the filedescriptor
90 can be configured to run forever or to exit after a period of inactivity\&. If
92 receives a TERM or an INT signal it will exit cleanly after flushing dirty database buffers to disk and closing
94 database environments\&. It is safe to terminate
96 this way, it will be restarted when necessary\&. Other signals are not handled and will cause an immediate exit, possibly leaving the CNID database in an inconsistent state (no transactions) or losing recent updates during recovery (transactions)\&.
98 If transactions are used the
100 database subsystem will create files named log\&.xxxxxxxxxx in the database home directory
101 \fIdbdir\fR, where xxxxxxxxxx is a monotonically increasing integer\&. These files contain information to replay database changes and are not automatically removed, unless the
102 \fBlogfile_autoremove\fR
103 option is specified in the
105 configuration file (see below)\&. Please see the sections
106 \fBDatabase and log file archival\fR,
107 \fB Log file removal\fR
108 and the documentation of the
110 command line utility in the Berkeley DB Tutorial and Reference for information when and how it is safe to remove these files manually\&.
114 for databases on NFS mounted file systems\&. It makes the whole point of securing database changes properly moot\&. Use the dbdir: Option in the appropriate
116 configuration file to put the database onto a local disk\&.
120 reads configuration information from the file
122 in the database directory
124 on startup\&. If the file does not exist or a parameter is not listed, suitable default values are used\&. The format for a single parameter is the parameter name, followed by one or more spaces, followed by the parameter value, followed by a newline\&. The following parameters are currently recognized:
126 \fBlogfile_autoremove\fR
128 This flag is ignored unless transactional support is enabled\&. If set to 1, unused Berkeley DB transactional logfiles (log\&.xxxxxxxxxx in the database home directory) are removed on startup of
129 \fBcnid_dbd\fR\&. This is usually safe if the content of the database directory is backed up on a regular basis\&. Default: 0\&.
134 Determines the size of the Berkeley DB cache in kilobytes\&. Default: 1024\&. Each
136 process grabs that much memory on top of its normal memory footprint\&. It can be used to tune database performance\&. The
140 option that comes with Berkely DB can help you determine wether you need to change this value\&. The default is pretty conservative so that a large percentage of requests should be satisfied from the cache directly\&. If memory is not a bottleneck on your system you might want to leave it at that value\&. The
141 \fBBerkeley DB Tutorial and Reference Guide\fR
143 \fBSelecting a cache size\fR
144 that gives more detailed information\&.
149 This flag is ignored unless transactional support is enabled\&. If it is set to 1, transactional changes to the database are not synchronously written to disk when the transaction completes\&. This will increase performance considerably at the risk of recent changes getting lost in case of a crash\&. The database will still be consistent, though\&. See
150 \fBTransaction Throughput\fR
151 in the Berkeley DB Tutorial for more information\&. Default: 0\&.
154 \fBflush_frequency\fR, \fBflush_interval\fR
156 \fIflush_frequency\fR
159 (Default: 30) control how often changes to the database are written to the underlying database files if no transactions are used or how often the transaction system is checkpointed for transactions\&. Both of these operations are performed if either i) more than
160 \fIflush_frequency\fR
161 requests have been received or ii) more than
163 seconds have elapsed since the last save/checkpoint\&. If you use transactions with
165 set to zero these parameters only influence how long recovery takes after a crash, there should never be any lost data\&. If
167 is 1, changes might be lost, but only since the last checkpoint\&. Be careful to check your harddisk configuration for on disk cache settings\&. Many IDE disks just cache writes as the default behaviour, so even flushing database files to disk will not have the desired effect\&.
172 is the maximum number of connections (filedescriptors) that can be open for
176 Default: 16\&. If this number is exceeded, one of the existing connections is closed and reused\&. The affected
178 process will transparently reconnect later, which causes slight overhead\&. On the other hand, setting this parameter too high could affect performance in
180 since all descriptors have to be checked in a
182 system call, or worse, you might exceed the per process limit of open file descriptors on your system\&. It is safe to set the value to 1 on volumes where only one
184 client process is expected to run, e\&.g\&. home directories\&.
189 is the number of seconds of inactivity before an idle
191 exits\&. Default: 600\&. Set this to 0 to disable the timeout\&.
196 is a flag value\&. If set
198 will automatically check the database indexes\&. Default: 0\&. Set this to 1 to enable checking\&.