Re: (renamed thread) btrfs metrics, free space reporting

[Daniel Pocock <daniel@pocock.pro>]

On 05/01/12 11:09, Daniel Pocock wrote:
> 
>>
>> From there on, one could potentially create a matrix: (proportional
>> font art, apologies):
>>
>>           | subvol1  | subvol2  | subvol3  |
>> ----------+----------+----------+----------+
>>  subvol1  |   200M   |     20M  |     50M  |
>> ----------+----------+----------+----------+
>>  subvol2  |    20M   |    350M  |     22M  |
>> ----------+----------+----------+----------+
>>  subvol3  |    50M   |     22M  |    634M  |
>> ----------+----------+----------+----------+
>>
>> The diagonal obviously shows the "unique" blocks, subvol2 and subvol1
>> share 20M data, etc. Missing from this plot would be "how much is
>> shared between subvol1, subvol2, and subvol3" together, but it's a
>> start and not something that hard to understand. One might add a
>> column for "total size" of each subvol, which may obviously not be an
>> addition of the rest of the columns in this diagram.
>>
>> Anyway, something like this would be high on my list of `df` numbers
>> I'd like to see - since I think they are useful numbers.
>>
> 
> This is an interesting way to look at it
> 
> Ganglia typically records time series data, it is quite conceivable to
> create a metric for every permutation in each and store that in rrdtool
> 
> The challenge would then be in reporting on the data: the rrdtool graphs
> use time as an X-axis, and then it can display multiple Y values
> 
> However, now that I've started thinking about the type of data generated
> from btrfs, I was wondering if some kind of rr3dtool is needed - a 3D
> graphing solution - or potentially making graphs that do not include
> time on any axis?
> 
> Has anyone seen anything similar for administering ZFS, for example?
> 


I just wanted to follow up on this and see if anybody had any more
comments or if the situation has changed?

One other thing that came to mind for me is the idea of letting the
local system administrator define views (similar to views in SQL) and
also nominate which of the views should be used to return values for the
standard df command.

This would allow existing monitoring tools and scripts to continue
getting some data that is considered sensible for a specific context.