On 2 Nov 2012 20:40 +0000, from g2p.c...@gmail.com (Gabriel):
> Now that I've started bikeshedding, here is something that I would
> find pretty much ideal:
>
> Data Metadata System Unallocated
>
>
> VolGroup/Btrfs
> Reserved 1.31TB 8.00MB + 2×28.00MB 16.00MB + 2×4.00MB -
> Used 1.31TB 2× 5.65GB 2×152.00KB -
> ======= ================== ================== ===========
> Total
> Reserved 1.31TB 56.00GB 24.00MB -
> Used 1.31TB 11.30GB 304.00KB -
> Free 12.34GB 44.70GB 23.70MB -
If we can take such liberties, then why bother with the 2× at all?
Also, I think the "B" can go, since it's implied by talking about
storage capacities. A lot of tools do this already; look at GNU "df -h"
and "ls -lh" for just two examples. That gives you a few extra columns
which can be used to make the table column spacing a little bigger even
in an 80-column terminal.
I'm _guessing_ that you meant for metadata reserved to be 2 × 28 GB and
not 2 × 28 MB, because otherwise the numbers really don't add up.
Data Metadata System Unallocated
VolGroup/Btrfs
Reserved 1.31T 8.00M + 28.00G 16.00M + 4.00M -
ResRedun - 28.00G 4.00M -
Used 1.31T 5.65G 152.00K -
UseRedun - 5.65G 152.00K -
======= ============== ================ ===========
Total
Reserved 1.31T 56.01G 24.00M -
Used 1.31T 11.30G 304.00K -
Free 12.34G 44.71G 23.70M -
This way, the numbers should add up nicely. ("Redun" for "redundancy" or
something like that.) 8M + 28G + 28G = 56.01G, 5.65G + 5.65G = 11.30G,
56.01G - 11.30G = 44.71G. I'm not sure you couldn't even work 8.00M +
28.00G into a single 28.01G entry at Reserved/Metadata, with
ResRedun/Metadata 28.00G. That would require some care when the units
are different enough that the difference doesn't show up in the numbers,
though, since then there is nothing to indicate that parts of the
metadata is not stored in a redundant fashion.
If some redundancy scheme (RAID 5?) uses an oddball factor, that can
still easily be expressed in a view like the above simply by displaying
the user data and redundancy data separately, in exactly the same way.
And personally, I feel that a summary view like this, for Data, if an
exact number cannot be calculated, should display the _minimum amount of
available free space_, with "free space" being _usable by user files_.
If I start copying a 12.0GB file onto the file system exemplified above,
I most assuredly _don't_ want to get a report of "device full" after 10
GB! ("You mating female dog, you told me I had 12.3 GB free, wrote 10 GB
and now you're saying there's NO free space?! To hell with this, I'm
switching to Windows!") That also saves this tool from having to take
into account possible compression ratios for when file system level
compression is enabled, savings from possible deduplication of data, etc
etc. Of course it also means that the amount of free space may shrink by
less than the size of the added data, but hey, that's a nice bonus if
your disk grows bigger as you add more data to it. :-)
> I suggest cutting out the /dev and putting a line break after the
> name. The extra info makes it more human-friendly, and the line
> break may complicate machine parsing but the non-tabular format is
> better at that anyway.
That might work well for anything under /dev, but what about things that
aren't? And I stand by my earlier position that the tabular data
shouldn't be machine-parsed anyway. As you say, the non-tabular format
is better for that.
--
Michael Kjörling • http://michael.kjorling.se • mich...@kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
