Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 06 Apr 1995 00:09:12 -0700
From:      "Justin T. Gibbs" <gibbs@estienne.cs.berkeley.edu>
To:        Kai.Vorma@hut.fi
Cc:        "Jordan K. Hubbard" <jkh@freefall.cdrom.com>, "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, jkh@freebsd.org (Jordan K. Hubbard), CVS-commiters@time.cdrom.com, cvs-ports@time.cdrom.com
Subject:   Re: cvs commit: ports/net/sup/patches patch-ae 
Message-ID:  <199504060709.AAA22147@estienne.cs.berkeley.edu>
In-Reply-To: Your message of "Thu, 06 Apr 1995 10:04:08 %2B0300." <199504060704.KAA26897@vinkku.hut.fi> 

next in thread | previous in thread | raw e-mail | index | archive | help
>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.
>
>..vode
>

--
Justin T. Gibbs
==============================================
TCS Instructional Group - Programmer/Analyst 1
  Cory | Po | Danube | Volga | Parker | Torus
==============================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504060709.AAA22147>