etc/cnid_dbd/README

   1 This is a reimplementation of the netatalk CNID database support that
   2 attempts to put all current functionality into a separate daemon
   3 called cnid_dbd. There is one such daemon per netatalk volume. The
   4 underlying database structure is still based on Berkeley DB and the
   5 database format is the same as in the current CNID implementation, so
   6 this can be used as a drop-in replacement.
   7
   8 Advantages:
   9
  10 - No locking issues or leftover locks due to crashed afpd daemons any
  11   more. Since there is only one thread of control accessing the
  12   database, no locking is needed and changes appear atomic.
  13
  14 - Berkeley DB transactions are difficult to get right with several
  15   processes attempting to access the CNID database simultanously. This
  16   is much easier with a single process and the database can be made nearly
  17   crashproof this way (at a performance cost).
  18
  19 - No problems with user permissions and access to underlying database
  20   files, the cnid_dbd process runs under a configurable user
  21   ID that normally also owns the underlying database
  22   and can be contacted by whatever afpd daemon accesses a volume.
  23
  24 - If an afpd process crashes, the CNID database is unaffected. If the
  25   process was making changes to the database at the time of the crash,
  26   those changes will either be completed (no transactions) or rolled
  27   back entirely (transactions). If the process was not using the
  28   database at the time of the crash, no corrective action is
  29   necessary. In both cases, database consistency is assured.
  30
  31 Disadvantages:
  32
  33 - Performance in an environment of processes sharing the database
  34   (files) is potentially better for two reasons:
  35
  36   i)  IPC overhead.
  37   ii) r/o access to database pages is possible by more than one
  38       process at once, r/w access is possible for nonoverlapping regions.
  39
  40   The current implementation of cnid_dbd uses unix domain sockets as
  41   the IPC mechanism. While this is not the fastest possible method, it
  42   is very portable and the cnid_dbd IPC mechanisms can be extended to
  43   use faster IPC (like mmap) on architectures where it is
  44   supported. As a ballpark figure, 20000 requests/replies to the cnid_dbd
  45   daemon take about 0.6 seconds on a Pentium III 733 Mhz running Linux
  46   Kernel 2.4.18 using unix domain sockets. The requests are "empty"
  47   (no database lookups/changes), so this is just the IPC
  48   overhead.
  49
  50   I have not measured the effects of the advantages of simultanous
  51   database access.
  52
  53
  54 Installation and configuration
  55
  56 cnid_dbd is now part of a new CNID framework whereby various CNID
  57 backends (including the ones present so far) can be selected for afpd
  58 as a runtime option for a given volume. The default is to compile
  59 support for all these backends, so normally there is no need to
  60 specify other options to configure. The only exception is
  61 transactional support, which is enabled as the default. If you want to
  62 turn it off use --with-cnid-dbd-txn=no.
  63
  64 In order to turn on cnid_dbd backend support for a given volume, set
  65 the option -cnidscheme:dbd in your AppleVolumes.default file or
  66 equivalent. The default for this parameter is -cnidscheme:cdb.
  67
  68 There are two executeables that will be built in etc/cnid_dbd and
  69 installed into the systems binaries directories of netatalk
  70 (e.g. /usr/local/netatalk/sbin or whatever you specify with --sbindir
  71 to configure): cnid_metad and cnid_dbd. cnid_metad should run all the
  72 time with root permissions. It will be notified when an instance of
  73 afpd starts up and will in turn make sure that a cnid_dbd daemon is
  74 started for the volume that afpd wishes to access. The daemon runs as
  75 long as necessary (see the idle_timeout option below) and services any
  76 other instances of afpd that access the volume. You can safely kill it
  77 with SIGTERM, it will be restarted automatically by cnid_metad as soon
  78 as the volume is accessed again.
  79
  80 cnid_metad needs one command line argument, the name of the cnid_dbd
  81 executeable. You can either specify "cnid_dbd" if it is in the path
  82 for cnid_metad or otherwise use the fully qualified pathname to
  83 cnid_dbd, e.g. /usr/local/netatalk/sbin/cnid_dbd. cnid_metad also uses
  84 a unix domain socket to receive requests from afpd. The pathname for
  85 that socket is /tmp/cnid_meta. It should not be deleted while
  86 cnid_metad runs.
  87
  88
  89 cnid_dbd changes to the Berkeley DB directory on startup and sets
  90 effective UID and GID to owner and group of that directory. Database and
  91 supporting files should therefore be writeable by that user/group. cnid_dbd
  92 reads configuration information from the file db_param in the database
  93 directory on startup. If the file does not exist, suitable default
  94 values for all parameters are used. The format for a single parameter
  95 is the parameter name, followed by one or more spaces, followed by the
  96 parameter value, followed by a newline. The following parameters are
  97 currently recognized:
  98
  99 Name               Default
 100
 101 backlog            20
 102 cachesize          1024
 103 nosync             0
 104 flush_frequency    100
 105 flush_interval     30
 106 usock_file         <databasedirectory>/usock
 107 fd_table_size      16
 108 idle_timeout       600
 109
 110
 111 "backlog" specifies the maximum number of connection requests that can
 112 be pending on the unix domain socket cnid_dbd uses. listen(2) has more
 113 information about this value on your system.
 114
 115 "cachesize" determines the size of the Berkeley DB cache in
 116 kilobytes. Each cnid_dbd process grabs that much memory on top of its
 117 normal memory footprint. It can be used to tune database
 118 performance. The db_stat utility with the "-m" option that comes with
 119 Berkely DB can help you determine wether you need to change this
 120 value. The default is pretty conservative so that a large percentage
 121 of requests should be satisfied from the cache directly. If memory is
 122 not a bottleneck on your system you might want to leave it at that
 123 value. The Berkeley DB Tutorial and Reference Guide has a section
 124 "Selecting a cache size" that gives more detailed information.
 125
 126 "nosync" is only valid if transactional support is enabled. If it is
 127 set to 1, transactional changes to the database are not synchronously
 128 written to disk when the transaction completes. This will increase
 129 performance considerably at the risk of recent changes getting
 130 lost in case of a crash. The database will still be consistent,
 131 though. See "Transaction throughput" in the Berkeley DB Tutorial for
 132 more information.
 133
 134 "flush_frequency" and "flush_interval" control how often changes to
 135 the database are written to the underlying database files if no
 136 transactions are used or how often the transaction system is
 137 checkpointed for transactions. Both of these operations are
 138 performed if either i) more than flush_frequency requests have been
 139 received or ii) more than flush_interval seconds have elapsed since
 140 the last save/checkpoint. If you use transactions with nosync set to
 141 zero these parameters only influence how long recovery takes after
 142 a crash, there should never be any lost data. If nosync is 1, changes
 143 might be lost, but only since the last checkpoint. Be careful to check
 144 your harddisk configuration for on disk cache settings. Many IDE disks
 145 just cache writes as the default behaviour, so even flushing database
 146 files to disk will not have the desired effect.
 147
 148 "usock_file" gives the pathname of the unix domain socket file that
 149 that instance of cnid_dbd will use for receiving requests. You might
 150 have to use another value if the total length of the default pathname
 151 exceeds the limits for unix domain socket files on your system,
 152 usually this is something like 100 bytes.
 153
 154 "fd_table_size" is the maximum number of connections (filedescriptors)
 155 that can be open for afpd client processes in cnid_dbd. If this number
 156 is exceeded, one of the existing connections is closed and reused. The
 157 affected afpd process will transparently reconnect later, which causes
 158 slight overhead. On the other hand, setting this parameter too high
 159 could affect performance in cnid_dbd since all descriptors have to be
 160 checked in a select() system call, or worse, you might exceed the per
 161 process limit of open file descriptors on your system. It is safe to
 162 set the value to 1 on volumes where only one afpd client process
 163 is expected to run, e.g. home directories.
 164
 165 "idle_timeout" is the number of seconds of inactivity before an idle
 166 cnid_dbd exits. Set this to 0 to disable the timeout.
 167
 168 Current shortcomings:
 169
 170 - The implementation for cnid_dbd doubles code from libatalk/cnid,
 171 making it more difficult to keep changes to the library interface and
 172 the semantics of database requests in sync.  If cnid_dbd takes over
 173 the world, this problem will eventually disappear, otherwise it should
 174 be possible to merge things again, if transactional support is
 175 eliminated from libatalk/cnid. I do not think it can work relieably in
 176 the current form anyway.
 177
 178 - It would be more flexible to have transaction support as a run time
 179 option as well.
 180
 181 - mmap for IPC would be nice as an alternative.
 182
 183 - The parameter file parsing of db_param is very simpleminded. It is
 184 easy to cause buffer overruns and the like.
 185 Also, there is no support for blanks (or weird characters) in
 186 filenames for the usock_file parameter.
 187
 188 - There is no protection against a malicious user connecting to the
 189 cnid_dbd socket and changing the database. I will adress this problem
 190 soon.
 191
 192 Please feel free to grep the source in etc/cnid_dbd and the file
 193 libatalk/cnid/dbd/cnid_dbd.c for the string TODO, which indicates
 194 comments that adress other, less important points.
 195
 196
 197 Joerg Lenneis, lenneis@wu-wien.ac.at