Project Quota on ZFS #6290

Nasf-Fan · 2017-06-30T06:31:15Z

Project quota is a new ZFS system space/object usage accounting
and enforcement mechanism. Similar as user/group quota, project
quota is another dimension of system quota. It bases on the new
object attribute - project ID.

Project ID is a numerical value to indicate to which project an
object belongs. An object only can belong to one project though
you (the object owner or privileged user) can change the object
project ID that can be set/modified via 'chattr -p' explicitly,
or inherited from its parent object when created if such parent
has the project inherit flag (via 'chattr +P').

By accounting the spaces/objects belong to the same project, we
can know how many spaces/objects used by the project. And if we
set the upper limit then we can control the spaces/objects that
are consumed by such project. It is useful when multiple groups
and users cooperate for the same project, or when an user/group
needs to participate in multiple projects.

Support the following commands and functionalities:

zfs set projectquota@project
zfs set projectobjquota@project

zfs get projectquota@project
zfs get projectobjquota@project
zfs get projectused@project
zfs get projectobjused@project

zfs projectspace

zfs allow projectquota
zfs allow projectobjquota
zfs allow projectused
zfs allow projectobjused

zfs unallow projectquota
zfs unallow projectobjquota
zfs unallow projectused
zfs unallow projectobjused

chattr +/-P
chattr -p project_id
lsattr -p

Signed-off-by: Fan Yong fan.yong@intel.com
Change-Id: Ib4f0544602e03fb61fd46a849d7ba51a6005693c

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Performance enhancement (non-breaking change which improves efficiency)
Code cleanup (non-breaking change which makes code smaller or more readable)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation (a change to man pages or other documentation)

Checklist:

My code follows the ZFS on Linux code style requirements.
I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.
All commit messages are properly formatted and contain Signed-off-by.
Change has been approved by a ZFS on Linux member.

mention-bot · 2017-06-30T06:31:26Z

@Nasf-Fan, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @ahrens and @tuxoko to be potential reviewers.

jxiong · 2017-06-30T15:56:57Z

@Nasf-Fan the patched failed zfstests as follows:

11:13:04.61 Badly formed zdb parameters fail as expected.
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zdb/zdb_002_pos (run as root) [10:00] [KILLED]
11:13:04.63 ASSERTION: Verify zdb accurately counts feature refcounts.
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zdb/zdb_003_pos (run as root) [10:00] [KILLED]
11:23:04.64 ASSERTION: Verify zdb does not produce redundant dumps of configurations
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zdb/zdb_004_pos (run as root) [10:00] [KILLED]
11:33:04.66 ASSERTION: Verify zdb produces unique dumps of uberblocks
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zdb/zdb_005_pos (run as root) [10:00] [KILLED]
11:43:04.68 ASSERTION: Verify zdb -l exit codes are correct
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zfs/setup (run as root) [10:00] [KILLED]
11:53:04.69 NOTE: begin default_setup_noexit
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zfs/zfs_001_neg (run as root) [00:00] [SKIP]
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zfs/zfs_002_pos (run as root) [00:00] [SKIP]
Test: /usr/share/zfs/zfs-tests/tests/functional/cli_root/zfs/zfs_003_neg (run as root) [00:00] [SKIP]

behlendorf · 2017-06-30T17:32:42Z

Link to the console log containing the backtraces from the kmemleak builder.

Nasf-Fan · 2017-07-12T04:46:06Z

@behlendorf
Is there any way to re-trigger the failed test without re-pushing the patch? I noticed that the following test failed because of timeout, but I do not think it is related with my patch, and I cannot reproduce it in my local test environment.

http://build.zfsonlinux.org/builders/Ubuntu%2014.04%20x86_64%20%28TEST%29/builds/6212

Thanks!

ahrens · 2017-07-11T23:19:28Z

cmd/zpool/zpool_main.c

@@ -6995,6 +6995,7 @@ zpool_do_upgrade(int argc, char **argv)
 		(void) printf(gettext(" 27  Improved snapshot creation "
 		    "performance\n"));
 		(void) printf(gettext(" 28  Multiple vdev replacements\n"));
+		(void) printf(gettext(" 29  Project quota\n"));


Use feature flags instead of adding a version number.

ahrens · 2017-07-11T23:20:59Z

