From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 12:23:59 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 D4F3B16A4CF; Wed, 14 Jan 2004 12:23:59 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D51B43D93; Wed, 14 Jan 2004 12:22:48 -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 HAA21249; Thu, 15 Jan 2004 07:21:47 +1100 Date: Thu, 15 Jan 2004 07:21:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20040115071736.B3765@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:24:00 -0000 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