ext4 quota tests fail with CONFIG_QFMT_V2=n

Hello,

If I run xfstests on ext4 with a kernel with CONFIG_QFMT_V2=n, the following tests fail:

generic/082
generic/219
generic/230
generic/231
generic/232
generic/233
generic/234
generic/235
generic/244
generic/270
generic/382

Would it be possible to handle this case and skip the test instead?

Quoted 17 lines · Omar Sandoval

Hello,

If I run xfstests on ext4 with a kernel with CONFIG_QFMT_V2=n, the following tests fail:

generic/082
generic/219
generic/230
generic/231
generic/232
generic/233
generic/234
generic/235
generic/244
generic/270
generic/382

Quoted 1 line

Would it be possible to handle this case and skip the test instead?

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

Quoted 3 lines

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

FWIW,

# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set

on this kernel.

Quoted 10 lines · Omar Sandoval

Quoted 3 lines

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

FWIW,

# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set

on this kernel.

Huh.... I don't think that's a valid kernel configuration at all. Or rather, it's allowed by Kconfig, but it shouldn't be, since without any quota formats enabled, the quota code is completely useless, and you might as well not compile it in, as near as I can tell.

Was this configuration one that you were deliberately using; and if
so, what for? Or was it one that was created accidentally?

In any case, ext4's quota feature has to have the V2 quota format enabled, or it's not going to work properly. We should remove EXT4_FEATURE_RO_COMPAT_QUOTA from the list of supported features if CONFIG_QUOTA or CONFIG_QFMT_V2 are not set.

- Ted

Quoted 17 lines · Theodore Ts'o

Quoted 10 lines · Omar Sandoval

Quoted 3 lines

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

FWIW,

# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set

on this kernel.

Huh.... I don't think that's a valid kernel configuration at all. Or rather, it's allowed by Kconfig, but it shouldn't be, since without any quota formats enabled, the quota code is completely useless, and you might as well not compile it in, as near as I can tell.

Quoted 2 lines

Was this configuration one that you were deliberately using; and if
so, what for? Or was it one that was created accidentally?

It's not intentional. I'm assuming what happened here is we disabled any modules we weren't using, but CONFIG_QUOTA happened to stay on. Is it also the case for XFS that quotas are useless without qfmt-v2?

Quoted 17 lines · Omar Sandoval

Hello,

If I run xfstests on ext4 with a kernel with CONFIG_QFMT_V2=n, the following tests fail:

generic/082
generic/219
generic/230
generic/231
generic/232
generic/233
generic/234
generic/235
generic/244
generic/270
generic/382

Quoted 1 line

Would it be possible to handle this case and skip the test instead?

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

Omar's problem is actually that he had no quota format enabled so tools failed miserably to enable quotas although xfstests thought quota should be available. That could be viewed as a bug in _require_quota() macro in xfstests but OTOH userspace has no way of knowing which quota formats are available
- it can only try to enable quota on a particular fs and that either fails or not. So implementing proper _require_quota() macro would mean you have to do full quota setup for some filesystem, try to enable quotas, and see if that fails. Doable but frankly I'm not hugely interested in that for such a cornercase...

Quoted 18 lines · Theodore Ts'o

Quoted 17 lines · Omar Sandoval

Hello,

If I run xfstests on ext4 with a kernel with CONFIG_QFMT_V2=n, the following tests fail:

generic/082
generic/219
generic/230
generic/231
generic/232
generic/233
generic/234
generic/235
generic/244
generic/270
generic/382

Quoted 5 lines

Quoted 1 line

Would it be possible to handle this case and skip the test instead?

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

Well, with ancient setups you could be using V1 quota format and then you don't need CONFIG_QFMT_V2. So I don't see a great reason to force enabling of CONFIG_QFMT_V2...

Omar's problem is actually that he had no quota format enabled so tools failed miserably to enable quotas although xfstests thought quota should be available. That could be viewed as a bug in _require_quota() macro in xfstests but OTOH userspace has no way of knowing which quota formats are available
- it can only try to enable quota on a particular fs and that either fails or not. So implementing proper _require_quota() macro would mean you have to do full quota setup for some filesystem, try to enable quotas, and see if that fails. Doable but frankly I'm not hugely interested in that for such a cornercase...

Quoted 17 lines · Theodore Ts'o

Quoted 10 lines · Omar Sandoval

Quoted 3 lines

I'd like to ask a different question, which is there a reason to support CONFIG_QFMT_V1 && !CONFIG_QFMT_V2? Maybe we should just always enable CONFIG_QFMT_V2, and simplify the test matrix?

FWIW,

# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set

on this kernel.

Huh.... I don't think that's a valid kernel configuration at all. Or rather, it's allowed by Kconfig, but it shouldn't be, since without any quota formats enabled, the quota code is completely useless, and you might as well not compile it in, as near as I can tell.

Quoted 2 lines

Was this configuration one that you were deliberately using; and if
so, what for? Or was it one that was created accidentally?

It's not intentional. I'm assuming what happened here is we disabled any modules we weren't using, but CONFIG_QUOTA happened to stay on. Is it also the case for XFS that quotas are useless without qfmt-v2?

Quoted 9 lines · Jan Kara

Omar's problem is actually that he had no quota format enabled so tools failed miserably to enable quotas although xfstests thought quota should be available. That could be viewed as a bug in _require_quota() macro in xfstests but OTOH userspace has no way of knowing which quota formats are available
- it can only try to enable quota on a particular fs and that either fails or not. So implementing proper _require_quota() macro would mean you have to do full quota setup for some filesystem, try to enable quotas, and see if that fails. Doable but frankly I'm not hugely interested in that for such a cornercase...

Yes, I'd much rather fix it in Kconfig. The question I was asing is really whether we could start deprecating QFMT_V1 by requiring QFMT_V2 and making QFMT_V1 the only optional format, and then changing the tools to strongly bias the user towards using V2 --- and maybe making it be impossible to create new QFMT_V1 format quota files at all at some point.

E.g. OCFS2 has it's own quota format (it selects only CONFIG_QUOTA, CONFIG_QUOTA_TREE) so forcing QFMT_V2 would just add unused code. So I'm not much in favor of forcing a particular quota format in Kconfig. On userspace side V2 format is the default for a long time and I haven't seen any setup with V1 quota file for years. So I guess making it harder to create new V1 files and slowly deprecating the support is a good idea.

Quoted 7 lines · Jan Kara

E.g. OCFS2 has it's own quota format (it selects only CONFIG_QUOTA, CONFIG_QUOTA_TREE) so forcing QFMT_V2 would just add unused code. So I'm not much in favor of forcing a particular quota format in Kconfig. On userspace side V2 format is the default for a long time and I haven't seen any setup with V1 quota file for years. So I guess making it harder to create new V1 files and slowly deprecating the support is a good idea.

Thanks, I didn't know that. Given that both OCFS2 and XFS have their config option for quota, I wonder if it might not be a good idea for EXT4 to also add a CONFIG_EXT4_QUOTA which selects CONFIG_QUOTA, CONFIG_QUOTA_TREE, and QFMT_V2.

The alternative would be to have ext4 silently disable support for the "quota" feature (since the built-in quota inodes have to be V2) if CONFIG_QFMT_V2 is not selected.

I think the first option is superior; do you agree?