Subject: Re: [netatalk-admins] current netatalk plans
From: bsmith@h-e.com
Date: Fri Mar 20 1998 - 22:18:41 EST
>> Do you think this will work if afpd volumes are set up so they never cross
Unix
>> filesystems? That would guarantee the directory inode numbers are unique
within
>> a volume. I don't have a problem with restricting volumes this way, I
already
>> have dedicated filesystems for the afpd volumes. Obviously this would be a
>> site-specific "hack" and not a general solution, but it seems like it should
>> work for me.
>
>Might there be some way to put a major:minor or other filesystem
>identifier combined with the inode number in that field? This should be
>reasonably stable on a given machine even between afpd sessions.
I thought of that too, however the directory IDs (DID) and file IDs (FNUM) have
to co-exist so that DID < FNUM in all cases on a given volume. The FNUMs are
already being computed as the file inode number with the device number shifted
into the high bits to guarantee they are > DIDs, which are assigned sequentially
starting with 3 and so are always relatively small. The only way to use inode
numbers for DIDs without also changing the way FNUMs are computed is to make
sure the DIDs have the appropriate high bits zeroed so they are always smaller
than FNUMs
Actually, even with this idea the FNUM computation has to change slightly.
Currently only the lower 16 bits of the inode number are used, with the device
number shifted into the upper 16 bits. Even on relatively small filesystems
inode numbers can be > 65535, so to make sure DIDs stay unique, more bits of the
inode number have to be preserved in the FNUMs and DIDs. How much depends on
the maximum possible inode number, which depends on the filesystem size, so a
particular number of bits is not going to work in all cases.
There may be some other scheme for deriving IDs from device/inode numbers with
the necessary properties of DID < FNUM and DID uniqueness even across
filesystems, but I think it would be really tough to come up with something that
works in every conceivable situation. Wes is correct that the "right" solution
is to generate the IDs without dependence on the Unix filesystem, and store them
in a database somewhere. But I'm looking for a short-term "hack" that will work
for me.
The devil is always in the details!
Bob
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:31:54 EST