From: Pavel Emelyanov <xemul@openvz.org>
To: Jan Kara <jack@suse.cz>
Cc: Andreas Dilger <adilger@sun.com>, "Theodore Ts'o" <tytso@mit.edu>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ext4@vger.kernel.org,
Dmitri Monakhov <dmonakhov@openvz.org>
Subject: Re: [PATCH] A request to reserve a "tree id" field on ext[34] inodes
Date: Tue, 17 Nov 2009 20:55:57 +0300 [thread overview]
Message-ID: <4B02E3AD.3090904@openvz.org> (raw)
In-Reply-To: <20091117171226.GC1923@atrey.karlin.mff.cuni.cz>
Jan Kara wrote:
> Hi,
>
>> We have a proposal to implement a 2-level disk quota on ext3 and ext4.
>>
>> In two words - the aim is to have directories on ext3/4 partitions
>> which are limited by its disk usage and the number of inodes. Further
>> the plan is to allow configuring uid and gid quotas within them.
> If I understand it right, this is something like XFS's project quota,
> right?
Not exactly. XFS tree quota actually replaces gid one. My proposal is
to add the 3rd id.
> Note that such thing has implications such as you have to forbid
> hardlinks between different "quota trees", otherwise it just won't fly...
Yes, I know it. We know other things we'll have to disable, but this is
OK to live without them.
> Also by 2-level, you mean it won't be possible to nest such subtrees?
As I see it - nesting can be done on top of it. I mean - once we have
a tree id of an inode and if we say "id A is a sub-id of id B" we're done.
As far as containers are concerned - we'll have to map container id to
quota tree id, since changing a container id is fast and simple, but
it's not so for tree id. That said, this treeid is just a way do distinguish
inodes from one sub-tree from the others.
> I.e. have a quota on directories a/, b/, a/b, a/c?
>
>> The main usage of this is containers. When two or more of them are
>> located on one disk their roots will be marked with a unique tree id
>> and thus the disk consumption of each container will be limited. While
>> achieving this goal having an id of what tree an inode belongs to is
>> a key requirement.
>>
>> So first we would like to ask to reserve a place on ext3 and ext4 inodes
>> for that ID.
> Do you really need to store tree ID on disk? I'd think that it should
> be enough to keep some id / pointer in memory and initialize it when we
> load inode into memory (from an id / pointer of parent directory). Then
> it would be enough to store a fact that some directory is a root of
> "quota tree" somewhere - either in extended attributes, as a flag in
> the inode, or together with quota data.
We can't do it inside ext4_nfs_get_inode unfortunately :(
> Honza
next prev parent reply other threads:[~2009-11-17 17:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 14:04 [PATCH] A request to reserve a "tree id" field on ext[34] inodes Pavel Emelyanov
2009-11-17 17:06 ` Andreas Dilger
2009-11-17 21:19 ` Dmitry Monakhov
2009-11-18 17:43 ` Dmitry Monakhov
2009-11-19 6:33 ` Andreas Dilger
2009-11-17 17:12 ` Jan Kara
2009-11-17 17:55 ` Pavel Emelyanov [this message]
2009-11-17 18:47 ` Jan Kara
2009-11-17 21:19 ` Dmitry Monakhov
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=4B02E3AD.3090904@openvz.org \
--to=xemul@openvz.org \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=dmonakhov@openvz.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.