Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 09 Mar 2002 22:39:10 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Increasing the size of dev_t and ino_t
Message-ID:  <3C8AFF8E.4B4C6940@mindspring.com>
References:  <p05101532b8b03545561a@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8AFF8E.4B4C6940>