linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Moviuro <moviuro@gmail.com>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs-progs and btrfs(8) inconsistencies
Date: Thu, 04 Feb 2016 11:14:17 +0100	[thread overview]
Message-ID: <1724218.nF6PTv1Cei@merkaba> (raw)
In-Reply-To: <CAM=f9=X5BU0N4iueXtVf4y5SAxrnMQgtgbrsx0Gbc8W6SEspMg@mail.gmail.com>

Am Donnerstag, 4. Februar 2016, 09:57:54 CET schrieb Moviuro:
> > Although personally I like to let all the backward compatibility
> > things go hell, but that's definitely not how things work. :(
> > 
> > 2) End-user taste.
> > Some end-users like such info as feedback of success.
> > Of course other users like it act as silent as possible.
> 
> I'm pretty sure that's... not the case. Almost everything on GNU/Linux
> is silent. cd(1) is silent, cp(1) is silent, rm(1)...
> What they all have though is a -v|--verbose switch.

The various mkfs commands are not. Not one of them I know of. Additionally 
each one gives a different output.

pvcreate, vgcreate, lvcreate and as well as the remove commands and probably 
other LVM commands are not (no one could argue, that from their ideas they 
come from HP/UX, but thats a Unix as well):

merkaba:~> lvcreate -L 1G -n bla sata
  Logical volume "bla" created.

And I think, not testing right now, that also mdadm is not silent on creating 
a softraid.

So while I agree with you that regular shell commands (coreutils, util-linux) 
are silent on success usually this does not appear to be the case with storage 
related commands in GNU/Linux.

I don´t have a clear oppinion about it other than I´d like to see some 
standard too. coreutils / util-linux both them to have some kind of standard, 
although not necessarily the same standard I bet. And I am not sure whether it 
is documented somewhere.

-- 
Martin

  parent reply	other threads:[~2016-02-04 10:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 21:54 btrfs-progs and btrfs(8) inconsistencies Moviuro
2016-02-04  1:33 ` Qu Wenruo
2016-02-04  8:57   ` Moviuro
2016-02-04  9:15     ` Qu Wenruo
2016-02-04 10:14     ` Martin Steigerwald [this message]
2016-02-04 12:04       ` Moviuro
2016-02-04 12:53       ` Austin S. Hemmelgarn
2016-02-04 19:40         ` Chris Murphy
2016-02-04 20:19           ` Austin S. Hemmelgarn
2016-02-04 20:40             ` Moviuro
2016-02-05 13:04               ` Austin S. Hemmelgarn
2016-02-04 17:17   ` Goffredo Baroncelli
2016-02-04 19:48     ` Hugo Mills
2016-02-04 20:10     ` Chris Murphy
2016-02-04 18:22 ` Chris Murphy
2016-02-05  3:11 ` Anand Jain
2016-02-05 12:59   ` Austin S. Hemmelgarn
2016-02-06 21:35   ` Chris Murphy
2016-02-07 10:07   ` Qu Wenruo
2016-02-07 20:26     ` Goffredo Baroncelli
2016-03-08 16:02 ` David Sterba
2016-03-09 10:02   ` Moviuro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1724218.nF6PTv1Cei@merkaba \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=moviuro@gmail.com \
    --cc=quwenruo@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).