[OpenAFS-devel] Re: [OpenAFS] Documentation for fs precache

Phillip Moore w.phillip.moore@gmail.com
Tue, 19 Oct 2010 07:27:46 -0400


--20cf300fb2cd07f1490492f6958c
Content-Type: text/plain; charset=ISO-8859-1

Would you accept a patch that introduces two new fs commands:

    fs getprecache
    fs setprecache

and that "hides" the precache command?  IOW, precache will work, but it will
not show up in fs help output.  This introduces a new pair of get/set
commands, and would give admins the ability to query the value, and
therefore manage it.

Alternately, fs precache can be modified to display the value when no
arguments are provided, instead of generate a syntax error like it does
right now.

There's a lack of consistency in the fs commands, but my personal preference
is for get/set commands when we add new features, as opposed to a single
command for both setting and querying something.

On Mon, Oct 18, 2010 at 1:50 PM, Derrick Brashear <shadow@gmail.com> wrote:

> On Mon, Oct 18, 2010 at 1:45 PM, Phillip Moore
> <w.phillip.moore@gmail.com> wrote:
> > Another fs command I can't find any documentation for:  fs precache
> > In this case, it appears that there's no way to query the value.   This
> > seems like bad interface design to me.  If there's a mechanism for
> setting
> > an important value that changes the behavior of the client, there has to
> be
> > a mechanism for querying that value.  Otherwise, you can't manage it.
> >  Write-only, read-never parameters are very bad.
> > Looking at the code in src/venus/fs.c, it looks to me like this *should*
> > have been implemented as a pair of CLI commands: setprecache and
> > getprecache, and in fact, that should be straight forward, and fully
> > backwards compatible.
>
> Probably. And I take blame for that.
>
> > Is this another bleeding edge feature that the authors thought wasn't
> > important enough to write a man page for?
>
> No.
>
>
>
> --
> Derrick
>

--20cf300fb2cd07f1490492f6958c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><br></div><div>Would you accept a patch that introduces two new fs com=
mands:</div><div>=A0=A0</div><div>=A0=A0 =A0fs getprecache</div><div>=A0=A0=
 =A0fs setprecache</div><div><br></div><div>and that &quot;hides&quot; the =
precache command? =A0IOW, precache will work, but it will not show up in fs=
 help output. =A0This introduces a new pair of get/set commands, and would =
give admins the ability to query the value, and therefore manage it.</div>
<div><br></div><div>Alternately, fs precache can be modified to display the=
 value when no arguments are provided, instead of generate a syntax error l=
ike it does right now.</div><div><br></div><div>There&#39;s a lack of consi=
stency in the fs commands, but my personal preference is for get/set comman=
ds when we add new features, as opposed to a single command for both settin=
g and querying something.</div>
<div><br><div class=3D"gmail_quote">On Mon, Oct 18, 2010 at 1:50 PM, Derric=
k Brashear <span dir=3D"ltr">&lt;<a href=3D"mailto:shadow@gmail.com">shadow=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, Oct 18, 2010 at 1:45 PM, Phillip Moore<br>
&lt;<a href=3D"mailto:w.phillip.moore@gmail.com">w.phillip.moore@gmail.com<=
/a>&gt; wrote:<br>
&gt; Another fs command I can&#39;t find any documentation for: =A0fs preca=
che<br>
&gt; In this case, it appears that there&#39;s no way to query the value. =
=A0 This<br>
&gt; seems like bad interface design to me. =A0If there&#39;s a mechanism f=
or setting<br>
&gt; an important value that changes the behavior of the client, there has =
to be<br>
&gt; a mechanism for querying that value. =A0Otherwise, you can&#39;t manag=
e it.<br>
&gt; =A0Write-only, read-never parameters are very bad.<br>
&gt; Looking at the code in src/venus/fs.c, it looks to me like this *shoul=
d*<br>
&gt; have been implemented as a pair of CLI commands: setprecache and<br>
&gt; getprecache, and in fact, that should be straight forward, and fully<b=
r>
&gt; backwards compatible.<br>
<br>
</div>Probably. And I take blame for that.<br>
<div class=3D"im"><br>
&gt; Is this another bleeding edge feature that the authors thought wasn&#3=
9;t<br>
&gt; important enough to write a man page for?<br>
<br>
</div>No.<br>
<br>
<br>
<br>
--<br>
<font color=3D"#888888">Derrick<br>
</font></blockquote></div><br></div>

--20cf300fb2cd07f1490492f6958c--