Re: lvcreate and lvremove --quiet option is not quiet

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

 



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

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux