From: Phillip Susi <psusi@cfl.rr.com>
To: Arne Jansen <sensille@gmx.net>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC] Subvolume Quota on-disk structures and configuration
Date: Mon, 21 Nov 2011 11:06:57 -0500 [thread overview]
Message-ID: <4ECA7721.3040607@cfl.rr.com> (raw)
In-Reply-To: <4E19611D.2090007@gmx.net>
On 7/10/2011 4:21 AM, Arne Jansen wrote:
> btrfs qgroup limit [--exclusive] <size>|none <qgroupid> <path>
>
> This sets actual limits on a qgroup. If --exclusive is given, the
> exclusive usage is limited instead of the referenced. I don't know
> if there are use cases where both values need a (possibly different)
> limit. <path> means the path to the root. Instead of "<qgroupid>
> <path>", a path to a subvolume can be given instead.
>
> btrfs qgroup create <qgroupid> <path>
> btrfs qgroup destroy <qgroupid> <path>
> btrfs qgroup assign <childid> <parentid> <path>
> btrfs qgroup remove <childid> <parentid> <path>
>
> These 4 commands are used to build hierarchical qgroups and are only
> for advanced users. I'll explain more of the concepts in a later
> paper.
>
> The main point here is that in the simplest case, a user creates a
> filesystem with initial quota support, creates his /var /usr /home
> etc. subvolumes and limits them with commands like
>
> 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>
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. 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.
next prev parent reply other threads:[~2011-11-21 16:06 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 [this message]
2011-11-21 17:20 ` Arne Jansen
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=4ECA7721.3040607@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sensille@gmx.net \
/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).