]> arthur.barton.de Git - netatalk.git/blobdiff - etc/cnid_dbd/README
Refine CNID salvatio strategies
[netatalk.git] / etc / cnid_dbd / README
index 7255a9e2745e53040f65bac8d637c92e8926ff08..cbd2f9f5a07b76ba4de429e0e34a45f685fe1ee7 100644 (file)
@@ -68,85 +68,12 @@ other instances of afpd that access the volume. You can safely kill it
 with SIGTERM, it will be restarted automatically by cnid_metad as soon
 as the volume is accessed again.
 
-cnid_metad needs one command line argument, the name of the cnid_dbd
-executeable. You can either specify "cnid_dbd" if it is in the path
-for cnid_metad or otherwise use the fully qualified pathname to
-cnid_dbd, e.g. /usr/local/netatalk/sbin/cnid_dbd. cnid_metad listens
-on TCP port 4700 by default for request from afpd processes.
-
 cnid_dbd changes to the Berkeley DB directory on startup and sets
 effective UID and GID to owner and group of that directory. Database and
-supporting files should therefore be writeable by that user/group. cnid_dbd
-reads configuration information from the file db_param in the database
-directory on startup. If the file does not exist, suitable default
-values for all parameters 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:
-
-Name               Default
-====               =======
-cachesize          8192
-flush_frequency    100
-flush_interval     1800
-usock_file         <databasedirectory>/usock
-fd_table_size      128
-idle_timeout       600
-
-"cachesize" determines the size of the Berkeley DB cache in
-kilobytes. Each cnid_dbd process grabs that much memory on top of its
-normal memory footprint. It can be used to tune database
-performance. The db_stat utility with the "-m" option that comes with
-Berkely DB can help you determine wether 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 Berkeley DB Tutorial and Reference Guide has a section
-"Selecting a cache size" that gives more detailed information.
-
-"flush_frequency" and "flush_interval" control how often changes to
-the database are written to the underlying database files if no
-transactions are used or how often the transaction system is
-checkpointed for transactions. Both of these operations are
-performed if either i) more than flush_frequency requests have been
-received or ii) more than flush_interval 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.
-
-"usock_file" gives the pathname of the unix domain socket file that
-that instance of cnid_dbd will use for receiving requests. You might
-have to use another value if the total length of the default pathname
-exceeds the limits for unix domain socket files on your system,
-usually this is something like 100 bytes.
-
-"fd_table_size" is the maximum number of connections (filedescriptors)
-that can be open for afpd client processes in cnid_dbd. If this number
-is exceeded, one of the existing connections is closed and reused. The
-affected afpd process will transparently reconnect later, which causes
-slight overhead. On the other hand, setting this parameter too high
-could affect performance in cnid_dbd since all descriptors have to be
-checked in a select() 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 afpd client process
-is expected to run, e.g. home directories.
-
-"idle_timeout" is the number of seconds of inactivity before an idle
-cnid_dbd exits. Set this to 0 to disable the timeout.
+supporting files should therefore be writeable by that user/group.
 
 Current shortcomings:
 
-- The implementation for cnid_dbd doubles code from libatalk/cnid,
-making it more difficult to keep changes to the library interface and
-the semantics of database requests in sync.  If cnid_dbd takes over
-the world, this problem will eventually disappear, otherwise it should
-be possible to merge things again, if transactional support is
-eliminated from libatalk/cnid. I do not think it can work relieably in
-the current form anyway.
-
-- mmap for IPC would be nice as an alternative.
-
 - The parameter file parsing of db_param is very simpleminded. It is
 easy to cause buffer overruns and the like.
 Also, there is no support for blanks (or weird characters) in