Re: simplifying linux_emul_convpath()

On Wed, 14 Jan 2004, Robert Watson wrote:

> On Wed, 14 Jan 2004, Harti Brandt wrote:
>
> > On Wed, 14 Jan 2004, Robert Watson wrote:
> > RW>For some time, I've been thinking of adding samefile() and fsamefile()
> > RW>system calls to FreeBSD, which would allow userspace applications to
> > RW>determine if two names or file handles refer to the same object without
> > RW>playing games with inode numbers, device ids, etc.  The reason to do this
> > RW>would be that 32-bit inode numbers are subject to collision on large file
> > RW>systems.  My initial implementation simply compared vnode pointers, but
> >
> > This is a seriouse violation of Posix and may make applications like
> > tar, mkisofs and friends do the wrong things. Are 32-bit inodes and UFS1
> > restriction?

It is mostly a binary compatibility restriction.  ino_t is declared
to be uint32_t, and the binary compatibility of things like stat(2)
depends on this.  ffs directory entries have 32-bit inode numbers
(independent of ino_t), and ffs2 didn't change this, so ffs just can't
support file systems with >= 2^32 inodes.

> 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.

Bruce