From owner-freebsd-arch Mon Mar 11 14: 9:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 2DF8537B402; Mon, 11 Mar 2002 14:09:49 -0800 (PST) Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2BM9mj03325; Mon, 11 Mar 2002 23:09:48 +0100 Date: Mon, 11 Mar 2002 23:09:48 +0100 From: Christoph Hellwig To: Robert Watson Cc: Harti Brandt , Garance A Drosihn , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <20020311230948.A2914@caldera.de> References: <20020311172142.K1371-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Mon, Mar 11, 2002 at 04:16:48PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 11, 2002 at 04:16:48PM -0500, Robert Watson wrote: > The complicating factor comes when you try and map the 96-bit (plus realm) > into the 32-bit inode number. FreeBSD runs fine, but some applications > assuming the POSIX device number/inode number equality behave poorly. For > example, gnu tar may find collisions and assume files are a hard link when > they are not. Linux, on the other hand, uses the inode numbers within the > kernel, and may panic if there is a collision. The only place Linux uses the inode number is the generic inode cache implementation, which may or may not be used by filesystems. Also there won't be panic because you can't read in two inodes having the same i_ino when using it.. Christoph -- Of course it doesn't work. We've performed a software upgrade. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message