Date: Mon, 11 Mar 2002 16:05:50 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Julian Elischer <julian@elischer.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Harti Brandt <brandt@fokus.gmd.de>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101547b8b2bfddd16b@[128.113.24.47]> In-Reply-To: <Pine.BSF.4.21.0203111147250.64479-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0203111147250.64479-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:50 AM -0800 3/11/02, Julian Elischer wrote: >On Mon, 11 Mar 2002, Garance A Drosihn wrote: > > > 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? > >I suggest that we create such a number and store it in the >filesystem superblock for filesystems in questions. maybe the >time of creation in secs since the epoch. (is that already there?) >it has the advantage of following the drive if it were renamed.. Unfortunately the idea of "the drive" is one which does not map well into an AFS filesystem. Each AFS-site is making thousands of volumes available, and you're running an AFS client. The AFS servers are scattered around the globe. There is zero chance that you can get everyone who runs an AFS server (sites which are literally scattered around the planet) to add a 32-bit number somewhere to each of those volumes. And your machine will not have write-access to those volumes, unless you are an authenticated user (at that site) who has write-access to the directory the file is in. Also note that a lot of sites make read-only repositories available to anyone in the AFS world, eg: /afs/athena.mit.edu/reference/rfc . So, users will want to reference AFS-sites and AFS-volumes that they have no write access to (and NOTHING on your machine -- not even root -- will have write-access to those remote files or remote volumes). I don't know if there is any useful value which is already available and which is *less than* 32-bits. (it would have to be less-than, because any such value is only going to be unique across a single AFS-site, and there are more than 150 such sites, plus you don't want to run into conflicts with the st_dev's that you come up with for non-AFS files). At any given site, an AFS volume can move across disks and indeed across server-machines without the user noticing. Whatever we pick as a value for st_dev is something that must not change when a file (well, the whole volume it is on) is moved around like that. Here at RPI we do such migrations all the time, to keep our disks balanced (wrt how much free space they have). AFS has a lot of cool things about it, actually. It is Very Nice in several ways. However, there are many assumptions which are perfectly valid when talking about non-AFS filesystems, but which break down when applied to AFS. -- 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?p05101547b8b2bfddd16b>