From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 12:03:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D250216A4E5; Wed, 14 Jan 2004 12:03:23 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF33F43D99; Wed, 14 Jan 2004 12:02:30 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id HAA19648; Thu, 15 Jan 2004 07:02:27 +1100 Date: Thu, 15 Jan 2004 07:02:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20040115064753.T3550@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Don Lewis cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: simplifying linux_emul_convpath() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 20:03:24 -0000 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