Subject: Re: [netatalk-admins] DIDs - an idea -or- I didn't read the AFP specs completely yet
From: Andras Kadinger (bandit@freeside.elte.hu)
Date: Thu Apr 16 1998 - 19:44:16 EDT
Duncan Sinclair wrote:
>
> "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.
Not to open a debate, but I don't see what You gain by hashing, and not
just bumping a counter. You have to keep the database anyway.
> 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 assume, You discover a moved directory by not finding it at the right
place. If you try to locate that directory purely by inode/dev number,
You lose if the given inode was reused; not to mention, that - AFAIK -
there is no simple way to get a pathname from an inode/dev number (I
might be wrong here), so You would have to search the tree for the
directory, which is very close to searching for the unambiguous [in
contents I mean] .DID file in the directory. The only case I see You
could lose here is when some uneducated user removes the .DID file, in
which case all Your aliases pointing to this dir would break; but You
still would not resolve to a wrong one, as with inode reuse You could
based on inode/dev.
Or did You think about performance issues? Clear me up, please!
Sincerely,
Andras Kadinger
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:27 EST