From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 13:14:48 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 6E0FB16A4CE; Wed, 14 Jan 2004 13:14:48 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37A7143D39; Wed, 14 Jan 2004 13:14:45 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i0ELEhL02215; Wed, 14 Jan 2004 22:14:43 +0100 (MET) Date: Wed, 14 Jan 2004 22:14:43 +0100 (CET) From: Harti Brandt To: Robert Watson In-Reply-To: Message-ID: <20040114221135.V15441@beagle.fokus.fraunhofer.de> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Don Lewis cc: current@freebsd.org Subject: Re: simplifying linux_emul_convpath() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org 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 21:14:48 -0000 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@fokus.fraunhofer.de, harti@freebsd.org