From owner-freebsd-arch Sat Mar 9 15: 0:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 7A42737B416 for ; Sat, 9 Mar 2002 15:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020309230014.GKZR1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sat, 9 Mar 2002 23:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA55417; Sat, 9 Mar 2002 14:42:55 -0800 (PST) Date: Sat, 9 Mar 2002 14:42:54 -0800 (PST) From: Julian Elischer To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 dev_t will not exist in 6.0 On Sat, 9 Mar 2002, Garance A Drosihn wrote: > This is something I've mentioned before, but reviewing the freebsd > summit notes reminded me of it once again. The change itself is > simple, but it would be disruptive enough that we can only consider > it as part of a major release (such as the upcoming 5.0). > > Should we increase the size of dev_t and ino_t? Right now, both > of them are unsigned 32-bit values. I shall claim that both of > those are too small, or at least they WILL be too small by the > time 6.0 rolls out. > > dev_t indicates the "device number" that a file is on, and and > ino_t is the inode within that device. These are the st_dev > and st_ino fields in 'struct stat'. > > At the summit, it was stated that UFS2 should (hopefully) be > available for 5.0-release, and that it will be a 64-bit filesystem. > If that is true, then it is certainly plausible that a single > filesystem will see more than a 32-bit-ints-worth of inodes. > And the hard-drive makers are also doing their best to produce > huge hard disks. > > At the same time, we're seeing distributed file systems like AFS > (or, more to the point, openAFS and ARLA). The nature of those > filesystems are that you will mount many devices which might all > be available at the same time. For those who are familiar with > AFS, I would claim that every AFS volume should be a separate > device (as far as st_dev in 'struct stat' is concerned), and if > that is true than we can certainly end up with more than a > 16-bit-ints-worth of devices, and probably more than a 32-bit- > ints worth. I know the field is already a 32-bit int there, but > the significance of my observation is that we can't just increase > the size of st_ino and decrease the size of st_dev. I think that > st_dev has to remain at *least* as large as it already is, and > that we need to increase st_ino as well. > > Perhaps we only need to do this for the newer, 64-bit platforms. > (perhaps we already are doing it there?). But I thought I would > bring the topic up and see what others thought about it. > > -- > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message