Date: Mon, 11 Mar 2002 11:50:07 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Garance A Drosihn <drosih@rpi.edu> 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: <Pine.BSF.4.21.0203111147250.64479-100000@InterJet.elischer.org> In-Reply-To: <p05101542b8b281472641@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. > > 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. > 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?Pine.BSF.4.21.0203111147250.64479-100000>