include/sys/dmu_objset.h

 	    sizeof (zil_header_t) - sizeof (uint64_t)*2];
 	dnode_phys_t os_userused_dnode;
 	dnode_phys_t os_groupused_dnode;
+	char os_pad1[OBJSET_PHYS_SIZE -OBJSET_PHYS_SIZE_V2 -
+	    sizeof (dnode_phys_t)];


why put the padding here rather than at the end of the struct?

ahrens · 2017-07-11T23:21:36Z

include/sys/dmu_objset.h

+	char os_pad1[OBJSET_PHYS_SIZE -OBJSET_PHYS_SIZE_V2 -
+	    sizeof (dnode_phys_t)];
+	/*
+	 * With os_projectused_dnode_phy introduced, the total


I think the _phy here is not needed.

ahrens · 2017-07-11T23:41:19Z

module/zfs/dmu_objset.c


 	ASSERT(ds == NULL || MUTEX_HELD(&ds->ds_opening_lock));

+	if (spa_version(spa) < SPA_VERSION_USERSPACE)
+		size = OBJSET_PHYS_SIZE_V1;
+	else if (spa_version(spa) < SPA_VERSION_PROJECT_QUOTA)


this will need to be changed to be based on the feature flag.

ahrens · 2017-07-11T23:42:14Z

module/zfs/dmu_objset.c

@@ -410,11 +424,11 @@ dmu_objset_open_impl(spa_t *spa, dsl_dataset_t *ds, blkptr_t *bp,
 		}

 		/* Increase the blocksize if we are permitted. */
-		if (spa_version(spa) >= SPA_VERSION_USERSPACE &&
-		    arc_buf_size(os->os_phys_buf) < sizeof (objset_phys_t)) {
+		if (size > OBJSET_PHYS_SIZE_V1 &&


when is this check needed? I would have thought that arc_buf_size() >= OBJSET_PHYS_SIZE_V1 is always true, so the 2nd check size > arc_buf_size() is sufficient.

ahrens · 2017-07-11T23:53:39Z

module/zfs/dmu_objset.c

-	    SPA_FEATURE_USEROBJ_ACCOUNTING] = B_TRUE;
+	if (dmu_objset_userobjused_enabled(os))
+		dmu_objset_ds(os)->ds_feature_activation_needed[
+		    SPA_FEATURE_USEROBJ_ACCOUNTING] = B_TRUE;


It might not be worth bothering with this. If you're going to automatically do this whenever a fs is mounted, effectively it will work as you described in the manpage - it gets activated immediately and never deactivated. So we might make that technically true as well.

ahrens · 2017-07-11T23:59:14Z

module/zfs/zfeature_common.c

@@ -318,4 +318,15 @@ zpool_feature_init(void)
 	    ZFEATURE_FLAG_READONLY_COMPAT | ZFEATURE_FLAG_PER_DATASET,
 	    userobj_accounting_deps);
 	}
