Date: Thu, 15 Aug 1996 16:15:15 -0700 From: John Polstra <jdp@polstra.com> To: Nate Williams <nate@mt.sri.com> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, davidg@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, stable@freebsd.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <199608152315.QAA27581@austin.polstra.com> In-Reply-To: Your message of "Thu, 15 Aug 1996 16:35:38 MDT." <199608152235.QAA03483@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Speaking of which, what do folks think about shutting down sup access > > to -stable and forcing a move towards CTM and CVSup for -stablefolk? > > > > It's *very* wasteful to have all those supfilesrv process's scanning > > the entire source tree for what are, at most, a couple of changes a > > week, not to mention the overhead of cvs updating the checked out > > version of -stable for sup on freefall. > > CVSup using checkout mode could easily be at least as compute bound as sup > in checkout mode if it has to stat all the files everytime (which SUP > with supscan running does only once), but John would be better suited to > answer with the details. I think Nate is right. You use supfilescan for the -stable release, don't you? If so, then supfilesrv should definitely be cheaper in terms of CPU cycles and disk accesses. About the overhead of cvs updating the checked out version, CVSup's checkout mode is actually much more efficient than that. (I've measured it.) But with cvs, you only do it once a day. With CVSup, the (lesser) work would be repeated for each client. So it would depend on the number of clients per day, among other things. The one reason I can think of for shutting down sup access to -stable would be if you want to free up all the disk space that's currently needed for the checked-out copy on the server. -- John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608152315.QAA27581>