From owner-freebsd-arch Mon Mar 11 8:14:46 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 1CEAB37B416 for ; Mon, 11 Mar 2002 08:14:42 -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 g2BGEdrT073368; Mon, 11 Mar 2002 11:14:40 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <17497.1015840078@critter.freebsd.dk> References: <17497.1015840078@critter.freebsd.dk> Date: Mon, 11 Mar 2002 11:14:38 -0500 To: Poul-Henning Kamp , Harti Brandt From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: arch@FreeBSD.ORG 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 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