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	seman-
       tics that does not map easily onto Unix file systems.  This makes sepa-
       rate storage 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 corrup-
       tion 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 con-
       tinue  to  use the inherited 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
       inactivity. 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 database 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 transac-
       tional 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
       parameter 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 parameters 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.  De-
	      fault: 8192. 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 Berkeley DB can help	you  determine	whether	 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;	flush_interval

	      flush_frequency  (Default:  1000)	 and  flush_interval (Default:
	      1800) control how	often  changes	to  the	 database  are	check-
	      pointed.	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	hard  disk  configura-
	      tion  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.

       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  se-
	      lect()  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.  Default: 600. Set	this to	0 to disable the timeout.

Updating
       Starting	with Netatalk 2.1.1, automatic Berkeley	DB  updates  are  sup-
       ported, as long as Netatalk 2.1.0 or later was used to create the data-
       base.

       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/.Ap-
	 pleDB

        Using the new Berkeley	DB utilities run db_upgrade -v -h path/to/.Ap-
	 pleDB -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

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

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

Netatalk 4.3.2							   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.0>

home | help