On Fri, 02 Nov 2012 21:46:35 +0000, Michael Kjörling wrote:
> 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.00GB 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?
It does save a line.
> 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.
Good idea.
> 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.
Feh, that's just a typo from when I swapped the 8.00M to the left.
> 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.
I tried to work out DUP vs RAID redundancy in my message to Hugo.
> 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 think we can guarantee minimum amounts of free space, as long as
data/metadata/system are segregated properly?
OK, reshapes complicate this. For those we could to take the worst
case between now and the completed reshape.
Or maybe add a second tally:
devices
===
total
reserved
used
free
===
anticipated (reshaped 8% eta 3:12)
reserved
used
free
>> 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?
Absolute path for those, assuming it ever happens.
> 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.
--
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
