Subject: Re: [netatalk-admins] DIDs - an idea -or- I didn't read the AFP specs completely yet
From: Donald L. Nash (D.Nash@utexas.edu)
Date: Thu Apr 16 1998 - 17:48:32 EDT
--On Thu, Apr 16, 1998 8:22 PM +0100 "Duncan Sinclair"
<sinclair@dis.strath.ac.uk> 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
>
> I would have thought this is still the key to the solution.
I suppose it could have been made to work (I was hoping for a quick hack,
and that fell through when I realized that inode numbers are 24 bits long
instead of 16), but it still has a fundamental problem which I wasn't even
trying to address: even this doesn't create truly unique DIDs. You can
create a directory, derive its DID from its inode and device numbers, delete
the directory, and then create a new one which happens to get the same inode
number and therefore the same DID. Granted, it would have been better than
what we have now, but it would still have been less than perfect.
Synthesizing and tracking DIDs externally via .DID files and the .DIDdb
database still sounds like the best approach, hack though it may be.
> The database is keyed by the DID or
> the i-node/device combination and contains the (complete) path.
Regardless of how you generate your DIDs, they are what you'd use as the
database key since the whole point of the database is to map DIDs to path
names. If you keyed by inode/device (a moot point given the above
paragraph), you'd have to find some way to calculate that from the DID,
which might be impossible depending on the hash function used to generate
the DID in the first place.
> 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.
IMO, it is scandalous that Unix doesn't include a basic database package
that does record-level locking (having a good amount of VMS in my
background, I long for this sort of thing in Unix). Even Berkeley DB
doesn't do this, at least not the version I've seen. Even though having an
external process is a performance hit, not to mention being a disgusting
hack, I can't think of any other way to do it reliably in the absense of
record locking.
-- Donald L. Nash, <D.Nash@utexas.edu>, PGP Key ID: 0x689DA021 The University of Texas System Office of Telecommunication Services PGP Key Fingerprint: D6D2 CBEE 8F56 60B2 736C 031A A1E0 AF3D
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:26 EST