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

[Spencer E. Olson]

--=-jBO0jsst6za1Jcry0TcM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm not really in favor of keeping commands hidden.  Obviously, we all
know that security through obscurity is not very good and for us that
are new to administering cells, it is really helpful to see all the
commands visible with 'fs|vos|bos|... help'--besides, who wants to read
the man page when you can see the quick reference "guide" in 'fs
help' :-).  Normal users don't try to/can't do everything that 'fs help'
currently lists anyways, so obscuring seems pointless.


Spencer


On Tue, 2010-10-19 at 07:27 -0400, Phillip Moore wrote:
>=20
>=20
> Would you accept a patch that introduces two new fs commands:
>  =20
>     fs getprecache
>     fs setprecache
>=20
>=20
> 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.
>=20
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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.
>        =20
>        =20
>         Probably. And I take blame for that.
>        =20
>         > Is this another bleeding edge feature that the authors
>         thought wasn't
>         > important enough to write a man page for?
>        =20
>        =20
>         No.
>        =20
>        =20
>        =20
>         --
>         Derrick
>=20
>=20

--=20
Mirrors should reflect a little before throwing back images.
        -- Jean Cocteau

--=-jBO0jsst6za1Jcry0TcM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAky9if4ACgkQqJi1KLrSDQ9I8wCfaO7VacByyIJ4iEbb4GVpvMm7
rwgAn1e6fI5K646Vb8lTOoV+g9knS/IW
=WnTj
-----END PGP SIGNATURE-----

--=-jBO0jsst6za1Jcry0TcM--