NFS ID mapping (was: cpio - segmentation violation)

[Ed Gould]

>Given a choice between the Yellow Pages and RFS approaches to ID mapping,
>I much prefer the RFS style.  Rather than adopt Yellow Pages here when we
>first installed NFS, we tossed YP and instead went to a "campus-wide"
>global UID scheme.  I'm not recommending that, but it shows what low
>regard some sites had for YP.

Very few people, including some developers at Sun, hold YP in high
regard.  But YP and UID mapping address separate issues.  Adopting an
administrative solution to a global UID space (e.g., assigning ranges
of UIDs to different groups) is often a very good idea.  It's probably
better than a single-administration scheme like YP.

UID mapping, on the other hand, addresses the situation where it is not
feasable or reasonable to demand a global UID space.  Maps are
typically per server-client pair, so any general mapping can be
implemented.  Note that mapping is potentially either expensive or
introduces problems of its own.

Maybe we should go to something like the Ethernet scheme:  Use 80-bit
UIDs built as follows.  The low-order 16 bits are the current UID,
treated as an unsigned quantity, and assigned by the "user" (in this
case the administrator) of each system.  The upper 64 bits are divided into
two 32-bit quantities.  The high-order 32 bits are assigned from a
global registry of UID-using manufacturers.  Each manufacturer assigns
a unique number to each system in the low-order 32 bits.

Is this enough bits (2^32 manufacturers, 2^32 systems/manufacturer,
64K users/system)?  Where do we store all of this junk?

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
ed at mtxinu.COM		    +1 415 644 0146

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."