Date: Sat, 9 Mar 2002 14:42:54 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <Pine.BSF.4.21.0203091442340.54954-100000@InterJet.elischer.org> In-Reply-To: <p05101532b8b03545561a@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203091442340.54954-100000>