From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 14:33:20 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 EDC0516A4CE; Wed, 14 Jan 2004 14:33:20 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD1C343D70; Wed, 14 Jan 2004 14:33:18 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i0EMXGL12562; Wed, 14 Jan 2004 23:33:16 +0100 (MET) Date: Wed, 14 Jan 2004 23:33:16 +0100 (CET) From: Harti Brandt To: Robert Watson In-Reply-To: Message-ID: <20040114233149.A15693@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 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 22:33:21 -0000 On Wed, 14 Jan 2004, Robert Watson wrote: RW> RW>On Wed, 14 Jan 2004, Harti Brandt wrote: RW> RW>> RW>So what ends up happening is what Coda and Arla do: take the 96-bit unique RW>> RW>identifier (viceid or fid), hash it to a somewhat unique value, and stick RW>> RW>the result in the vattr returned by VOP_GETATTR(). And sometimes RW>> RW>applications just get confused. Of course, many of those applications were RW>> RW>quite capable of getting confused before -- unless you hold a file open, RW>> RW>you can't prevent its inode number from being reused if the file is RW>> RW>deleted and a new one created. RW>> RW>> The problem is with archivers. Posix guarantees that if the device and RW>> the inode are equal then its the same file. If they are different its RW>> another file. If two different files have the same device/inode RW>> archivers that can store hard links will think that this is a hard link RW>> and will store only one file. If they are clever they will check the RW>> nlink is greater 1. But this doesn't help if both files have an nlink > RW>> 1. RW>> RW>> So backups of these larger file systems will likely be hosed. RW> RW>This can end up with incorrect operation on a live file system anyway: RW>nothing says the file with inode 400 can't be deleted, then reused as the RW>archiver runs, and then count as a false positive... :-) You can backup a snapshot. You can also forbid access to the file system while the backup is running. This is a different issue. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org