From owner-freebsd-arch Sat Mar 9 22:39:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id DC76A37B402 for ; Sat, 9 Mar 2002 22:39:29 -0800 (PST) Received: from pool0032.cvx22-bradley.dialup.earthlink.net ([209.179.198.32] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16jwzP-0004Fl-00; Sat, 09 Mar 2002 22:39:27 -0800 Message-ID: <3C8AFF8E.4B4C6940@mindspring.com> Date: Sat, 09 Mar 2002 22:39:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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. The limiting factor for these is NFS. The ino_t is limited by the ondisk structure. Note that the dev_t limitation is antiquated... but so is the idea of "fixing" it. With devfs, tonly the fact that device lookups still go through specfs makes major/minor numbers relevent at all. Their point was to provide a rendesvous that allowed conversion from an FS reference to a device instance reference. However, we can do that now, without using major or minor values, merely by using the name-to-vnode conversion in devfs. > 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. You won't be able to export these via NFS, unless to have a 64 bit file instance to 32 bit reference instance conversion, and limit the number of open files to 2^32 simultaneous opens. Of course, doing that will add a significant reverse-lookup penalty for NFS handles, and for conversion of multiple name references into a single handle reference. > 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. Check the NFSv4 RFC... and then check for an implementation in FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message