Daniel Pocock wrote on 2015/08/30 14:31 +0200:
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.
The matrix seems intersting.
But have you guys tried qgroups?
That will do the thing for you and it should be more flex than you
imagination.
For your use case, qgroup should be quite stable after v4.2-rc1, as you
only want to see how much unique/shared extents between subvolumes.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
