Subject: Re: [netatalk-admins] DIDs - an idea -or- I didn't read the AFP specs completely yet

From: "Donald L. Nash" <[email-masked]>
Date: Thu, 16 Apr 1998 08:54:31 -0500

--On Thu, Apr 16, 1998 9:21 AM -0400 "William LeFebvre" <[email-masked]>
wrote: 

>> what about the action on xntpd and the
>> adjustments it makes to keep correct time.
> 
> xntp does its thing by slewing the clock (not explicitly setting it).

Xntpd will step-adjust the clock if it is too far off for a slewing
adjustment to be feasible.  The exact threshold for this is a configurable
parameter.  It will repeatedly step-adjust the clock if the clock frequency
is too far out of spec. to keep it disciplined via slewing adjustments. 
Many x86 Unix boxes I've worked with have this problem, but it can be fixed
by tinkering with the Unix kernel to account for the off-frequency clock.

-- 
Donald L. Nash, <[email-masked]>, PGP Key ID: 0x689DA021
The University of Texas System Office of Telecommunication Services
PGP Key Fingerprint: D6D2 CBEE 8F56 60B2  736C 031A A1E0 AF3D

---

From: "Donald L. Nash" <[email-masked]>
Date: Thu, 16 Apr 1998 16:48:32 -0500

--On Thu, Apr 16, 1998 8:22 PM +0100 "Duncan Sinclair"
<[email-masked]> 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.