[OpenAFS-devel] PATCH: autotuned cache files limit and fs getcacheparms update

Troy Benjegerdes hozer@hozed.org
Mon, 29 Aug 2005 12:17:24 -0500


On Sun, Aug 28, 2005 at 07:33:16PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Saturday, August 27, 2005 21:03:37 -0500 Troy Benjegerdes 
> <hozer@hozed.org> wrote:
> 
> >Here's a better version. Default behavior is the following:
> >
> >>fs getcache
> >AFS using    22% of cache blocks (4346186 of 20000000 1k blocks)
> >             18% of the cache files (91319 of 500000 files)
> 
> Yeah; you're still changing the default output format.
> Please don't do that; give people a -verbose switch or whatever, but don't 
> say "well, if you have a script that parses this, then you need to either 
> teach it to parse the new format, or have it pass a new switch that old 
> versions of the tool won't accept".
> 
> As it stands now, there is no way for a program to invoke 'fs getcache' in 
> a way that is guaranteed to produce the output format it needs without 
> knowing in advance whether it has your patch or not.

Do you have any scripts that parse the output of 'fs getcacheparms' ?
Is there anyone that this is going to cause a big problem for?

I see this as a trade-off of changeing the default behavior so it is
much more likely we will get usefull information about real-world cache
space and file usage. The downside is some scripts break.

Would a configure option be a better choice? This we we can enable the
new behavior by default, and anyone that really really needs the old
behavior can rebuild the 'fs' command. We are prepareing a new
release, and a lot more than just 'fs getcache' behavior has changed.