From owner-freebsd-arch Mon Mar 11 16:30:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id DC3B237B400; Mon, 11 Mar 2002 16:30:48 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2C0UerT102974; Mon, 11 Mar 2002 19:30:41 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 11 Mar 2002 19:30:40 -0500 To: Robert Watson , Harti Brandt From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 At 4:16 PM -0500 3/11/02, Robert Watson wrote: >AFS, Coda, and various other "global scale" filesystems rely on >a much larger unique identifier space than the traditional 64-bit >(dev_t, ino_t) pair. Coda, for example, uses a 96-bit "Vice ID" >which is per-realm. [...] >The complicating factor comes when you try and map the 96-bit >(plus realm) into the 32-bit inode number. [...] >The "uniqueness" aspect for these numbers is a serious scaling >problem: global filesystems can and will name trillions of file >system objects. Squeezing them into a single 32-bit number, or >even a pair, simply doesn't work. Moving to a 64-bit inode >number in FreeBSD would reduce the chances of a collision >dramatically, and probably enough that the risk would become >acceptable. > >A preferred solution approximates the POSIX conventions but >allows for a special call into the filesystem to check collision >cases. [...] If we went with a 64-bit dev_t and 64-bit ino_t for userspace, would that be enough to hold a unquestionably-unique id for every file that currently exists in something like Coda or AFS? Say, 64-bits for inode, 32-bits for volume-identifier, 16-bits for realm (or AFS cell), and 16-bits left over for some sort of future expansion? If UFS2 requires a 64-bit (u)ino_t, then we're going to have to make some kind of change to the struct returned by stat(). We have also talked about wanting 64-bit fields for time values in that same struct. The more I think about it, the more I think we should just move towards a 64-bit field for (u)dev_t at the same time. Maybe we should wrap these all up into one major change, so we can have a st_dev+st_ino which can handle all existing filesystems (with some room for expansion). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message