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

FreeBSD Manual Pages

  
 
  

home | help
CNID_DBD(8)			    3.1.12			   CNID_DBD(8)

NAME
       cnid_dbd	- implement access to CNID databases through a dedicated
       daemon process

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
       database	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
       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 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
       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
       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. Default:
	   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
	   Berkley 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 checkpointed. 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.

       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
	   exits. Default: 600.	Set this to 0 to disable the timeout.

UPDATING
       Note that the first version to appear after Netatalk 2.1	ie Netatalk
       2.1.1, will support BerkeleyDB updates on the fly without manual
       intervention. In	other words Netatalk 2.1 does contain code to prepare
       the BerkeleyDB 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
       because that one	didn't prepare the database.

       In order	to update between older	Netatalk releases using	different
       BerkeleyDB library versions, follow this	steps:

       o   Stop	the to be upgraded old version of Netatalk

       o   Using the old BerkeleyDB utilities run db_recover -h	<path to
	   .AppleDB>

       o   Using the new BerkeleyDB utilities run db_upgrade -v	-h <path to
	   .AppleDB> -f	cnid2.db

       o   Again using the new BerkeleyDB utilities run	db_checkpoint -1 -h
	   <path to .AppleDB>

       o   Start the the new version of	Netatalk

SEE ALSO
       cnid_metad(8), afpd(8), dbd(1)

3.1.12				  10 Nov 2015			   CNID_DBD(8)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | CONFIGURATION | UPDATING | SEE ALSO

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

home | help