The following patches propose an implementation of project quota
support for ext4. A project is an aggregate of unrelated inodes
which might scatter in different directories. Inodes belongs to a
project possesses a same identification i.e. 'project ID', just
like every inode has its user/group identification. The following
patches adds project quota as supplement to the former uer/group
quota types.
The semantics of ext4 project quota is consistent with XFS. Each
directory can have EXT4_INODE_PROJINHERIT flag set. When the
EXT4_INODE_PROJINHERIT flag of a parent directory is not set, a
newly created inode under that directory will have a default project
ID (i.e. 0). And its EXT4_INODE_PROJINHERIT flag is not set either.
When this flag is set on a directory, following rules will be kept:
1) The newly created inode under that directory will inherit both
the EXT4_INODE_PROJINHERIT flag and the project ID from its parent
directory.
2) Hard-linking a inode with different project ID into that directory
will fail with errno EXDEV.
3) Renaming a inode with different project ID into that directory
will fail with errno EXDEV. However, 'mv' command will detect this
failure and copy the renamed inode to a new inode in the directory.
Thus, this new inode will inherit both the project ID and
EXT4_INODE_PROJINHERIT flag.
4) If the project quota of that ID is being enforced, statfs() on
that directory will take the quotas as another upper limits along
with the capacity of the file system, i.e. the total block/inode
number will be the minimum of the quota limits and file system
capacity.
Changelog:
* v4 <- v3:
- Do not check project feature when set/get project ID;
- Use EXT4_MAXQUOTAS instead of MAXQUOTAS in ext4 patches;
- Remove unnecessary change of fs/quota/dquot.c;
- Remove CONFIG_QUOTA_PROJECT.
* v3 <- v2:
- Add EXT4_INODE_PROJINHERIT semantics.
* v2 <- v1:
- Add ioctl interface for setting/getting project;
- Add EXT4_FEATURE_RO_COMPAT_PROJECT;
- Add get_projid() method in struct dquot_operations;
- Add error check of ext4_inode_projid_set/get().
v3: http://www.spinics.net/lists/linux-ext4/msg45184.html
v2: http://www.spinics.net/lists/linux-ext4/msg44695.html
v1: http://article.gmane.org/gmane.comp.file-systems.ext4/45153
Any comments or feedbacks are appreciated.
Regards,
- Li Xi
Li Xi(4):
quota: Adds general codes to enforces project quota limits
ext4: Adds project ID support for ext4
ext4: Adds project quota support for ext4
ext4: Adds ioctl interface support for ext4 project
Documentation/filesystems/ext4.txt | 4 +
fs/ext4/ext4.h | 31 +++++++--
fs/ext4/ialloc.c | 6 ++
fs/ext4/inode.c | 29 ++++++++-
fs/ext4/ioctl.c | 85 ++++++++++++++++++++++++
fs/ext4/namei.c | 10 +++
fs/ext4/super.c | 124 ++++++++++++++++++++++++++++++++---
fs/quota/dquot.c | 16 ++++-
fs/quota/quota.c | 5 +-
fs/quota/quotaio_v2.h | 6 +-
include/linux/quota.h | 2 +
include/uapi/linux/quota.h | 6 +-
12 files changed, 299 insertions(+), 25 deletions(-)
On Wed 24-09-14 20:14:35, Li Xi wrote:
> The following patches propose an implementation of project quota
> support for ext4. A project is an aggregate of unrelated inodes
> which might scatter in different directories. Inodes belongs to a
> project possesses a same identification i.e. 'project ID', just
> like every inode has its user/group identification. The following
> patches adds project quota as supplement to the former uer/group
> quota types.
>
> The semantics of ext4 project quota is consistent with XFS. Each
> directory can have EXT4_INODE_PROJINHERIT flag set. When the
> EXT4_INODE_PROJINHERIT flag of a parent directory is not set, a
> newly created inode under that directory will have a default project
> ID (i.e. 0). And its EXT4_INODE_PROJINHERIT flag is not set either.
> When this flag is set on a directory, following rules will be kept:
>
> 1) The newly created inode under that directory will inherit both
> the EXT4_INODE_PROJINHERIT flag and the project ID from its parent
> directory.
>
> 2) Hard-linking a inode with different project ID into that directory
> will fail with errno EXDEV.
>
> 3) Renaming a inode with different project ID into that directory
> will fail with errno EXDEV. However, 'mv' command will detect this
> failure and copy the renamed inode to a new inode in the directory.
> Thus, this new inode will inherit both the project ID and
> EXT4_INODE_PROJINHERIT flag.
>
> 4) If the project quota of that ID is being enforced, statfs() on
> that directory will take the quotas as another upper limits along
> with the capacity of the file system, i.e. the total block/inode
> number will be the minimum of the quota limits and file system
> capacity.
>
> Changelog:
> * v4 <- v3:
> - Do not check project feature when set/get project ID;
> - Use EXT4_MAXQUOTAS instead of MAXQUOTAS in ext4 patches;
> - Remove unnecessary change of fs/quota/dquot.c;
> - Remove CONFIG_QUOTA_PROJECT.
> * v3 <- v2:
> - Add EXT4_INODE_PROJINHERIT semantics.
> * v2 <- v1:
> - Add ioctl interface for setting/getting project;
> - Add EXT4_FEATURE_RO_COMPAT_PROJECT;
> - Add get_projid() method in struct dquot_operations;
> - Add error check of ext4_inode_projid_set/get().
>
> v3: http://www.spinics.net/lists/linux-ext4/msg45184.html
> v2: http://www.spinics.net/lists/linux-ext4/msg44695.html
> v1: http://article.gmane.org/gmane.comp.file-systems.ext4/45153
>
> Any comments or feedbacks are appreciated.
Whitespace got mangled in your patches so much they are hardly readable.
Please resend them so that it is properly preserved. I'm not sure how other
guys using gmail do this so you might need to ask them... Thanks!
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Wed, Sep 24, 2014 at 02:52:06PM +0200, Jan Kara wrote:
> Whitespace got mangled in your patches so much they are hardly readable.
> Please resend them so that it is properly preserved. I'm not sure how other
> guys using gmail do this so you might need to ask them... Thanks!
And it would be nice if they are chained together so that people with
proper mail-threading readers can easily find all of your patches.
Probably the best way to do this is to configure your a local mail
transfer agent on your Linux desktop/laptop, and configure it to use
smart mail-router with authenticated SMTP to:
Host: smtp.gmail.com
Port: 465
Authentication: Yes
Username: #YOU#@gmail.com
Password: #YOUR_PASSWORD#
Security: SSL
Then use "git send-email" to post your patches, and it should all be
good.
(I'm guessing your cutting and pasting your patches into the mail send
window, and that unfortunately tends not to work well.)
Cheers,
- Ted
On Wed, Sep 24, 2014 at 11:42:39AM -0400, Theodore Ts'o wrote:
> On Wed, Sep 24, 2014 at 02:52:06PM +0200, Jan Kara wrote:
> > Whitespace got mangled in your patches so much they are hardly readable.
> > Please resend them so that it is properly preserved. I'm not sure how other
> > guys using gmail do this so you might need to ask them... Thanks!
>
> And it would be nice if they are chained together so that people with
> proper mail-threading readers can easily find all of your patches.
>
> Probably the best way to do this is to configure your a local mail
> transfer agent on your Linux desktop/laptop, and configure it to use
> smart mail-router with authenticated SMTP to:
>
> Host: smtp.gmail.com
> Port: 465
> Authentication: Yes
> Username: #YOU#@gmail.com
> Password: #YOUR_PASSWORD#
> Security: SSL
>
> Then use "git send-email" to post your patches, and it should all be
> good.
>
> (I'm guessing your cutting and pasting your patches into the mail send
> window, and that unfortunately tends not to work well.)
>
> Cheers,
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Li Xi,
You can set up Mutt (likely Alpine, maybe others) to work with GMail, if
you want to; I believe it handles whitespace and patch series well by
default. There are relevant resources online to assist with the
configuration, if you need them. It also includes an SMTP feature, if you
want to make use of it.
Cheers,
Nikitas
On Wed, Sep 24, 2014 at 11:42 PM, Theodore Ts'o <[email protected]> wrote:
> On Wed, Sep 24, 2014 at 02:52:06PM +0200, Jan Kara wrote:
>> Whitespace got mangled in your patches so much they are hardly readable.
>> Please resend them so that it is properly preserved. I'm not sure how other
>> guys using gmail do this so you might need to ask them... Thanks!
>
> And it would be nice if they are chained together so that people with
> proper mail-threading readers can easily find all of your patches.
>
> Probably the best way to do this is to configure your a local mail
> transfer agent on your Linux desktop/laptop, and configure it to use
> smart mail-router with authenticated SMTP to:
>
> Host: smtp.gmail.com
> Port: 465
> Authentication: Yes
> Username: #YOU#@gmail.com
> Password: #YOUR_PASSWORD#
> Security: SSL
>
> Then use "git send-email" to post your patches, and it should all be
> good.
>
> (I'm guessing your cutting and pasting your patches into the mail send
> window, and that unfortunately tends not to work well.)
Thank you very much for the help. And sorry for the mistakes I've made.
That is too many times even for a newbie. Hopefully, I won't make any
mistake with 'git send-email' in the next version. :)
Regards,
Li Xi
On Thu, Sep 25, 2014 at 6:27 AM, Nikitas Angelinas
<[email protected]> wrote:
> On Wed, Sep 24, 2014 at 11:42:39AM -0400, Theodore Ts'o wrote:
>> On Wed, Sep 24, 2014 at 02:52:06PM +0200, Jan Kara wrote:
>> > Whitespace got mangled in your patches so much they are hardly readable.
>> > Please resend them so that it is properly preserved. I'm not sure how other
>> > guys using gmail do this so you might need to ask them... Thanks!
>>
>> And it would be nice if they are chained together so that people with
>> proper mail-threading readers can easily find all of your patches.
>>
>> Probably the best way to do this is to configure your a local mail
>> transfer agent on your Linux desktop/laptop, and configure it to use
>> smart mail-router with authenticated SMTP to:
>>
>> Host: smtp.gmail.com
>> Port: 465
>> Authentication: Yes
>> Username: #YOU#@gmail.com
>> Password: #YOUR_PASSWORD#
>> Security: SSL
>>
>> Then use "git send-email" to post your patches, and it should all be
>> good.
>>
>> (I'm guessing your cutting and pasting your patches into the mail send
>> window, and that unfortunately tends not to work well.)
>>
>> Cheers,
>>
>> - Ted
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-api" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Li Xi,
>
>
> You can set up Mutt (likely Alpine, maybe others) to work with GMail, if
> you want to; I believe it handles whitespace and patch series well by
> default. There are relevant resources online to assist with the
> configuration, if you need them. It also includes an SMTP feature, if you
> want to make use of it.
Hi Nikitas,
Thank you! I will try that too.
Regards,
Li Xi