From owner-freebsd-arch Sat Mar 9 14:24:34 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 49D3037B402 for ; Sat, 9 Mar 2002 14:24:32 -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 g29MORVu016212 for ; Sat, 9 Mar 2002 17:24:27 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 9 Mar 2002 17:24:26 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Increasing the size of dev_t and ino_t 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 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