Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
CNID_DBD(8)		 Netatalk AFP Fileserver Manual 	     CNID_DBD(8)

Name
     cnid_dbd -- CNID database access daemon

Synopsis
     cnid_dbd

     cnid_dbd [-v | -V]

Description
     cnid_dbd  provides  an  interface for storage and retrieval of catalog node
     IDs (CNIDs) and related information to the afpd daemon when using	the  dbd
     (Database Daemon) CNID backend.

     CNIDs  are  a component of Classic Mac OS based file systems with semantics
     that does not map easily onto Unix file systems.  This makes separate stor-
     age in a database necessary.

     cnid_dbd is never started via the command line or	system	startup  scripts
     but  only	by  the cnid_metad daemon. There is one instance of cnid_dbd per
     netatalk volume.

     cnid_dbd uses the Berkeley DB database  library  and  uses  transactionally
     protected	updates. The dbd backend with transactions will avoid corruption
     of the CNID database even if the system crashes unexpectedly.

     cnid_dbd inherits the effective  userid  and  groupid  from  cnid_metad  on
     startup,  which  is  normally caused by afpd serving a netatalk volume to a
     client. It changes to the Berkeley DB database home directory dbdir that is
     associated with the volume. If the userid inherited from  cnid_metad  is  0
     (root),  cnid_dbd	will change userid and groupid to the owner and group of
     the database home directory. Otherwise, it will continue to use the  inher-
     ited  values.  cnid_dbd  will  then  attempt to open the database and start
     serving requests using filedescriptor clntfd. Subsequent instances of  afpd
     that  want to access the same volume are redirected to the running cnid_dbd
     process by cnid_metad via the filedescriptor ctrlfd.

     cnid_dbd can be configured to run forever or to exit after a period of  in-
     activity. If cnid_dbd receives a TERM or an INT signal it will exit cleanly
     after flushing dirty database buffers to disk and closing Berkeley DB data-
     base  environments.  It  is safe to terminate cnid_dbd this way, it will be
     restarted when necessary. Other signals are not handled and will  cause  an
     immediate exit, possibly leaving the CNID database in an inconsistent state
     (no transactions) or losing recent updates during recovery (transactions).

     The  Berkeley  DB database subsystem will create files named log.xxxxxxxxxx
     in the database home directory dbdir, where xxxxxxxxxx is	a  monotonically
     increasing integer. These files contain the transactional database changes.
     They  will  be  removed  regularly, unless the logfile_autoremove option is
     specified in the db_param configuration file (see below) with a value of  0
     (default 1).

Options
     -v | -V

	    Show version and exit.

Configuration
     cnid_dbd  reads  configuration  information  from	the file db_param in the
     database directory dbdir on startup. If the file does not exist or a  para-
     meter  is	not  listed,  suitable default values 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 para-
     meters are currently recognized:

     logfile_autoremove

	    If	 set   to   0,	 unused   Berkeley   DB  transactional	logfiles
	    (log.xxxxxxxxxx in the database home directory) are not  removed  on
	    startup of cnid_dbd and on a regular basis. Default: 1.

     cachesize

	    Determines the size of the Berkeley DB cache in kilobytes.	Default:
	    8192.  Each  cnid_dbd  process  grabs that much memory on top of its
	    normal memory footprint. It can be used  to  tune  database  perfor-
	    mance. The db_stat utility with the -m option that comes with Berke-
	    ley DB can help you determine whether you need to change this value.
	    The default is pretty conservative so that a large percentage of re-
	    quests 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; flush_interval

	    flush_frequency  (Default:	1000) and flush_interval (Default: 1800)
	    control how often changes to the database are checkpointed. Both  of
	    these  operations  are  performed  if either i) more than flush_fre-
	    quency requests have been received or ii) more  than  flush_interval
	    seconds  have  elapsed since the last save/checkpoint. Be careful to
	    check your hard disk configuration for on disk cache settings.  Many
	    IDE disks just cache writes as the default behaviour, so even flush-
	    ing database files to disk will not have the desired effect.

     fd_table_size

	    is	the  maximum number of connections (filedescriptors) that can be
	    open for afpd client processes in cnid_dbd. Default:  512.	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 ex-
	    its.  Default: 600. Set this to 0 to disable the timeout.

Updating
     Starting with Netatalk 2.1.1, automatic Berkeley DB updates are  supported,
     as long as Netatalk 2.1.0 or later was used to create the database.

     In order to update between older Netatalk releases using different Berkeley
     DB library versions, follow these steps:

     * Stop the to be upgraded old version of Netatalk

     * Using the old Berkeley DB utilities run db_recover -h path/to/.AppleDB

     * Using the new Berkeley DB utilities run db_upgrade -v -h path/to/.AppleDB
       -f cnid2.db

     * Again  using  the  new  Berkeley  DB  utilities	run  db_checkpoint -1 -h
       path/to/.AppleDB

     * Start the the new version of Netatalk

Wire Protocol
     cnid_dbd speaks a private TCP/IP protocol	with  afpd  and  nad  on  local-
     host:4700	 (configurable	per-volume  via  cnid  server  /  cnid	port  in
     afp.conf(5)). The protocol is internal and may change between releases. Af-
     ter a netatalk upgrade, restart the netatalk service.

See Also
     cnid_metad(8), afpd(8), dbd(1)

Author
     Contributors to the Netatalk Project (https://netatalk.io/contributors)

Netatalk 4.5.0							     CNID_DBD(8)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=cnid_dbd&sektion=8&manpath=FreeBSD+Ports+15.1.quarterly>

home | help