From: Arne Jansen <sensille@gmx.net>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC] Subvolume Quota on-disk structures and configuration
Date: Mon, 21 Nov 2011 18:20:07 +0100 [thread overview]
Message-ID: <4ECA8847.2080905@gmx.net> (raw)
In-Reply-To: <4ECA7721.3040607@cfl.rr.com>
On 11/21/2011 05:06 PM, Phillip Susi wrote:
> On 7/10/2011 4:21 AM, Arne Jansen wrote:
>> btrfs qgroup limit [--exclusive] <size>|none <qgroupid> <path>
>>
>>
>> btrfs qgroup limit 10g /usr
>>
>> That should be simple enough for the common use case.
>
> Wouldn't that make the syntax above actually be:
>
> btrfs qgroup limit [--exclusive] <size|none> [qgroupid] <path>
You don't mean to actually changing the syntax, but adding a better
explanation or a more precise usage?
>
> Since the qgroupid is optional? And the meaning of path depends on
> whether or not qgroupid is specified. With qgroupid, path is anywhere
> on the fs, but without it, it specifies the path of the implicit
> qgroupid, right?
>
> I also have a question about the interactions with groups of groups. Say
> I have 4 subvolumes: 1, 2, 3, and Z. I group the first 3 volumes and
> set a limit on them. Now if all 3 volumes share a chunk of space, that
> space should only count towards the group once, rather than 3 times.
It's just what groups are made for. In your scenario the chunk of space
would count only once. Some hopefully better explanation can be found at
http://sensille.com/qgroups.pdf
Have you already played with the patchset?
-Arne
> You might think the solution to that is to use the exclusive limits, but
> that would mean that any space volume 3 and volume Z share would not be
> counted in the group at all. I don't care about volume Z since it is
> not part of the group, yet it can influence the used space of the
> group. Likewise, if I set an exclusive limit on the group, and then
> create snapshot Y from subvol 2, that would significantly reduce the
> exclusive charge for the group, and we don't want that.
> --
> 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:[~2011-11-21 17:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-10 8:21 [RFC] Subvolume Quota on-disk structures and configuration Arne Jansen
2011-08-24 7:26 ` Yeh
2011-08-24 7:53 ` Arne Jansen
2011-11-21 16:06 ` Phillip Susi
2011-11-21 17:20 ` Arne Jansen [this message]
2011-11-21 18:29 ` Phillip Susi
[not found] ` <4ECA9DBF.40104@gmx.net>
2011-11-21 20:15 ` Arne Jansen
2011-11-22 15:04 ` Phillip Susi
2011-11-22 15:07 ` Hugo Mills
2011-11-26 4:14 ` Phillip Susi
2011-12-01 9:15 ` Arne Jansen
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=4ECA8847.2080905@gmx.net \
--to=sensille@gmx.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=psusi@cfl.rr.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.