From: Christoph Hellwig <hch@infradead.org>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, jack@suse.cz
Subject: Re: [PATCH 4/4] quota: add generic subtree quota support
Date: Tue, 16 Feb 2010 04:03:37 -0500 [thread overview]
Message-ID: <20100216090337.GA9837@infradead.org> (raw)
In-Reply-To: <877hqdv9rn.fsf@openvz.org>
On Tue, Feb 16, 2010 at 11:56:44AM +0300, Dmitry Monakhov wrote:
> what do you mean by "slightly limited" ?
> I dont now xfs project-id feature very well.
> I cant find good explanation of this feature(except man pages).
> Can you please post main design assumptions.
The only difference from your subtree quota is that multiple subtrees
can belong to a project.
XFS project quotas work the following way:
- an inode can be marked as belonging to a project, in which case a
32bit project ID is stored in the inode
- a flag on the inode is set to inherit the project ID
- adding links from outside the subtree is not allowed
quota uses the project ID for accounting, similar to the user/group id.
One other small difference is that going over the project quota does
not return EDQUOT but ENOSPC.
> In fact i use get_id in order to support second-level quota feature
> *Second-level quota*
> In order to isolate user/group quota in one subtree from other subtree
> we have to remap quota id similar to:
> quota_uid = (subtree_id << 32) | uid;
> > And yes, fs-specific quota interfaces are an utter nightmare, speaking
> > as the person fixing all this crap up right now.
> I've prepare patches against ext4 because:
It's perfectly fine to impement it for one filesystem, the important bit
is to make sure we have consistant interfaces for it in generic code.
I don't think having a get_id callback to allow fs-specific mappings is
a good idea for that.
next prev parent reply other threads:[~2010-02-16 9:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-16 5:31 [PATCH 0/4] quota: RFC add extend quota type v2 Dmitry Monakhov
2010-02-16 5:31 ` [PATCH 1/4] quota: sb_quota state flags cleanup Dmitry Monakhov
2010-02-16 5:31 ` [PATCH 2/4] quota: generalize quota transfer interface Dmitry Monakhov
2010-02-16 5:31 ` [PATCH 3/4] introduce get_id callback Dmitry Monakhov
2010-02-16 5:31 ` [PATCH 4/4] quota: add generic subtree quota support Dmitry Monakhov
2010-02-16 8:14 ` Christoph Hellwig
2010-02-16 8:25 ` Dmitry Monakhov
2010-02-16 8:28 ` Christoph Hellwig
2010-02-16 8:56 ` Dmitry Monakhov
2010-02-16 9:03 ` Christoph Hellwig [this message]
2010-02-16 21:13 ` [PATCH 0/4] quota: RFC add extend quota type v2 Jan Kara
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=20100216090337.GA9837@infradead.org \
--to=hch@infradead.org \
--cc=dmonakhov@openvz.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@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).