Date: Mon, 11 Mar 2002 11:14:38 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Poul-Henning Kamp <phk@critter.freebsd.dk>, Harti Brandt <brandt@fokus.gmd.de> Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101542b8b281472641@[128.113.24.47]> In-Reply-To: <17497.1015840078@critter.freebsd.dk> References: <17497.1015840078@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:47 AM +0100 3/11/02, Poul-Henning Kamp wrote:
>(Sorry, I confused st_dev and st_rdev earlier).
>
>Ok, I think we are on the same page now.
>
>I don't think any of the stuff headed for -current would give
>you trouble in this respect. Just because we _can_ assign a
>random st_dev doesn't mean we will shoot ourselves in the foot
>by doing so :-)
Given what we (RPI) have with our present AFS cell, I am not
sure how easy it will be to do this. If you follow my previous
description of AFS, you realize that RPI (by itself) has over
33,000 unique AFS volumes. We also have users who will touch
a large percentage of those volumes by typing in a single 'find'
command. If FreeBSD comes up with a unique random number for
each volume as it is referenced, and it has to cache all the
mappings between unique-numbers and AFS-volumes (so it can
tell when the same AFS volume is found at a different pathname
in AFS space), then that strikes me as an unwieldy situation.
Perhaps I should just explain it this way. Assume that a person
can have an /etc/fstab which will mount >33,000 separate volumes.
Do not debate whether you believe this will happen, because it
is *already* happening with AFS at RPI. Given a situation where
the system will have more than 33,000 separate mounts, can we
come up with a good way to cache all those random numbers?
Also note that the >33,000 number is only for the AFS cell at
RPI, and the way AFS works any single workstation can be mounting
volumes from more than 150 different AFS cells. AFS is trying
to create a world-wide distributed file system, and as such it
sees scaling issues that no one faces with NFS.
>And still, I see no pressure to increase the size of (u)dev_t
>on any platforms.
My thinking is:
1) there will be a desire to increase (u)ino_t to 64-bits
due to UFS2.
2) due to AFS, I don't want that to happen by *shrinking*
the size of (u)dev_t (which had been suggested in some
messages when I brought this up a year or two ago).
3) if we have to make the incompatible change for a 64-bit
(u)ino_t, it would make some sense to also leave room
in the new 'struct stat' for 64-bit timestamps and
maybe even a 64-bit (u)dev_t, although I do agree that
the 64-bit (u)dev_t is the least important change to
consider...
I am not completely certain that (u)dev_t needs to increase in
size, but I am pretty close to adamant that it must not decrease
in size.
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101542b8b281472641>