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. CNIDs  are
       a component of Macintosh	based file systems with	semantics that map not
       easily  onto  Unix file systems.	This makes separate storage in a data-
       base necessary. cnid_dbd	is part	of the CNID backend framework of  afpd
       and implements the dbd backend.

       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
       Note  that the first version to appear after Netatalk 2.1 i.e. Netatalk
       2.1.1, will support Berkeley DB updates on the fly without  manual  in-
       tervention.  In	other  words Netatalk 2.1 does contain code to prepare
       the Berkeley DB database	for upgrades and to upgrade it in case it  has
       been  prepared  before. That means it can't upgrade a 2.0.x version be-
       cause that one didn't prepare the database.

       In order	to update between  older  Netatalk  releases  using  different
       Berkeley	DB library versions, follow this 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
	 .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

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

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

Netatalk 4.2.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+14.3.quarterly>

home | help