>Justin T. Gibbs writes:
> > It doubles the number of stats needed to do an upgrade. It needs to
>Doubling stats on a client machine is not that much a problem. I am
>currently trying to do fast updatedb/locate program for our big
>fileservers and I am developing it using my own FreeBSD machine. The
>Slowest part is of course traversing filesystem. It took just some
>80+ seconds to traverse my 1GB disk with some >30000 files and >1000
>directories using brute force algorithm (stat for every file and
>directory) and about 70 seconds with 4.4BSD optimizations (using file
>info from struct dirent and onet stat() for each directory for other
>reasons). So making a few hundred or thousand stats on _client_
>machine is not really that much an issue, IMHO. On a loaded server you
>probably want to avoid any stats possible.
It is if I'm using SUP to mirror Auspexes (30+ gigabyte filesets). This
is something that will be happening shortly at TCS. Don't tell me that
doubling the number of stat calls is not a problem.
> > be implemented another way and an option. I should be able to create
> > #sup files all I want if I choose to distribute them via SUP.
>You can do that. The special name for foo#sup is foo#sup#sup .. :-)
So your saying I can distribute supfile and supfile#sup without it doing
the wrong thing?
> > No, he should have used PATH_MAX or SUP's own STRINGLENGTH there I
> > would guess.
>SUP's STRINGLENGTH (see sup.h) has nothing to do with PATH_MAX (or
>whatever) so using it is no more better than 1024 (actually worse).
>Using MAXPATHLEN (or is it PATH_MAX fro posix systems?) would be the
>right way, I suppose.
Justin T. Gibbs
TCS Instructional Group - Programmer/Analyst 1
Cory | Po | Danube | Volga | Parker | Torus