Date: Mon, 11 Mar 2002 19:30:40 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Robert Watson <rwatson@FreeBSD.ORG>, Harti Brandt <brandt@fokus.gmd.de> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p0510154eb8b2ed99898c@[128.113.24.47]> In-Reply-To: <Pine.NEB.3.96L.1020311160835.46602A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1020311160835.46602A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0510154eb8b2ed99898c>