etc/cnid_dbd/README

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