3 .\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
4 .\" Generator: DocBook XSL Stylesheets v1.78.0 <http://docbook.sf.net/>
6 .\" Manual: @NETATALK_VERSION@
7 .\" Source: @NETATALK_VERSION@
10 .TH "CNID_DBD" "8" "01 Jan 2012" "@NETATALK_VERSION@" "@NETATALK_VERSION@"
11 .\" -----------------------------------------------------------------
12 .\" * Define some portability stuff
13 .\" -----------------------------------------------------------------
14 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15 .\" http://bugs.debian.org/507673
16 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
17 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
20 .\" -----------------------------------------------------------------
21 .\" * set default formatting
22 .\" -----------------------------------------------------------------
23 .\" disable hyphenation
25 .\" disable justification (adjust text to left margin only)
27 .\" -----------------------------------------------------------------
28 .\" * MAIN CONTENT STARTS HERE *
29 .\" -----------------------------------------------------------------
31 cnid_dbd \- implement access to CNID databases through a dedicated daemon process
33 .HP \w'\fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR\fBcnid_dbd\fR\fB\fR\ 'u
34 \fBcnid_dbd\fR\fB\fR\fB\fR\fB\fR
36 \fBcnid_dbd\fR\fB\fR \-v | \-V
40 provides an interface for storage and retrieval of catalog node IDs (CNIDs) and related information to the
42 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\&.
53 is never started via the command line or system startup scripts but only by the
55 daemon\&. There is one instance of
57 per netatalk volume\&.
62 database library and uses transactionally protected updates\&. The
64 backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly\&.
67 inherits the effective userid and groupid from
69 on startup, which is normally caused by
71 serving a netatalk volume to a client\&. It changes to the
73 database home directory
75 that is associated with the volume\&. If the userid inherited from
79 will change userid and groupid to the owner and group of the database home directory\&. Otherwise, it will continue to use the inherited values\&.
81 will then attempt to open the database and start serving requests using filedescriptor
82 \fIclntfd\fR\&. Subsequent instances of
84 that want to access the same volume are redirected to the running
88 via the filedescriptor
92 can be configured to run forever or to exit after a period of inactivity\&. If
94 receives a TERM or an INT signal it will exit cleanly after flushing dirty database buffers to disk and closing
96 database environments\&. It is safe to terminate
98 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)\&.
102 database subsystem will create files named log\&.xxxxxxxxxx in the database home directory
103 \fIdbdir\fR, where xxxxxxxxxx is a monotonically increasing integer\&. These files contain the transactional database changes\&. They will be removed regularly, unless the
104 \fBlogfile_autoremove\fR
105 option is specified in the
107 configuration file (see below) with a value of 0 (default 1)\&.
112 Show version and exit\&.
117 reads configuration information from the file
119 in the database directory
121 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:
123 \fBlogfile_autoremove\fR
125 If set to 0, unused Berkeley DB transactional logfiles (log\&.xxxxxxxxxx in the database home directory) are not removed on startup of
127 and on a regular basis\&. Default: 1\&.
132 Determines the size of the Berkeley DB cache in kilobytes\&. Default: 8192\&. Each
134 process grabs that much memory on top of its normal memory footprint\&. It can be used to tune database performance\&. The
138 option that comes with Berkley DB can help you determine ether 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
139 \fBBerkeley DB Tutorial and Reference Guide\fR
141 \fBSelecting a cache size\fR
142 that gives more detailed information\&.
145 \fBflush_frequency\fR, \fBflush_interval\fR
147 \fIflush_frequency\fR
150 (Default: 1800) control how often changes to the database are checkpointed\&. Both of these operations are performed if either i) more than
151 \fIflush_frequency\fR
152 requests have been received or ii) more than
154 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\&.
159 is the maximum number of connections (filedescriptors) that can be open for
163 Default: 512\&. If this number is exceeded, one of the existing connections is closed and reused\&. The affected
165 process will transparently reconnect later, which causes slight overhead\&. On the other hand, setting this parameter too high could affect performance in
167 since all descriptors have to be checked in a
169 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
171 client process is expected to run, e\&.g\&. home directories\&.
176 is the number of seconds of inactivity before an idle
178 exits\&. Default: 600\&. Set this to 0 to disable the timeout\&.
182 Note that the first version to appear
184 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\*(Aqt upgrade a 2\&.0\&.x version because that one didn\*(Aqt prepare the database\&.
186 In order to update between older Netatalk releases using different BerkeleyDB library versions, follow this steps:
196 Stop the to be upgraded old version of Netatalk
207 Using the old BerkeleyDB utilities run
208 \fBdb_recover \-h <path to \&.AppleDB>\fR
219 Using the new BerkeleyDB utilities run
220 \fBdb_upgrade \-v \-h <path to \&.AppleDB> \-f cnid2\&.db\fR
231 Again using the new BerkeleyDB utilities run
232 \fBdb_checkpoint \-1 \-h <path to \&.AppleDB>\fR
243 Start the the new version of Netatalk