[451] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Michael T. Stolarchuk)
Mon Nov 18 15:07:40 1991
To: Wallace Colyer <wally+@andrew.cmu.edu>
Cc: Cal_Thixton@next.com, Info-AFS@transarc.com, mts@terminator.cc.umich.edu
In-Reply-To: Your message of "Mon, 18 Nov 91 11:15:58 EST."
Date: Mon, 18 Nov 91 13:33:19 -0500
From: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>
.../afs/andrew.cmu.edu/usr...
"Stats are still expensive no matter what you do at this level"
No joke. If I recall right, my test for large directories was
/afs/andrew.cmu.edu/usr. Its that 10,000 entry directory which
was my test case for the NeXT browser. It was 'kinda' convienient
that someone took the time to make a huge direcotry for me to stat...
The 'real' problem with /afs/andrew.cmu.edu/usr isn't really the
size of the directory. I had a version of the NeXT code which
did Bulk stat's to recover lots of the entries in 'current'
directories... that code never really made it into the public
cause of /afs/andrew.cmu.edu/usr.
The 'real' problem is that each entry is a symbolic link into
another directory, which was then a 'fs mkmount' for the entry.
Even bulk stating those entries was useless, since you could get
the details on the entries of the local directory, only to find
each was a symbolic link (sigh, you get the status and have more
work to do), whose file contents have to be read (heavy sigh),
which evaluates to ANOTHER symbolic link (almost time to cry),
for a 'fs mkmount', which then has to be stated to get its
contents....
So cause of /afs/andrew.cmu.edu/usr, the bulk status stuff wasn't
even enough...
mts.
