Date: Mon, 11 Mar 2002 08:22:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> 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: <3C8CD9B8.53D6B36F@mindspring.com> References: <17497.1015840078@critter.freebsd.dk> <p05101542b8b281472641@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn wrote: > 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. Poul is a non-native English speaker, and this often leads to intepretation issues. The usage here is archaic English, and the "can"/"will" are paired, which isn't clear from the use of the predicate phrase "by doing so". You should read this as "Just because we _can_ ... doesn't mean we _will_ ...". > 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. This is a seperate problem. As you note, the number is already larger than 2^15; it's going to face scaling issues, no matter how you look at it, due to the single volume identification space. -- 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?3C8CD9B8.53D6B36F>