From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Daniel Pocock <daniel@pocock.pro>,
"Kok, Auke-jan H" <auke-jan.h.kok@intel.com>
Cc: Hugo Mills <hugo@carfax.org.uk>, cwillu <cwillu@cwillu.com>,
<linux-btrfs@vger.kernel.org>
Subject: Re: (renamed thread) btrfs metrics, free space reporting
Date: Mon, 31 Aug 2015 10:03:16 +0800 [thread overview]
Message-ID: <55E3B5E4.1060106@cn.fujitsu.com> (raw)
In-Reply-To: <55E2F791.80008@pocock.pro>
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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2015-08-31 2:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-02 14:29 btrfs-tools in Debian squeeze-backports? Daniel Pocock
2012-01-02 14:43 ` Hugo Mills
2012-01-02 14:55 ` cwillu
2012-01-02 15:01 ` Daniel Pocock
2012-01-02 15:14 ` Hugo Mills
2012-01-02 16:25 ` (renamed thread) btrfs metrics Daniel Pocock
2012-01-02 16:39 ` Hugo Mills
2012-01-04 11:48 ` Daniel Pocock
2012-01-04 18:46 ` Kok, Auke-jan H
2012-01-05 10:09 ` Daniel Pocock
2015-08-30 12:31 ` (renamed thread) btrfs metrics, free space reporting Daniel Pocock
2015-08-31 2:03 ` Qu Wenruo [this message]
2012-01-04 18:05 ` btrfs-tools in Debian squeeze-backports? Jan Schmidt
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=55E3B5E4.1060106@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=auke-jan.h.kok@intel.com \
--cc=cwillu@cwillu.com \
--cc=daniel@pocock.pro \
--cc=hugo@carfax.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).