[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet



On Tue, Feb 15 2011 at 11:07am -0500,
Jeff <jlar310 gmail com> wrote:

> On Tue, Feb 15, 2011 at 7:41 AM, Mike Snitzer <snitzer redhat com> wrote:
> > On Tue, Feb 15 2011 at  8:02am -0500,
> > Jeff <jlar310 gmail com> wrote:
> >
> >> On Mon, Feb 14, 2011 at 12:14 PM, Alasdair G Kergon <agk redhat com> wrote:
> >> > The simple problem is that the code today does not distinguish between
> >> > essential output (to stdout) and incidental output (to stdout).
> >> >
> >> > If I run 'pvs' I expect a list of PVs.
> >> > If I run 'pvs --quiet' do I still expect to see that list?
> >> >
> >> > Today, there is no distinction: pvs output and the message you're wanting
> >> > to suppress are the same category of message.
> >>
> >> Yes, there should be a difference between "do-something" commands and
> >> "tell-me-something" commands. I hope there aren't too many cases where
> >> that's a gray area.
> >
> > Ignoring the fact that we have a --quiet option for a moment, why is
> > the additional output of the command(s) so problematic?
> 
> In short, the --quiet option isn't quiet.
> 
> In the case of lvcreate and lvremove it prints purely informational
> confirmation messages to stdout. I find this somewhat inconsistent
> with other linux commands that offer a --quiet option (rsync for
> example).
> 
> It's not so much problematic as it is an issue of good design and
> documentation. It's easy enough for me to send stdout to /dev/null in
> my scripts, but that does run the risk of missing important
> information in the case of unexpected results. What if the program
> isn't so precise about sending error messages to stderr?

well lvm _should_ send all errors to stderr.

> As already stated, for commands such as lvcreate and lvremove where
> the user is requesting the lvm system to "do something" and not "tell
> me something" I think the --quiet option should actually make the
> program be quiet, which it does not in the current implementation.

Noted, definitely an lvm short-coming.

> I am not a hard-core c developer and it's not likely that I would be
> able to find the time to contribute trustworthy patches. If the
> lvm-powers-that-be wish to ignore me, I can live with that. I simply
> saw a potential improvement and chose to share my thoughts.

Not ignoring you at all.  This should get cleaned up.  I was just
pointing out that --quiet not actually being quiet isn't a showstopper
at the moment -- so such a janitorial audit can be deferred.

Thanks for the report,
Mike


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]