1CNID_DBD(8)                         3.1.12                         CNID_DBD(8)
2
3
4

NAME

6       cnid_dbd - implement access to CNID databases through a dedicated
7       daemon process
8

SYNOPSIS

10       cnid_dbd
11
12       cnid_dbd -v | -V
13

DESCRIPTION

15       cnid_dbd provides an interface for storage and retrieval of catalog
16       node IDs (CNIDs) and related information to the afpd daemon. CNIDs are
17       a component of Macintosh based file systems with semantics that map not
18       easily onto Unix file systems. This makes separate storage in a
19       database necessary.  cnid_dbd is part of the CNID backend framework of
20       afpd and implements the dbd backend.
21
22       cnid_dbd is never started via the command line or system startup
23       scripts but only by the cnid_metad daemon. There is one instance of
24       cnid_dbd per netatalk volume.
25
26       cnid_dbd uses the Berkeley DB database library and uses transactionally
27       protected updates. The dbd backend with transactions will avoid
28       corruption of the CNID database even if the system crashes
29       unexpectedly.
30
31       cnid_dbd inherits the effective userid and groupid from cnid_metad on
32       startup, which is normally caused by afpd serving a netatalk volume to
33       a client. It changes to the Berkeley DB database home directory dbdir
34       that is associated with the volume. If the userid inherited from
35       cnid_metad is 0 (root), cnid_dbd will change userid and groupid to the
36       owner and group of the database home directory. Otherwise, it will
37       continue to use the inherited values.  cnid_dbd will then attempt to
38       open the database and start serving requests using filedescriptor
39       clntfd. Subsequent instances of afpd that want to access the same
40       volume are redirected to the running cnid_dbd process by cnid_metad via
41       the filedescriptor ctrlfd.
42
43       cnid_dbd can be configured to run forever or to exit after a period of
44       inactivity. If cnid_dbd receives a TERM or an INT signal it will exit
45       cleanly after flushing dirty database buffers to disk and closing
46       Berkeley DB database environments. It is safe to terminate cnid_dbd
47       this way, it will be restarted when necessary. Other signals are not
48       handled and will cause an immediate exit, possibly leaving the CNID
49       database in an inconsistent state (no transactions) or losing recent
50       updates during recovery (transactions).
51
52       The Berkeley DB database subsystem will create files named
53       log.xxxxxxxxxx in the database home directory dbdir, where xxxxxxxxxx
54       is a monotonically increasing integer. These files contain the
55       transactional database changes. They will be removed regularly, unless
56       the logfile_autoremove option is specified in the db_param
57       configuration file (see below) with a value of 0 (default 1).
58

OPTIONS

60       -v, -V
61           Show version and exit.
62

CONFIGURATION

64       cnid_dbd reads configuration information from the file db_param in the
65       database directory dbdir on startup. If the file does not exist or a
66       parameter is not listed, suitable default values are used. The format
67       for a single parameter is the parameter name, followed by one or more
68       spaces, followed by the parameter value, followed by a newline. The
69       following parameters are currently recognized:
70
71       logfile_autoremove
72           If set to 0, unused Berkeley DB transactional logfiles
73           (log.xxxxxxxxxx in the database home directory) are not removed on
74           startup of cnid_dbd and on a regular basis. Default: 1.
75
76       cachesize
77           Determines the size of the Berkeley DB cache in kilobytes. Default:
78           8192. Each cnid_dbd process grabs that much memory on top of its
79           normal memory footprint. It can be used to tune database
80           performance. The db_stat utility with the -m option that comes with
81           Berkley DB can help you determine whether you need to change this
82           value. The default is pretty conservative so that a large
83           percentage of requests should be satisfied from the cache directly.
84           If memory is not a bottleneck on your system you might want to
85           leave it at that value. The Berkeley DB Tutorial and Reference
86           Guide has a section Selecting a cache size that gives more detailed
87           information.
88
89       flush_frequency, flush_interval
90           flush_frequency (Default: 1000) and flush_interval (Default: 1800)
91           control how often changes to the database are checkpointed. Both of
92           these operations are performed if either i) more than
93           flush_frequency requests have been received or ii) more than
94           flush_interval seconds have elapsed since the last save/checkpoint.
95           Be careful to check your harddisk configuration for on disk cache
96           settings. Many IDE disks just cache writes as the default
97           behaviour, so even flushing database files to disk will not have
98           the desired effect.
99
100       fd_table_size
101           is the maximum number of connections (filedescriptors) that can be
102           open for afpd client processes in cnid_dbd.  Default: 512. If this
103           number is exceeded, one of the existing connections is closed and
104           reused. The affected afpd process will transparently reconnect
105           later, which causes slight overhead. On the other hand, setting
106           this parameter too high could affect performance in cnid_dbd since
107           all descriptors have to be checked in a select() system call, or
108           worse, you might exceed the per process limit of open file
109           descriptors on your system. It is safe to set the value to 1 on
110           volumes where only one afpd client process is expected to run, e.g.
111           home directories.
112
113       idle_timeout
114           is the number of seconds of inactivity before an idle cnid_dbd
115           exits. Default: 600. Set this to 0 to disable the timeout.
116

UPDATING

118       Note that the first version to appear after Netatalk 2.1 ie Netatalk
119       2.1.1, will support BerkeleyDB updates on the fly without manual
120       intervention. In other words Netatalk 2.1 does contain code to prepare
121       the BerkeleyDB database for upgrades and to upgrade it in case it has
122       been prepared before. That means it can't upgrade a 2.0.x version
123       because that one didn't prepare the database.
124
125       In order to update between older Netatalk releases using different
126       BerkeleyDB library versions, follow this steps:
127
128       ·   Stop the to be upgraded old version of Netatalk
129
130       ·   Using the old BerkeleyDB utilities run db_recover -h <path to
131           .AppleDB>
132
133       ·   Using the new BerkeleyDB utilities run db_upgrade -v -h <path to
134           .AppleDB> -f cnid2.db
135
136       ·   Again using the new BerkeleyDB utilities run db_checkpoint -1 -h
137           <path to .AppleDB>
138
139       ·   Start the the new version of Netatalk
140

SEE ALSO

142       cnid_metad(8), afpd(8), dbd(1)
143
144
145
1463.1.12                            10 Nov 2015                      CNID_DBD(8)
Impressum