RE: NFS Under OS X (was Re: pre-asun2.1.4-39)


Subject: RE: NFS Under OS X (was Re: pre-asun2.1.4-39)
From: Jonathan Newman (jnewman@mudpup.com)
Date: Thu Jul 20 2000 - 17:22:33 EDT


> Also, one side note-
>
> The latest version (in the subj) has eliminated the alias problem
> and AFAIK, has not damaged any files, graphics or otherwise.

I personally have seen issues with the DID hack for aliases. Error messages
appear in the logs about directories mapping to the same ID, and the macs
trying to use those directories would have to be rebooted. Not all that
pretty. Your experience may be different. There are a fixed number of bits
used for creating the IDs, and IIRC it is a combination of the device and
the inode. If your inode values overflow the bitspace, you can have
multiple items mapping to the same ID.

It really is a kludge (IMO). 37 does not have the kludge, but it is also
lacking in the locking fixes/enhancements that are in 39. I'm hoping to get
some time to roll the locking code from 39 into the "relatively kludgeless"
37. Your experience may vary.

After a quick search, I _think_ this is the code in question. The comment
is not mine, but actually in the asun code (etc/afpd/directory.h):

/* file/directory ids. what a mess. we scramble things in a vain attempt
 * to get something meaningful */
#ifndef AFS
#define CNID_XOR(a) (((a) >> 16) ^ (a))
#define CNID_DEV(a) ((((CNID_XOR(major((a)->st_dev)) & 0xf) << 3) | \
        (CNID_XOR(minor((a)->st_dev)) & 0x7)) << 24)
#define CNID_INODE(a) (((a)->st_ino ^ (((a)->st_ino & 0xff000000) >> 8)) \
                                       & 0x00ffffff)
#define CNID_FILE(a) (((a) & 0x1) << 31)
#define CNID(a,b) (CNID_DEV(a) | CNID_INODE(a) | CNID_FILE(b))
#else
#define CNID(a,b) (((a)->st_ino & 0x7fffffff) | CNID_FILE(b))
#endif

Jon Newman
>



This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:31:33 EST