linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs-progs and btrfs(8) inconsistencies
Date: Thu, 4 Feb 2016 15:19:24 -0500	[thread overview]
Message-ID: <56B3B24C.8070200@gmail.com> (raw)
In-Reply-To: <CAJCQCtTYFeM-ryJbFHfsiPEK+xbwkNoAmZ1=k8eaJ5TnS7yLaQ@mail.gmail.com>

On 2016-02-04 14:40, Chris Murphy wrote:
> On Thu, Feb 4, 2016 at 5:53 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>
>
>> 4) Possibly get rid of the message on subvolume delete (It provides no
>> useful information at all, and it has no option to not error out on non
>> existence of a subvolume.  In addition, the same arguments as for create
>> apply here too.).
>
> btrfs sub del has different commit modes that affect the user space
> command's completion behavior, and output. So I wouldn't say it isn't
> useful.
>
Last I checked, those are controlled by using command line switches, 
which means that anyone invoking them knows what they're invoking 
because it's specified on the command line, therefore all info it 
currently provides in the non-error case is info you should already 
have.  I have no issue with it spitting out errors if something goes 
wrong, but it's just annoying having output that provides no information 
that isn't already known when everything goes right (think atd, cron, 
and almost any other periodic or deferred scheduling system).


  reply	other threads:[~2016-02-04 20:19 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
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 [this message]
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=56B3B24C.8070200@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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).