• Home
  • History
  • Annotate
  • only in this directory
NameDateSize

..16-Jun-201411

.deps/H16-Jun-201421

cmd_dbd.cH A D19-Dec-201115.3 KiB

cmd_dbd.hH A D19-Dec-20111.1 KiB

cmd_dbd_scanvol.cH A D19-Dec-201140.8 KiB

cnid_metad.cH A D19-Dec-201117.2 KiB

comm.cH A D19-Dec-20117.1 KiB

comm.hH A D19-Dec-2011511

db_param.cH A D19-Dec-20116.1 KiB

db_param.hH A D19-Dec-2011995

dbd.hH A D19-Dec-20111.2 KiB

dbd_add.cH A D19-Dec-20116 KiB

dbd_dbcheck.cH A D19-Dec-20111.3 KiB

dbd_delete.cH A D19-Dec-20113.1 KiB

dbd_get.cH A D19-Dec-20111.7 KiB

dbd_getstamp.cH A D19-Dec-20111.3 KiB

dbd_lookup.cH A D19-Dec-201110.9 KiB

dbd_rebuild_add.cH A D19-Dec-20112 KiB

dbd_resolve.cH A D19-Dec-20111.5 KiB

dbd_search.cH A D19-Dec-20111.3 KiB

dbd_update.cH A D19-Dec-20111.8 KiB

dbif.cH A D19-Dec-201141.8 KiB

dbif.hH A D19-Dec-20113.6 KiB

main.cH A D19-Dec-201111.2 KiB

MakefileH A D26-Dec-201120.6 KiB

Makefile.amH A D19-Dec-20111,004

Makefile.inH A D19-Dec-201121.3 KiB

pack.cH A D19-Dec-20113.8 KiB

pack.hH A D19-Dec-20111 KiB

READMEH A D19-Dec-20114 KiB

usockfd.cH A D19-Dec-20114.6 KiB

usockfd.hH A D19-Dec-20111,017

README

1This is a implementation of the netatalk CNID database support that
2attempts to put all functionality into a separate daemon called cnid_dbd.
3There is one such daemon per netatalk volume. The underlying database
4structure is based on Berkeley DB and the database format is the same
5as in the cdb CNID backend, so this can be used as a drop-in replacement.
6
7Advantages: 
8
9- No locking issues or leftover locks due to crashed afpd daemons any
10  more. Since there is only one thread of control accessing the
11  database, no locking is needed and changes appear atomic.
12
13- Berkeley DB transactions are difficult to get right with several
14  processes attempting to access the CNID database simultanously. This 
15  is much easier with a single process and the database can be made nearly 
16  crashproof this way (at a performance cost).
17
18- No problems with user permissions and access to underlying database
19  files, the cnid_dbd process runs under a configurable user
20  ID that normally also owns the underlying database
21  and can be contacted by whatever afpd daemon accesses a volume.
22
23- If an afpd process crashes, the CNID database is unaffected. If the
24  process was making changes to the database at the time of the crash,
25  those changes will be rolled back entirely (transactions).
26  If the process was not using the database at the time of the crash,
27  no corrective action is necessary. In any case, database consistency
28  is assured.
29
30Disadvantages:
31
32- Performance in an environment of processes sharing the database
33  (files) is potentially better for two reasons:
34
35  i)  IPC overhead.
36  ii) r/o access to database pages is possible by more than one
37      process at once, r/w access is possible for nonoverlapping regions.
38
39  The current implementation of cnid_dbd uses unix domain sockets as
40  the IPC mechanism. While this is not the fastest possible method, it
41  is very portable and the cnid_dbd IPC mechanisms can be extended to
42  use faster IPC (like mmap) on architectures where it is
43  supported. As a ballpark figure, 20000 requests/replies to the cnid_dbd
44  daemon take about 0.6 seconds on a Pentium III 733 Mhz running Linux
45  Kernel 2.4.18 using unix domain sockets. The requests are "empty"
46  (no database lookups/changes), so this is just the IPC
47  overhead.
48  
49  I have not measured the effects of the advantages of simultanous
50  database access.
51
52
53Installation and configuration
54
55cnid_dbd is part of the CNID framework whereby various CNID backends
56can be selected for afpd as a runtime option for a given volume.
57By default only last and dbd backend are built and dbd is the default.
58
59There are two executeables that will be built in etc/cnid_dbd and
60installed into the systems binaries directories of netatalk
61(e.g. /usr/local/netatalk/sbin or whatever you specify with --sbindir
62to configure): cnid_metad and cnid_dbd. cnid_metad should run all the
63time with root permissions. It will be notified when an instance of
64afpd starts up and will in turn make sure that a cnid_dbd daemon is
65started for the volume that afpd wishes to access. The daemon runs as
66long as necessary (see the idle_timeout option below) and services any
67other instances of afpd that access the volume. You can safely kill it
68with SIGTERM, it will be restarted automatically by cnid_metad as soon
69as the volume is accessed again.
70
71cnid_dbd changes to the Berkeley DB directory on startup and sets
72effective UID and GID to owner and group of that directory. Database and
73supporting files should therefore be writeable by that user/group.
74
75Current shortcomings:
76
77- The parameter file parsing of db_param is very simpleminded. It is
78easy to cause buffer overruns and the like.
79Also, there is no support for blanks (or weird characters) in
80filenames for the usock_file parameter.
81
82- There is no protection against a malicious user connecting to the
83cnid_dbd socket and changing the database.
84
85Please feel free to grep the source in etc/cnid_dbd and the file
86libatalk/cnid/dbd/cnid_dbd.c for the string TODO, which indicates
87comments that adress other, less important points.
88
89
90The Netatalk Team
91