1CNID_DBD(8) Netatalk 2.1 CNID_DBD(8)
2
6 cnid_dbd - implement access to CNID databases through a dedicated
7 daemon process
8
10 cnid_dbd dbdir ctrlfd clntfd logconfig_string
11
13 cnid_dbd provides an interface for storage and retrieval of catalog
14 node IDs (CNIDs) and related information to the afpd daemon. CNIDs are
15 a component of Macintosh based file systems with semantics that map not
16 easily onto Unix file systems. This makes separate storage in a
17 database necessary. cnid_dbd is part of the CNID backend framework of
18 afpd and implements the dbd backend.
19 cnid_dbd is never started via the command line or system startup
21 scripts but only by the cnid_metad daemon. There is at most one
22 instance of cnid_dbd per netatalk volume.
23 cnid_dbd uses the Berkleley DB database library and uses
25 transactionally protected updates. The dbd backend with transactions
26 will avoid corruption of the CNID database even if the system crashes
27 unexpectedly.
28 cnid_dbd uses the same on-disk database format as the cdb backend. It
30 is therefore possible to switch between the two backends as necessary.
31 cnid_dbd inherits the effective userid and groupid from cnid_metad on
33 startup, which is normally caused by afpd serving a netatalk volume to
34 a client. It changes to the Berkleley DB database home directory dbdir
35 that is associated with the volume. If the userid inherited from
36 cnid_metad is 0 (root), cnid_dbd will change userid and groupid to the
37 owner and group of the database home directory. Otherwise, it will
38 continue to use the inherited values. cnid_dbd will then attempt to
39 open the database and start serving requests using filedescriptor
40 clntfd. Subsequent instances of afpd that want to access the same
41 volume are redirected to the running cnid_dbd process by cnid_metad via
42 the filedescriptor ctrlfd.
43 cnid_dbd uses logconfig_string which is passed from cnid_metad to
45 configure its logging output.
46 cnid_dbd can be configured to run forever or to exit after a period of
48 inactivity. If cnid_dbd receives a TERM or an INT signal it will exit
49 cleanly after flushing dirty database buffers to disk and closing
50 Berkleley DB database environments. It is safe to terminate cnid_dbd
51 this way, it will be restarted when necessary. Other signals are not
52 handled and will cause an immediate exit, possibly leaving the CNID
53 database in an inconsistent state (no transactions) or losing recent
54 updates during recovery (transactions).
55 The Berkleley DB database subsystem will create files named
57 log.xxxxxxxxxx in the database home directory dbdir, where xxxxxxxxxx
58 is a monotonically increasing integer. These files contain ithe
59 transactional database changes. They will be removed regularily, unless
60 the logfile_autoremove option is specified in the db_param
61 configuration file (see below).
62 Do not use cnid_dbd for databases on NFS mounted file systems. It makes
64 the whole point of securing database changes properly moot. Use the
65 dbdir: Option in the appropriate AppleVolumes configuration file to put
66 the database onto a local disk.
67
69 cnid_dbd reads configuration information from the file db_param in the
70 database directory dbdir on startup. If the file does not exist or a
71 parameter is not listed, suitable default values are used. The format
72 for a single parameter is the parameter name, followed by one or more
73 spaces, followed by the parameter value, followed by a newline. The
74 following parameters are currently recognized:
75 logfile_autoremove
77 If set to 0, unused Berkeley DB transactional logfiles
78 (log.xxxxxxxxxx in the database home directory) are not removed on
79 startup of cnid_dbd and on a reqular basis. Default: 1.
80 cachesize
82 Determines the size of the Berkeley DB cache in kilobytes. Default:
83 8192. Each cnid_dbd process grabs that much memory on top of its
84 normal memory footprint. It can be used to tune database
85 performance. The db_stat utility with the -m option that comes with
86 Berkely DB can help you determine wether you need to change this
87 value. The default is pretty conservative so that a large
88 percentage of requests should be satisfied from the cache directly.
89 If memory is not a bottleneck on your system you might want to
90 leave it at that value. The Berkeley DB Tutorial and Reference
91 Guide has a section Selecting a cache size that gives more detailed
92 information.
93 flush_frequency, flush_interval
95 flush_frequency (Default: 1000) and flush_interval (Default: 1800)
96 control how often changes to the database are checkpointed. Both of
97 these operations are performed if either i) more than
98 flush_frequency requests have been received or ii) more than
99 flush_interval seconds have elapsed since the last save/checkpoint.
100 Be careful to check your harddisk configuration for on disk cache
101 settings. Many IDE disks just cache writes as the default
102 behaviour, so even flushing database files to disk will not have
103 the desired effect.
104 fd_table_size
106 is the maximum number of connections (filedescriptors) that can be
107 open for afpd client processes in cnid_dbd. Default: 512. If this
108 number is exceeded, one of the existing connections is closed and
109 reused. The affected afpd process will transparently reconnect
110 later, which causes slight overhead. On the other hand, setting
111 this parameter too high could affect performance in cnid_dbd since
112 all descriptors have to be checked in a select() system call, or
113 worse, you might exceed the per process limit of open file
114 descriptors on your system. It is safe to set the value to 1 on
115 volumes where only one afpd client process is expected to run, e.g.
116 home directories.
117 idle_timeout
119 is the number of seconds of inactivity before an idle cnid_dbd
120 exits. Default: 600. Set this to 0 to disable the timeout.
121
123 In order to update between Netatalk releases using different BerkeleyDB
124 library versions, follow this steps:
125 · Stop the to be upgraded old version of Netatalk
127 · Using the old BerkeleyDB utilities run db_recover -h <path to
129 .AppleDB>
130 · Using the new BerkeleyDB utilities run db_upgrade -v -h <path to
132 .AppleDB> -f cnid2.db
133 · Again using the new BerkeleyDB utilities run db_checkpoint -1 -h
135 <path to .AppleDB>
136 · Start the the new version of Netatalk
138 Note that the first version to appear after Netatalk 2.1 ie Netatalk
140 2.1.1, will support BerkeleyDB updates on the fly without manual
141 intervention. In other words Netatalk 2.1 does contain code to prepare
142 the BerkeleyDB database for upgrades and to upgrade it in case it has
143 been prepared before. That means it can´t upgrade a 2.0.x version
144 because that one didn´t prepare the database.
145
147 cnid_metad(8), afpd(8), dbd(1)
148Netatalk 2.1 21 Mar 2009 CNID_DBD(8)