At IBM research, we have been exploring the possibility of augmenting the
CellServDB with the DNS based cell locating mechanism. If we are
successful, cell admins will not need to put all cells in the CellServDB
file. The clients (we are currently working on Linux and Windows 9x) will
be able to reach cells that are not listed in the CellServDB file. This
might mitigate the problem of a large static /afs directory with hundreds
of cells. We are also planning on implementing a history-oriented listing
of cells on a per user basis. When a user does an "ls" or the equivalent,
only the cells that the user visited recently will be listed. We will
also try to avoid contacting a cell unless the cell is being visited.
Note that this is some work in IBM research. Although we will try to make
the results (when the work is done) available to the AFS community in any
viable way, I am not representing Transarc/IBM or making any product
commitment for the company.
Shyh-Wei Luan
Manager, Internet Storage
IBM Almaden Research Center
Terry McCoy <[EMAIL PROTECTED]>@transarc.com on 07/27/2000 07:41:57 AM
Sent by: [EMAIL PROTECTED]
To: Noel Hunt <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: root.othercells - a solution to "ls /afs" takes a long time
I would agree, it is really a social engineering problem. But the easy
at which file managers allow someone to navigate around mounted file
systems (Unix world) or mount network drives (Windows world) has caused
many complaints from users about long delays. Which has resulted in us
having to trim down the number of cells that are available.
But... when you have several thousand users, its easier to maintain the
symbolic links, than to have to deal with the noise.
On Thu, 27 Jul 2000, Noel Hunt wrote:
> I don't think making a change like this *simply* so that `ls /afs'
> doesn't take a long time, is warranted. It looks like another abuse
> of symlinks.
>
--
Terry McCoy email: [EMAIL PROTECTED]
Sr Systems Engineer phone: (219) 631-4274
Enterprise Systems Software
Office of Information Technologies
University of Notre Dame