+	{
+	static const spa_feature_t project_quota_deps[] = {
+		SPA_FEATURE_EXTENSIBLE_DATASET,


~~how does this use EXTENSIBLE_DATASET?~~
Saw that you're doing PER_DATASET which requires this.

ahrens · 2017-07-12T00:03:03Z

include/sys/zfs_sa.h

@@ -87,6 +88,8 @@ typedef enum zpl_attr {
 #define	SA_UID_OFFSET		24
 #define	SA_GID_OFFSET		32
 #define	SA_PARENT_OFFSET	40
+#define	SA_FLAGS_OFFSET		48
+#define	SA_PROJID_OFFSET	128


I'm not sure that this is actually a constant, because SA_ZPL_RDEV is conditionally present before it.

Then I will define two OFFSET based on whether SA_ZPL_RDEV exists or not.

Could you instead put the PROJID before RDEV?

Seems good, but maybe more affect on the existing files for upgrade case, is it OK? Then can I move it more close to UID/GID, such as just after flags attribute?

It would be a good idea to keep all the mandatory attrs together (i.e. MODE through LINKS).

If you're asking about zfs_sa_upgrade(), I don't see how it matters if you switch the order of RDEV and PROJID.

OK, I will move the "project ID" attr just ahead of the "rdev".

It looks like this still needs to be addressed.

Follows current user/group quota framework, I have no better idea yet

I think you're saying that you can't follow my suggestion of putting PROJID before RDEV. How does that conflict with the "current user/group quota framework"?

But it looks like you've made the change I suggested, so maybe I've misunderstood? You've put PROJID between LINKS and RDEV. Is its OFFSET still 128 (I don't think so, but I don't see how your code could work if SA_PROJID_OFFSET is inaccurate).

I think we should be aware that there can be exactly one "optional, but fixed location" attribute, and it is PROJID. If another feature wants to do something similar to what you've done, they won't be able to.

I have already put the PROJID just after the LINKS and before the RDEV. The new offset is really 128 as following:

MODE 0
SIZE 8
GEN 16
UID 24
GID 32
PARENT 40
FALGS 48
ATIME 56
MTIME 72
CTIME 88
CRTIME 104
LINKS 120
PROJID 128

I'm still not entirely clear on this. I see that in the zfs_sa_upgrade() case PROJID will be placed after LINKS since sa_replace_all_by_template() preserves the passed order. However, I don't see where this ordering is made the preferred default layout for new filesystems. Can you point me to the code which ensures this is true.

ahrens · 2017-07-12T00:04:18Z

include/sys/zfs_znode.h

@@ -65,6 +65,8 @@ extern "C" {
 #define	ZFS_REPARSE		0x0000080000000000ull
 #define	ZFS_OFFLINE		0x0000100000000000ull
 #define	ZFS_SPARSE		0x0000200000000000ull
+#define	ZFS_PROJINHERIT		0x0000400000000000ull
+#define	ZFS_PROJID		0x0000800000000000ull


since these are new on disk flags, we should also reserve them upstream in illumos so that other projects are less likely to use them for something different. That said, can you explain (possibly in a comment here) what these mean exactly? How is ZFS_PROJID different from the presence of SA_ZPL_PROJID?

OK, I will add comment for the new flags.

ahrens · 2017-07-12T00:07:15Z

module/zfs/zfs_vnops.c

@@ -3563,6 +3652,17 @@ zfs_rename(struct inode *sdip, char *snm, struct inode *tdip, char *tnm,
 	}

 	/*
+	 * If we are using project inheritance, we only allow renames
+	 * into our tree when the project IDs are the same; otherwise
+	 * tree quota mechanism would be circumvented.


What's the tree quota mechanism?

If the ZFS_PROJINHERIT flag in set on the directory object, then we hope that all the children under the directory will belong to the same project, means the same project ID. Based on that if we want to support tree quota, for example, assume we want to limite the space used by the directory, then we can give an unique project ID to the directory and set ZFS_PROJINHERIT flag on it. And then the project quota mechanism will guarantee that.

The comment implies that we don't just "hope" all the children will have the same project, we enforce that they do. Is that a universal requirement - if ZFS_PROJINHERIT is set on a directory, all its descendants must have the same project?

I am not sure whether it is "requirement", but it is useful. In fact, some other filesystem, such as EXT4, has already support "tree quota" like that. Means if the ZFS_PROJINHERIT flag is set on the directory, then all its descendants will inherit its project ID.

I think you're saying that today there is no "tree quota" in ZFS, but we might want to support it someday. When/if we support "tree quota", we will need to enforce that if PROJINHERIT is set, all descendants have the same project.

To make that easier to determine, would we also enforce that if PROJINHERIT is set, all descendant directories also have PROJINHERIT set? That way if we are renaming a directory, if the new parent dir has PROJINHERIT, the dir that we're renaming must have the same PROJID and also have PROJINHERIT set (to ensure that all its descendants also have that projid).

You are right, the current implementation is just as you expected. Means if the directory has PROJINHERIT set, then its descendant directories will inherit not only the project ID, but also the PROJINHERIT flag.

Cool. In that case can you reword this comment, since this restriction (of PROJINHERIT being also force-inherited) applies all the time, not just for the (non-existent) tree quota. It seems like the PROJINHERIT flag is potentially useful even in the absence of tree quota, since it allows you to force a directory and everything below it to be assigned to the same project.

behlendorf · 2017-07-12T18:34:56Z

@Nasf-Fan yes actually, I've resubmitted that test.

Nasf-Fan · 2017-07-13T15:47:29Z

@ahrens
Thanks! I will update the patch as you suggested.

@behlendorf
Thanks for helping re-triggered the tests.

ahrens · 2017-07-13T16:17:16Z

module/zfs/zfs_vnops.c

+			attrzp->z_projid = projid;
+			SA_ADD_BULK_ATTR(xattr_bulk, xattr_count,
+			    SA_ZPL_PROJID(zfsvfs), NULL, &attrzp->z_projid,
+			    sizeof (attrzp->z_projid));


how do you ensure that this lands at SA_PROJID_OFFSET?

Good question!
I need more handle here: if the object has no PROJID flag, then it should be existing file that is not upgraded yet, so we need to handle it as zfs_sa_upgrade() does. Does it work?

I'm not sure, but probably something like that (reformatting the whole SA) would work. You'd need to handle other optional attributes that aren't in the legacy layout.

ahrens · 2017-07-13T16:17:54Z

module/zfs/zfs_vnops.c

+		zp->z_projid = projid;
+		SA_ADD_BULK_ATTR(bulk, count,
+		    SA_ZPL_PROJID(zfsvfs), NULL, &zp->z_projid,
+		    sizeof (zp->z_projid));


how do you ensure that this lands at SA_PROJID_OFFSET?

Has been resolved via sa_add_projid

ahrens · 2017-07-13T16:22:09Z

include/sys/zfs_sa.h

@@ -87,6 +88,8 @@ typedef enum zpl_attr {
 #define	SA_UID_OFFSET		24
 #define	SA_GID_OFFSET		32
 #define	SA_PARENT_OFFSET	40
+#define	SA_FLAGS_OFFSET		48
+#define	SA_PROJID_OFFSET	128


It would be a good idea to keep all the mandatory attrs together (i.e. MODE through LINKS).

If you're asking about zfs_sa_upgrade(), I don't see how it matters if you switch the order of RDEV and PROJID.

Nasf-Fan · 2017-07-22T14:57:39Z

@behlendorf

As you can see, there are still some build/test failures in my latest commit (1 errored, 8 failing, and 15 successful checks). I do not think all of them are caused by my changes. I have checked some other recent patches, similar build/test failures. I suspect that there are some common build/test issues on current ZOL community branch. Is there any ZOL master test/build results that can be used for the comparison? then I can clearly know whether any test failures are special in my patch and need to be further investigated.

Thanks!

behlendorf · 2017-07-25T04:30:04Z

@Nasf-Fan sorry about the recent rash of unrelated test failures. We expect to have largely under control in the next day or so. Then if you rebase on master you should get a cleaner test run. Thanks for your patience!

Nasf-Fan · 2017-07-25T04:40:48Z

@behlendorf

Understood. Thanks!

Nasf-Fan · 2018-01-31T16:14:41Z

ztest failed on CentOS 7 x86_64 and CentOS 7 x86_64 Mainline, but I do not think it is project quota patch caused such trouble.

@behlendorf , would you please to help to re-trigger the two tests? Thanks!

codecov · 2018-02-01T09:26:41Z

Codecov Report

Merging #6290 into master will increase coverage by 0.39%.
The diff coverage is 87.05%.

@@            Coverage Diff             @@
##           master    #6290      +/-   ##
==========================================
+ Coverage   76.13%   76.53%   +0.39%     
==========================================
  Files         324      327       +3     
  Lines      103013   103765     +752     
==========================================
+ Hits        78432    79418     +986     
+ Misses      24581    24347     -234

Flag	Coverage Δ
#kernel	`76.45% <86.26%> (+0.44%)`	⬆️
#user	`66.05% <77.3%> (+0.73%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c03f047...1fa7455. Read the comment docs.

Nasf-Fan · 2018-02-01T11:55:03Z

http://build.zfsonlinux.org/builders/Ubuntu%2017.10%20x86_64%20%28TEST%29/builds/188
zfs_rollback_00{1,2}_pos failed on Ubuntu 17.10 x86_64, seems related with #6415

behlendorf · 2018-02-01T23:24:41Z

@Nasf-Fan resubmitted Ubuntu 17.10, that's a known failure almost certainly due to a flaw in the test case.

Nasf-Fan · 2018-02-02T02:28:00Z

Thanks @behlendorf !
What is the next step for the patch?

behlendorf · 2018-02-02T23:30:47Z

@Nasf-Fan @nedbass @ahrens believe we're ready for a final review.

nedbass · 2018-02-10T00:02:27Z

Looks good to me. I confirmed directory-based xattr issues are fixed. I think we can clean up documentation and UI issues in follow-up patches. If I could suggest one change prior to merging, I'd like zfs project to include the top level directory for the list operation. Something like this:

diff --git a/cmd/zfs/zfs_project.c b/cmd/zfs/zfs_project.c
index 99b4e1a..2510a42 100644
--- a/cmd/zfs/zfs_project.c
+++ b/cmd/zfs/zfs_project.c
@@ -277,9 +277,12 @@ zfs_project_handle(const char *name, zfs_project_control_t *zpc)
        zpc->zpc_ignore_noent = B_FALSE;
        if (zpc->zpc_op == ZFS_PROJECT_OP_SET ||
            zpc->zpc_op == ZFS_PROJECT_OP_CLEAR ||
-           !S_ISDIR(st.st_mode) || zpc->zpc_dironly) {
+           zpc->zpc_op == ZFS_PROJECT_OP_LIST) {
                ret = zfs_project_handle_one(name, zpc);
-               if (ret || !zpc->zpc_recursive)
+               if (ret ||
+                   (!S_ISDIR(st.st_mode) || zpc->zpc_dironly) ||
+                   (!zpc->zpc_recursive &&
+                   (zpc->zpc_op != ZFS_PROJECT_OP_LIST)))
                        return (ret);
        }

Nasf-Fan · 2018-02-12T14:18:59Z

Update the patch as nedbass suggested and resolve merge conflict issues.

nedbass · 2018-02-12T19:41:24Z

Update the patch as nedbass suggested and resolve merge conflict issues.

@Nasf-Fan with your latest change, zfs project -c no longer checks directory contents by default.

behlendorf

This worked as expected for me in my local testing. If you can address the few nits I mentioned and the issue @nedbass found then this should be good to go. Thanks!

behlendorf · 2018-02-12T22:51:46Z

cmd/zfs/zfs_main.c

@@ -199,6 +204,9 @@ static zfs_command_t command_table[] = {
 	{ "upgrade",	zfs_do_upgrade,		HELP_UPGRADE		},


nit: for readability let's add a blank line after upgrade and before userspace.

behlendorf · 2018-02-12T23:05:52Z

man/man8/zfs.8

+Clear project inherit flag and/or ID on the file(s) or directories.
+.Bl -tag -width "-k"
+.It Fl k
+Keep the porject ID unchanged. If not specified, the project ID will be reset as zero.


nit: s/porject/project

behlendorf · 2018-02-12T23:06:14Z

cmd/zfs/zfs_main.c

+ *
+ * 2) zfs project -C [-k] [-r] <file|directory ...>
+ *    Clear project inherit flag and/or ID on the file(s) or directories.
+ *    -k: Keep the porject ID unchanged. If not specified, the project ID


nit: s/porject/project

behlendorf · 2018-02-12T23:16:48Z

man/man8/zfs.8

+.Cm project
+.Op Fl p Ar id
+.Oo Fl r Ns Oc
+.Oo Fl s Ns Oc


nit: For flags which aren't mutually exclusive, or require additional arguments, they should be grouped together.

.Oo Fl rs Ns Oc

behlendorf · 2018-02-12T23:20:54Z

man/man8/zfs.8

+.Cm project
+.Fl C
+.Oo Fl k Ns Oc
+.Oo Fl r Ns Oc


nit: For flags which aren't mutually exclusive, or require additional arguments, they should be grouped together. You'll want to get this instance and the ones below.

Oo Fl kr Ns Oc

behlendorf · 2018-02-12T23:23:25Z

man/man8/zfs.8

@@ -905,6 +935,50 @@ The root user, or a user who has been granted the
 privilege with
 .Nm zfs Cm allow ,
 can access all groups' usage.
+.It Sy projectused Ns @ Ns Em project
+The amount of space consumed by the specified project in this dataset. Project is identified via the project identifier (ID) that is object-based numeral attribute. An object can inherit the project ID from its parent object (if the parent has the flag of inherit project ID that can be set and changed via


nit: Please wrap all new lines at 80 character like the rest of the man page.

behlendorf · 2018-02-12T23:25:31Z

man/man8/zfs.8

+List project identifier (ID) and inherit flag of file(s) or directories.
+.Bl -tag -width "-d"
+.It Fl d
+Show the directory its own project ID and inherit flag, not its children's. It will overwrite the former specified


nit: s/Show the directory its own project ID and inherit flag, not its children's./Show the directory project ID and inherit flag, not its childrens./

behlendorf · 2018-02-12T23:26:49Z

man/man8/zfs.8

+.It Fl 0
+Print file name with a trailing NUL instead of newline (by default), like "find -print0".
+.It Fl d
+Check the directory its own project ID and inherit flag, not its children's. It will overwrite the former specified


nit: s/Check the directory its own project ID and inherit flag, not its children's/Check the directory project ID and inherit flag, not its childrens

Project quota is a new ZFS system space/object usage accounting and enforcement mechanism. Similar as user/group quota, project quota is another dimension of system quota. It bases on the new object attribute - project ID. Project ID is a numerical value to indicate to which project an object belongs. An object only can belong to one project though you (the object owner or privileged user) can change the object project ID via 'chattr -p' or 'zfs project [-s] -p' explicitly. The object also can inherit the project ID from its parent when created if the parent has the project inherit flag (that can be set via 'chattr +P' or 'zfs project -s [-p]'). By accounting the spaces/objects belong to the same project, we can know how many spaces/objects used by the project. And if we set the upper limit then we can control the spaces/objects that are consumed by such project. It is useful when multiple groups and users cooperate for the same project, or a user/group needs to participate in multiple projects. Support the following commands and functionalities: zfs set projectquota@project zfs set projectobjquota@project zfs get projectquota@project zfs get projectobjquota@project zfs get projectused@project zfs get projectobjused@project zfs projectspace zfs allow projectquota zfs allow projectobjquota zfs allow projectused zfs allow projectobjused zfs unallow projectquota zfs unallow projectobjquota zfs unallow projectused zfs unallow projectobjused chattr +/-P chattr -p project_id lsattr -p This patch also supports tree quota based on the project quota via "zfs project" commands set as following: zfs project [-d|-r] <file|directory ...> zfs project -C [-k] [-r] <file|directory ...> zfs project -c [-0] [-d|-r] [-p id] <file|directory ...> zfs project [-p id] [-r] [-s] <file|directory ...> For "df [-i] $DIR" command, if we set INHERIT (project ID) flag on the $DIR, then the proejct [obj]quota and [obj]used values for the $DIR's project ID will be shown as the total/free (avail) resource. Keep the same behavior as EXT4/XFS does. TEST_ZIMPORT_POOLS="zol-0.6.1 zol-0.6.2 master" Signed-off-by: Fan Yong <fan.yong@intel.com> Change-Id: Ib4f0544602e03fb61fd46a849d7ba51a6005693c

Nasf-Fan · 2018-02-13T06:43:19Z

Addressed the latest issues mentioned by behlendorf and nedbass.

behlendorf · 2018-02-13T22:55:15Z

@Nasf-Fan @adilger merged! Thanks for all your hard work on this. Now that it's merged we should be able to get an ever wider range of testing on this and then make any additional tweaks before this appears in a tagged release.

Nasf-Fan · 2018-02-13T23:29:51Z

Thanks @behlendorf and all the patch viewers!

Project quota is a new ZFS system space/object usage accounting and enforcement mechanism. Similar as user/group quota, project quota is another dimension of system quota. It bases on the new object attribute - project ID. Project ID is a numerical value to indicate to which project an object belongs. An object only can belong to one project though you (the object owner or privileged user) can change the object project ID via 'chattr -p' or 'zfs project [-s] -p' explicitly. The object also can inherit the project ID from its parent when created if the parent has the project inherit flag (that can be set via 'chattr +P' or 'zfs project -s [-p]'). By accounting the spaces/objects belong to the same project, we can know how many spaces/objects used by the project. And if we set the upper limit then we can control the spaces/objects that are consumed by such project. It is useful when multiple groups and users cooperate for the same project, or a user/group needs to participate in multiple projects. Support the following commands and functionalities: zfs set projectquota@project zfs set projectobjquota@project zfs get projectquota@project zfs get projectobjquota@project zfs get projectused@project zfs get projectobjused@project zfs projectspace zfs allow projectquota zfs allow projectobjquota zfs allow projectused zfs allow projectobjused zfs unallow projectquota zfs unallow projectobjquota zfs unallow projectused zfs unallow projectobjused chattr +/-P chattr -p project_id lsattr -p This patch also supports tree quota based on the project quota via "zfs project" commands set as following: zfs project [-d|-r] <file|directory ...> zfs project -C [-k] [-r] <file|directory ...> zfs project -c [-0] [-d|-r] [-p id] <file|directory ...> zfs project [-p id] [-r] [-s] <file|directory ...> For "df [-i] $DIR" command, if we set INHERIT (project ID) flag on the $DIR, then the proejct [obj]quota and [obj]used values for the $DIR's project ID will be shown as the total/free (avail) resource. Keep the same behavior as EXT4/XFS does. Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by Ned Bass <bass6@llnl.gov> Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Fan Yong <fan.yong@intel.com> TEST_ZIMPORT_POOLS="zol-0.6.1 zol-0.6.2 master" Change-Id: Ib4f0544602e03fb61fd46a849d7ba51a6005693c Closes openzfs#6290

Project quota is a new ZFS system space/object usage accounting and enforcement mechanism. Similar as user/group quota, project quota is another dimension of system quota. It bases on the new object attribute - project ID. Project ID is a numerical value to indicate to which project an object belongs. An object only can belong to one project though you (the object owner or privileged user) can change the object project ID via 'chattr -p' or 'zfs project [-s] -p' explicitly. The object also can inherit the project ID from its parent when created if the parent has the project inherit flag (that can be set via 'chattr +P' or 'zfs project -s [-p]'). By accounting the spaces/objects belong to the same project, we can know how many spaces/objects used by the project. And if we set the upper limit then we can control the spaces/objects that are consumed by such project. It is useful when multiple groups and users cooperate for the same project, or a user/group needs to participate in multiple projects. Support the following commands and functionalities: zfs set projectquota@project zfs set projectobjquota@project zfs get projectquota@project zfs get projectobjquota@project zfs get projectused@project zfs get projectobjused@project zfs projectspace zfs allow projectquota zfs allow projectobjquota zfs allow projectused zfs allow projectobjused zfs unallow projectquota zfs unallow projectobjquota zfs unallow projectused zfs unallow projectobjused chattr +/-P chattr -p project_id lsattr -p This patch also supports tree quota based on the project quota via "zfs project" commands set as following: zfs project [-d|-r] <file|directory ...> zfs project -C [-k] [-r] <file|directory ...> zfs project -c [-0] [-d|-r] [-p id] <file|directory ...> zfs project [-p id] [-r] [-s] <file|directory ...> For "df [-i] $DIR" command, if we set INHERIT (project ID) flag on the $DIR, then the proejct [obj]quota and [obj]used values for the $DIR's project ID will be shown as the total/free (avail) resource. Keep the same behavior as EXT4/XFS does. Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by Ned Bass <bass6@llnl.gov> Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Fan Yong <fan.yong@intel.com> TEST_ZIMPORT_POOLS="zol-0.6.1 zol-0.6.2 master" Change-Id: Ib4f0544602e03fb61fd46a849d7ba51a6005693c Closes openzfs#6290 vpsFree.cz Porting Notes dnodes physically contain ZIO_OBJSET_MAC_LEN cause of 0.8.0

Project quota is a new ZFS system space/object usage accounting and enforcement mechanism. Similar as user/group quota, project quota is another dimension of system quota. It bases on the new object attribute - project ID. Project ID is a numerical value to indicate to which project an object belongs. An object only can belong to one project though you (the object owner or privileged user) can change the object project ID via 'chattr -p' or 'zfs project [-s] -p' explicitly. The object also can inherit the project ID from its parent when created if the parent has the project inherit flag (that can be set via 'chattr +P' or 'zfs project -s [-p]'). By accounting the spaces/objects belong to the same project, we can know how many spaces/objects used by the project. And if we set the upper limit then we can control the spaces/objects that are consumed by such project. It is useful when multiple groups and users cooperate for the same project, or a user/group needs to participate in multiple projects. Support the following commands and functionalities: zfs set projectquota@project zfs set projectobjquota@project zfs get projectquota@project zfs get projectobjquota@project zfs get projectused@project zfs get projectobjused@project zfs projectspace zfs allow projectquota zfs allow projectobjquota zfs allow projectused zfs allow projectobjused zfs unallow projectquota zfs unallow projectobjquota zfs unallow projectused zfs unallow projectobjused chattr +/-P chattr -p project_id lsattr -p This patch also supports tree quota based on the project quota via "zfs project" commands set as following: zfs project [-d|-r] <file|directory ...> zfs project -C [-k] [-r] <file|directory ...> zfs project -c [-0] [-d|-r] [-p id] <file|directory ...> zfs project [-p id] [-r] [-s] <file|directory ...> For "df [-i] $DIR" command, if we set INHERIT (project ID) flag on the $DIR, then the proejct [obj]quota and [obj]used values for the $DIR's project ID will be shown as the total/free (avail) resource. Keep the same behavior as EXT4/XFS does. Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by Ned Bass <bass6@llnl.gov> Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Fan Yong <fan.yong@intel.com> TEST_ZIMPORT_POOLS="zol-0.6.1 zol-0.6.2 master" Change-Id: Ib4f0544602e03fb61fd46a849d7ba51a6005693c Closes openzfs#6290

Nasf-Fan force-pushed the project_quota branch from cb01167 to 351b803 Compare July 4, 2017 16:56

ahrens self-requested a review July 6, 2017 17:14

Nasf-Fan force-pushed the project_quota branch 2 times, most recently from 287acff to 8437909 Compare July 11, 2017 04:08

ahrens reviewed Jul 12, 2017

View reviewed changes

Nasf-Fan force-pushed the project_quota branch from 8437909 to 158ebf9 Compare July 13, 2017 15:47

ahrens reviewed Jul 13, 2017

View reviewed changes

Nasf-Fan force-pushed the project_quota branch 2 times, most recently from d65bd78 to 347d3ae Compare July 14, 2017 17:27

Nasf-Fan changed the title ~~LU-7991 quota: Project Quota on ZFS~~ Project Quota on ZFS Jul 14, 2017

Nasf-Fan force-pushed the project_quota branch 4 times, most recently from 16e8d2f to 0fe0590 Compare July 22, 2017 01:23

Nasf-Fan force-pushed the project_quota branch 2 times, most recently from 1792dc0 to ca5e2d6 Compare July 25, 2017 00:28

Nasf-Fan force-pushed the project_quota branch 5 times, most recently from dee2d24 to d55e523 Compare July 27, 2017 07:32

Nasf-Fan force-pushed the project_quota branch from c1c78eb to 157bd55 Compare February 1, 2018 03:03

behlendorf removed the Ready label Feb 9, 2018

behlendorf added this to the 0.8.0 milestone Feb 9, 2018

nedbass approved these changes Feb 9, 2018

View reviewed changes

Nasf-Fan force-pushed the project_quota branch from 157bd55 to 29f8613 Compare February 12, 2018 14:17

behlendorf approved these changes Feb 12, 2018

View reviewed changes

Nasf-Fan force-pushed the project_quota branch 2 times, most recently from ce46a31 to 1fa7455 Compare February 13, 2018 06:41

behlendorf approved these changes Feb 13, 2018

View reviewed changes

behlendorf merged commit 9c5167d into openzfs:master Feb 13, 2018

amotin mentioned this pull request Jun 29, 2023

Add missed DMU_PROJECTUSED_OBJECT prefetch. #15024

Merged

13 tasks

		@@ -199,6 +204,9 @@ static zfs_command_t command_table[] = {
		{ "upgrade", zfs_do_upgrade, HELP_UPGRADE },

Project Quota on ZFS #6290

Project Quota on ZFS #6290

Conversation

Nasf-Fan commented Jun 30, 2017

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

mention-bot commented Jun 30, 2017

jxiong commented Jun 30, 2017

behlendorf commented Jun 30, 2017

Nasf-Fan commented Jul 12, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahrens Jul 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

behlendorf commented Jul 12, 2017

Nasf-Fan commented Jul 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nasf-Fan commented Jul 22, 2017

behlendorf commented Jul 25, 2017

Nasf-Fan commented Jul 25, 2017

Nasf-Fan commented Jan 31, 2018

codecov bot commented Feb 1, 2018 • edited Loading

Codecov Report

Nasf-Fan commented Feb 1, 2018

behlendorf commented Feb 1, 2018

Nasf-Fan commented Feb 2, 2018

behlendorf commented Feb 2, 2018 • edited Loading

nedbass commented Feb 10, 2018

Nasf-Fan commented Feb 12, 2018

nedbass commented Feb 12, 2018

behlendorf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nasf-Fan commented Feb 13, 2018

ahrens Jul 11, 2017 •

edited

Loading

codecov bot commented Feb 1, 2018 •

edited

Loading

behlendorf commented Feb 2, 2018 •

edited

Loading