Subject: Database of DID's (start of a solution?)

From: "Tom Watson" <[email-masked]>
Date: Thu, 07 Dec 2000 19:37:44 -0800

On Thu, 7 Dec 2000 14:37:45 -0500 (EST), [email-masked] wrote:
> > so.  The problem is the same as yours, the minor device number.
> > mine are 1,17,33 and 49.  So here's a question,
> > in my case, as all the major numbers are the
> > same (8), would itbe evil to hack this hash function to
> > give the major
> > bits to the minor?
> 
> Evil?  Only malicious software is evil in my book.  The change you
> describe would be a short term fix for your issue, but certainly not a
> long term one for everyone.

How about a database for JUST the major/minor parts of the the
identifier.  If this is limited to 256 entries (8 bits of index), it
would allow quite a bit of mounted volumes.  Then there would be no
"evil hash".  OK, so it takes a table in memory that has the accumulated
major/minor numbers, and it needs to be written out, but after it is
started, it should be pretty much self sufficient.  Since the DID is
a total of 4 bytes, this allows 16megs of unique inodes for a volume.
In my book, this sounds pretty adequate.

<<<deletia>>>

> 
> The reality is that we need a persistent DID database for netatalk.
> Unfortunately, it seems no one has the time to commit to such a
> project.
> 
> Jon
> 
-- 
Tom Watson         Generic short signature
[email-masked]     (I'm at home now)

---

From: "Jonathan Newman" <[email-masked]>
Date: Thu, 7 Dec 2000 20:59:03 -0800

> In my book, this sounds pretty adequate.

The only reason for using the dev/inode pair was that it is a
semi-permanent way to enumerate the directories.  A database wouldn't
have to depend on those, and would certainly be more portable if it
didn't -- if you move your contents to a new drive/volume, your
database shouldn't become invalid.  I think something more complicated
that just the device number is needed.  The lastdid solution would
work quite well if it only persisted between runs of afpd.

Jon