Message-ID: <20140128064248.GA8653@gmail.com>
Date:	Tue, 28 Jan 2014 14:42:49 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	linux-ext4 <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>, xfs@....sgi.com
Cc:	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Jan Kara <jack@...e.cz>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	Li Xi <pkuelelixi@...il.com>,
	Dave Chinner <david@...morbit.com>, Ben Myers <bpm@....com>
Subject: [RFC] A draft for making ext4 support project quota

Hi all,

Here is a draft about ext4 project quota.  After discussed in another
thread [1], I believe that we have reached a consensus for supporting
project quota in ext4 and keep consistency with xfs.  Thus I write this
draft.  As always, comments, suggestions and ideas are welcome.

1. http://www.spinics.net/lists/linux-ext4/msg41275.html

                   Ext4 Project Quota (ver. 0.10)

Goal
====

The goal is to make ext4 support project quota which keeps the same
behaviour with xfs.  After adding this new feature, we can support
directory quota based on it.

Background
==========

The project quota is a quota mechanism can be used to implement a form
of directory tree quota, where a specified directory and all of the
files and subdirectories below it (i.e. a tree) can be restricted to
using a subset of the available space in the filesystem [2].

*Note*
Project quota is not directory quota.  Project quota is an aggregation
of unrelated inodes with the same id (e.g. project id).  That means that
some directories without the common parent directory could have the same
id and are accounted as the same quota.

Currently xfs has supported project quota several years, and has a mature
interface to manage project quota on kernel and userspace side.  After
discusstion we believe that we should use the same quota API for project
quota on ext4.  Now xfs_quota (userspace tool for managing xfs quota) is
used to get/set/check project id, which communicates with kernel via
ioctl(2).  For quota management, xfs_quota uses Q_X* via quotactl(2) to
manipulate quota.  A XFS_DIFLAG_PROJINHERIT flag is defined in xfs to
mark a directory that new file and direcotry created in this directory
will get marked with this flag.

For project quota, the key issue is how to handle link(2)/rename(2).  We
summarize the behaviour in xfs as following.

*Note*
+ unaccounted dir
x accounted dir

link(2)
-------
		+		x
+		ok		error (EXDEV)
x		ok		error (EXDEV)

rename(2)
---------
		+		x
+		ok		ok
x		wrong		ok

Further, project quota *cannot* be used with group quota at the same time.
On the other hand user quota and project quota can be used simultaneously.

2. http://xfs.org/index.php/XFS_FAQ#Q:_Quota:_What.27s_project_quota.3F

Design
======

Project id
----------
We have two options to store project id in inode.  a) define a new member
in ext4_inode structure; b) store project id in xattr.

Option a)
Pros:
  * Only need 4 bytes if we use a '__le32' type to store it

Cons:
  * Needs to change disk layout of ext4 inode

Option b)
Pros:
  * Don't need to change disk layout

Cons:
  * Take 24 bytes

Here I propose to use option *b)* because it is easy for us to support
project id and we don't need to worry about changing disk layout.  But
I raise another issue here.  Now inline_data feature has been applied.
After waiting inline_data feature stable, we'd better enable inline_data
feature by default when we create a new ext4 file system.  Now the inode
size is 256 bytes by default, we have 72 bytes extra size to store
inline data:
  256 (default inode size) -
	156 (ext4_inode) + 4 (ext4_xattr_ibody_header) +
	20 (ext4_xattr_entry) + 4 (value) = 72

If we store project id in xattr, we just leave 48 bytes for inline data.
I am not sure whether or not it is too small for some users.

When we store project id in xattr, we will use {get,set}fattr to get/set
project id.  Thus we don't need to change userspace tool to manipulate
project id.  Meanwhile a _INHERENT flag for inode needs to be defined to
indicate that new directory creating in a directory with this flag will
get the same project id and get marked with this flag.  

Project quota API
-----------------
For keeping consistency with xfs, here I propose to use Q_X* flag to
communicate with kernel via quotactl(2) as we discussed.  Due to this we
need to define some callback functions to support Q_X* flag.  That means
that ext4 will support two quota flag sets for being compatible with
legacy userspace tools and use the same quotactl API to communicate with
kernel for project id like xfs.

Currently quota subsystem in vfs doesn't handle project quota.  Thus we
need to make quota subsystem handle project id properly (e.g.
dquot_transfer, dquot_initialize).  We need to define a new callback
function in order to get project id.  Now in vfs we can access uid/gid
directly from inode, but we have no way to get project id.  A generic
callback function is defined to handle uid/gid.  The file system itself
can handle project id.  Until now only ext4 needs to implement this
callback function by itself because xfs doesn't use vfs quota subsystem.

For handling link(2)/rename(2) like xfs, we only allow hard link or
rename operation when the project ids are the same.  Otherwise we will
return EXDEV error to notify the user.

Quota-tools
-----------
Now quota-tools (e.g. quotaon, edquota, etc...) don't support project
quota.  Thus we need to make it support project id.  I believe that Li
Xi did some works on quota-tools.

E2fsprogs
---------
After supporting project quota, we need to change e2fsck(1) to make sure
that all sub-directories with _INHERENT flag have the same project id.
Meanwhile we need to make chattr(1) set/clear _INHERENT flag.

Regards,
						- Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists