3 .\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
4 .\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
6 .\" Manual: Netatalk 3.0
7 .\" Source: Netatalk 3.0
10 .TH "CNID_DBD" "8" "01 Jan 2012" "Netatalk 3.0" "Netatalk 3.0"
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\fBcnid_dbd\fR\fB\fR\ 'u
25 \fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR \fIvolpath\fR \fIctrlfd\fR \fIclntfd\fR \fIlogconfig_string\fR
27 \fBcnid_dbd\fR\fB\fR \-v | \-V
31 provides an interface for storage and retrieval of catalog node IDs (CNIDs) and related information to the
33 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\&.
44 is never started via the command line or system startup scripts but only by the
46 daemon\&. There is one instance of
48 per netatalk volume\&.
53 database library and uses transactionally protected updates\&. The
55 backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly\&.
58 inherits the effective userid and groupid from
60 on startup, which is normally caused by
62 serving a netatalk volume to a client\&. It changes to the
64 database home directory
66 that is associated with the volume\&. If the userid inherited from
70 will change userid and groupid to the owner and group of the database home directory\&. Otherwise, it will continue to use the inherited values\&.
72 will then attempt to open the database and start serving requests using filedescriptor
73 \fIclntfd\fR\&. Subsequent instances of
75 that want to access the same volume are redirected to the running
79 via the filedescriptor
84 \fBlogconfig_string\fR
87 to configure its logging output\&.
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)\&.
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 ithe transactional database changes\&. They will be removed regularily, unless the
102 \fBlogfile_autoremove\fR
103 option is specified in the
105 configuration file (see below) with a value of 0 (default 1)\&.
109 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
111 configuration file to put the database onto a local disk\&.
116 Show version and exit\&.
121 reads configuration information from the file
123 in the database directory
125 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:
127 \fBlogfile_autoremove\fR
129 If set to 0, unused Berkeley DB transactional logfiles (log\&.xxxxxxxxxx in the database home directory) are not removed on startup of
131 and on a reqular basis\&. Default: 1\&.
136 Determines the size of the Berkeley DB cache in kilobytes\&. Default: 8192\&. Each
138 process grabs that much memory on top of its normal memory footprint\&. It can be used to tune database performance\&. The
142 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
143 \fBBerkeley DB Tutorial and Reference Guide\fR
145 \fBSelecting a cache size\fR
146 that gives more detailed information\&.
149 \fBflush_frequency\fR, \fBflush_interval\fR
151 \fIflush_frequency\fR
154 (Default: 1800) control how often changes to the database are checkpointed\&. Both of these operations are performed if either i) more than
155 \fIflush_frequency\fR
156 requests have been received or ii) more than
158 seconds have elapsed since the last save/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\&.
163 is the maximum number of connections (filedescriptors) that can be open for
167 Default: 512\&. If this number is exceeded, one of the existing connections is closed and reused\&. The affected
169 process will transparently reconnect later, which causes slight overhead\&. On the other hand, setting this parameter too high could affect performance in
171 since all descriptors have to be checked in a
173 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
175 client process is expected to run, e\&.g\&. home directories\&.
180 is the number of seconds of inactivity before an idle
182 exits\&. Default: 600\&. Set this to 0 to disable the timeout\&.
186 Note that the first version to appear
188 Netatalk 2\&.1 ie Netatalk 2\&.1\&.1, will support BerkeleyDB updates on the fly without manual intervention\&. In other words Netatalk 2\&.1 does contain code to prepare the BerkeleyDB database for upgrades and to upgrade it in case it has been prepared before\&. That means it can\'t upgrade a 2\&.0\&.x version because that one didn\'t prepare the database\&.
190 In order to update between older Netatalk releases using different BerkeleyDB library versions, follow this steps:
200 Stop the to be upgraded old version of Netatalk
211 Using the old BerkeleyDB utilities run
212 \fBdb_recover \-h <path to \&.AppleDB>\fR
223 Using the new BerkeleyDB utilities run
224 \fBdb_upgrade \-v \-h <path to \&.AppleDB> \-f cnid2\&.db\fR
235 Again using the new BerkeleyDB utilities run
236 \fBdb_checkpoint \-1 \-h <path to \&.AppleDB>\fR
247 Start the the new version of Netatalk