All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kjörling" <michael@kjorling.se>
To: kreijack@inwind.it
Cc: Martin Steigerwald <Martin@lichtvoll.de>,
	Hugo Mills <hugo@carfax.org.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: [RFC] New attempt to a better "btrfs fi df"
Date: Sun, 28 Oct 2012 11:18:58 +0000	[thread overview]
Message-ID: <20121028111858.GC2381@yeono.kjorling.se> (raw)
In-Reply-To: <508D1015.6050100@gmail.com>

On 28 Oct 2012 11:59 +0100, from kreijack@gmail.com (Goffredo Baroncelli):
> On 2012-10-28 11:38, Martin Steigerwald wrote:
>> But still if if can be arbitrarily long due to that per object replication 
>> config, a vertical output might and leaving graphical representation to a 
>> Qt Quick application or so might be better.
> 
> Yes, this is my same feel: For console I prefer a text representation in
> rows, leaving to a graphical GUI to show the information in columns..

So a sysadmin who logs on to a server (which uses btrfs) over plain
SSH should need to install a good chunk of X11 plus a load of support
libraries on the server, plus have a X11 server on the machine they
are connecting from, simply to get a tabular view of the disk space?

That _might_ fly in a strictly *nix environment. In a mixed
*nix/Windows (and maybe even throw in some Mac OS X) environment, not
necessarily as much so. And what about the sysadmin on the road who
logs on using a smartphone SSH client to get a quick overview of the
disk usage situation because they received an alert that disk space is
starting to run low?

It appears to me that what is being discussed here is, to some extent,
an edge case of use of a file system feature that hasn't even been
implemented yet, but rather is only planned. Like Martin pointed out,
scripts should not parse meant-for-human-consumption output anyway,
and beyond trivial greps and that kind of parsing, tabular data by
design lends itself rather poorly to script parsing anyway.

I would personally really prefer a tabular view that perhaps does not
show _all_ details when no explicit parameters are given, and a
"--dump" or similar that will give a fuller data dump that might lend
itself better to parsing by other tools for a more thorough
presentation. The data is all right there; it's basically a matter of
deciding how much of it to show by default.

-- 
Michael Kjörling • http://michael.kjorling.se • michael@kjorling.se
                “People who think they know everything really annoy
                those of us who know we don’t.” (Bjarne Stroustrup)

  reply	other threads:[~2012-10-28 11:19 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25 19:21 [RFC] New attempt to a better "btrfs fi df" Goffredo Baroncelli
2012-10-25 19:40 ` cwillu
2012-10-25 19:59   ` Goffredo Baroncelli
2012-10-25 20:06     ` cwillu
2012-10-25 20:36   ` Chris Murphy
2012-10-25 20:49     ` cwillu
2012-10-25 20:52       ` Goffredo Baroncelli
2012-10-25 20:03 ` Chris Murphy
2012-10-25 20:11   ` cwillu
2012-10-25 20:41     ` Goffredo Baroncelli
2012-10-26  2:33     ` Chris Murphy
2012-10-26  3:36       ` cwillu
2012-10-26  4:03         ` Chris Murphy
2012-10-27 15:05         ` Chris Murphy
2012-10-27 16:43 ` Martin Steigerwald
2012-10-27 19:55   ` Michael Kjörling
2012-10-27 22:30     ` Martin Steigerwald
2012-10-27 22:38       ` Hugo Mills
2012-10-27 23:01         ` Michael Kjörling
2012-10-28 10:58           ` Martin Steigerwald
2012-10-28  8:45         ` Goffredo Baroncelli
2012-10-28 10:38           ` Martin Steigerwald
2012-10-28 10:59             ` Goffredo Baroncelli
2012-10-28 11:18               ` Michael Kjörling [this message]
2012-10-28 12:25                 ` Goffredo Baroncelli
2012-10-28 12:48                   ` Michael Kjörling
2012-10-28 13:22                   ` Martin Steigerwald
2012-10-27 23:35     ` Chris Murphy
2012-10-28 11:20       ` Michael Kjörling
2012-10-28  9:01 ` Goffredo Baroncelli
2012-10-28 10:33   ` Martin Steigerwald
2012-10-28 10:58     ` Goffredo Baroncelli
2012-10-28 11:16       ` Martin Steigerwald
2012-10-28 18:27         ` Chris Murphy
2012-10-28 19:06           ` Michael Kjörling
2012-10-28 19:42             ` Chris Murphy
2012-10-28 20:09               ` Michael Kjörling
2012-10-28 20:19                 ` Chris Murphy
2012-10-29  9:04                   ` Michael Kjörling
2012-10-30  4:41                     ` Chris Murphy
2012-10-28 19:42             ` Chris Murphy
2012-10-29 13:06             ` Randy Barlow
2012-10-29 22:21 ` [RFC][V2] " Goffredo Baroncelli
2012-10-30  9:42   ` Michael Kjörling
2012-10-30 18:15     ` Goffredo Baroncelli
2012-10-30 18:32       ` Michael Kjörling
2012-10-30 20:13         ` Chris Murphy

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=20121028111858.GC2381@yeono.kjorling.se \
    --to=michael@kjorling.se \
    --cc=Martin@lichtvoll.de \
    --cc=hugo@carfax.org.uk \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.