Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.10.7
-
3
-
9223372036854775807
Description
Testing Lustre 2.10.7 against zfs 0.8.0-rc5
If the file system is stored in pools created under previous versions of zfs and the project quota feature has not yet been enabled on those pools, writes fail with -EOPNOTSUPP
Debug logs on the OST seem to indicate that the -EOPNOTSUPP is returned from osd_declare_attr_set(), which requires that if Lustre has been built with the ZFS project quota feature enabled, that the pool must have the feature enabled.
#ifdef ZFS_PROJINHERIT
if (attr && attr->la_valid & LA_PROJID) {
if (!osd->od_projectused_dn)
GOTO(out, rc = -EOPNOTSUPP);
It's unclear why this is necessary. In addition, every user who upgrades from an earlier version of lustre will initially be in this state, where their zfs software supports project quotas, but the feature is not enabled on the pool. As long as they do not enable the feature on the pool, they can revert to the earlier zfs version if they encounter issues.
Attachments
Activity
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35009
Subject: LU-12309 osd-zfs: Support disabled project quotas
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 259c14db010a0733c4e467e451250a89c5efac3e
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34888/
Subject: LU-12309 osd-zfs: Support disabled project quotas
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 291e7196d39365739f9daa02efd25535b5415174
Is there something that you are running in userspace that is trying to set projid, or is this just normal usage?
Mount (all the servers and the client) is successful. I see the failure with an ordinary write, e.g. using bash redirect or using dd.
Possibly the check could have a caveat that it shouldn't try to set projid if it is zero and not enabled, because that is just the default value?
Good idea.
I think the intent is that someone trying to set the projid on a file where the storage does not support (or enable) project quota should get }{-ENOTSUPP}}. Definitely it shouldn't refuse to mount in that case.
Is there something that you are running in userspace that is trying to set projid, or is this just normal usage?
Possibly the check could have a caveat that it shouldn't try to set projid if it is zero and not enabled, because that is just the default value?
Nathaniel Clark (nclark@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/34888
Subject: LU-12309 osd-zfs: Support disabled project quotas
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 74733dd3aa761dbe0477b599b166a3791e8582c5
I haven't tried it, but I believe you could reproduce this with a new file system easily, just by using option "-d" to zpool create, and then explicitly enabling features other than project quotas.
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35009/
Subject:
LU-12309osd-zfs: Support disabled project quotasProject: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 965af09947473129c45e8201e9f9b4cd4da77d8b