Re: simplifying linux_emul_convpath()

On Wed, 14 Jan 2004, Robert Watson wrote:

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

The problem is with archivers. Posix guarantees that if the device and
the inode are equal then its the same file. If they are different
its another file. If two different files have the same device/inode
archivers that can store hard links will think that this is a hard link
and will store only one file. If they are clever they will check the
nlink is greater 1. But this doesn't help if both files have an nlink > 1.

So backups of these larger file systems will likely be hosed.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt_at_fokus.fraunhofer.de, harti_at_freebsd.org