Date: Thu, 15 Jan 2004 07:02:27 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: simplifying linux_emul_convpath() Message-ID: <20040115064753.T3550@gamplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1040114114851.46433J-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040114114851.46433J-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040115064753.T3550>