Subject: Re: [netatalk-admins] DIDs - an idea -or- I didn't read the AFP specs completely yet
From: Duncan Sinclair (sinclair@dis.strath.ac.uk)
Date: Thu Apr 16 1998 - 15:22:41 EDT
"Donald L. Nash" writes:
>... DIDs are only 32
>bits long. I looked into using inode numbers combined with major and minor
>device numbers to create an inode-based DID that worked for volumes which
>span filesystems, but had to give up on it because inode numbers are 24 bits
>long and major and minor device numbers are each 8 bits long. I couldn't
>figure out a way to cram 40 bits into 32 without the possibility of
>collision. :-)
I would have thought this is still the key to the solution. As a
database lookup has to be implemented anyway, you just use a hash
function, and hash the 40 bits down to 32. When you get a collision,
use a secondary hash function.
I guess this sort of thing can be done by berkeley db or gdbm. (I'd
prefer berkeley db myself.) Or you can roll your own hash table
pretty easily.
This gives you everything you need. The database is keyed by the DID or
the i-node/device combination and contains the (complete) path. Keeping
the database consistant should be an easy task. E.g. when a directory is
moved you still know its inode/dev number, so you can reset the path.
I would still recommend a separate process for the management of this
database, but I'm sure the concurrent access problem could be solved
some other way.
I guess all the same applies to file numbers.
Hope this inspires someone...
Duncan Sinclair.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:26 EST