From: Arne Jansen <sensille@gmx.net>
To: Yeh <ykwan0201@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [RFC] Subvolume Quota on-disk structures and configuration
Date: Wed, 24 Aug 2011 09:53:42 +0200 [thread overview]
Message-ID: <4E54AE06.8060109@gmx.net> (raw)
In-Reply-To: <loom.20110824T083328-979@post.gmane.org>
On 24.08.2011 09:26, Yeh wrote:
> Arne Jansen <sensille <at> gmx.net> writes:
>
>>
>> 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.
>>
>> -Arne
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo <at> vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
> Hello Arne,
>
> There are some discussion in mailling list topic "What to do about subvolumes".
> It is copy-on-write quota counting.
> One is charged the quota as physical blocks count.
> Another is charged as how much the user looks like.
> Both of them have different limitation.
> What solution would you use?
I have written an earlier mail to sketch out what I intend to implement. I
don't quite understand the 2 counting methods you refer to, but maybe that
earlier mails helps (Subject: Quota Implementation). If not, I can try to
describe in more detail what I implement. Most probably it will meet your
need, unless you expect user quota :)
>
> The topic you mentioned is what I need. How is your btrfs quota implementation
> progress? You could release your patch for me if possible, I can join your idea,
> design and implementation. I have large disk array for testing.
>
Still fighting against delayed refs... it might take a few weeks until I have
the first reasonably stable and cleaned-up version.
-Arne
> Best regards,
> Yeh.
>
>
> --
> 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-08-24 7:53 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 [this message]
2011-11-21 16:06 ` Phillip Susi
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=4E54AE06.8060109@gmx.net \
--to=sensille@gmx.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=ykwan0201@gmail.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.