Re: simplifying linux_emul_convpath()

On Wed, 14 Jan 2004, Robert Watson wrote:

> On Thu, 15 Jan 2004, Bruce Evans wrote:
>
> > > That inode numbers are subject to collision is a practical reality with
> > > the existence of globally scalable distributed file systems.  Many file
> > > formats, APIs, and ABIs assume a 32-bit inode number; however, distributed
> > > systems like AFS support hundreds of thousands, if not millions, of
> > > concurrent users and computer systems.  Expecting each user/computer to
> >
> > It's a practical reality that file systems with inode numbers >= 2^32
> > cannot work in FreeBSD now.
>
> So what ends up happening is what Coda and Arla do: take the 96-bit unique
> identifier (viceid or fid), hash it to a somewhat unique value, and stick
> the result in the vattr returned by VOP_GETATTR().  And sometimes
> applications just get confused. Of course, many of those applications were
> quite capable of getting confused before -- unless you hold a file open,
> you can't prevent its inode number from being reused if the file is
> deleted and a new one created.

I didn't quote the part where you explained why hashing didn't work :-).

Another example is the psuedo-hashing in getnewfsid().  The namespace is
very sparse there, but it's still not easy to ensure that the hash number
is unique without actually doing an expensive full search of all the
active hash numbers.

Bruce