ext4 quota tests fail with CONFIG_QFMT_V2=n

ext4 quota tests fail with CONFIG_QFMT_V2=n

[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

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

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Theodore Ts'o]

On Wed, Jan 17, 2018 at 05:09:36PM -0800, Omar Sandoval wrote:
> 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?

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?

       	      		      	  	       	    - Ted

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Omar Sandoval]

On Wed, Jan 17, 2018 at 08:28:31PM -0500, Theodore Ts'o wrote:
> On Wed, Jan 17, 2018 at 05:09:36PM -0800, Omar Sandoval wrote:
> > 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?
> 
> 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.

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Theodore Ts'o]

On Wed, Jan 17, 2018 at 06:16:10PM -0800, Omar Sandoval wrote:
> > 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

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Omar Sandoval]

On Wed, Jan 17, 2018 at 11:08:19PM -0500, Theodore Ts'o wrote:
> On Wed, Jan 17, 2018 at 06:16:10PM -0800, Omar Sandoval wrote:
> > > 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?

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?

> 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

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Jan Kara]

On Thu 18-01-18 00:17:13, Omar Sandoval wrote:
> On Wed, Jan 17, 2018 at 11:08:19PM -0500, Theodore Ts'o wrote:
> > On Wed, Jan 17, 2018 at 06:16:10PM -0800, Omar Sandoval wrote:
> > > > 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?
> 
> 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?

No, they can be used without CONFIG_QFMT_V2 but also without CONFIG_QUOTA.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Dave Chinner]

On Thu, Jan 18, 2018 at 12:17:13AM -0800, Omar Sandoval wrote:
> On Wed, Jan 17, 2018 at 11:08:19PM -0500, Theodore Ts'o wrote:
> > On Wed, Jan 17, 2018 at 06:16:10PM -0800, Omar Sandoval wrote:
> > > > 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?
> 
> 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?

XFS quotas are completely independent of the generic CONFIG_QUOTA
stuff. From fs/xfs/Kconfig:

config XFS_QUOTA
        bool "XFS Quota support"
        depends on XFS_FS
        select QUOTACTL
        help
.....

So it's fully controlled by CONFIG_XFS_QUOTA...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Jan Kara]

On Wed 17-01-18 20:28:31, Theodore Ts'o wrote:
> On Wed, Jan 17, 2018 at 05:09:36PM -0800, Omar Sandoval wrote:
> > 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?
> 
> 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...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Theodore Ts'o]

On Thu, Jan 18, 2018 at 01:21:25PM +0100, Jan Kara wrote:
> 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.

It will take a while --- years no doubt --- but a journey of ten
thousand miles starts with a single step, as the saying goes.

					- Ted

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Jan Kara]

On Thu 18-01-18 11:03:21, Theodore Ts'o wrote:
> On Thu, Jan 18, 2018 at 01:21:25PM +0100, Jan Kara wrote:
> > 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.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Theodore Ts'o]

On Fri, Jan 19, 2018 at 09:46:49AM +0100, Jan Kara wrote:
> 
> 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?

  	    	  	    	      	     - Ted

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Jan Kara]

On Fri 19-01-18 12:14:57, Theodore Ts'o wrote:
> On Fri, Jan 19, 2018 at 09:46:49AM +0100, Jan Kara wrote:
> > 
> > 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?

Yeah, I agree that CONFIG_EXT4_QUOTA is a good idea.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: ext4 quota tests fail with CONFIG_QFMT_V2=n

[Omar Sandoval]

On Thu, Jan 18, 2018 at 01:21:25PM +0100, Jan Kara wrote:
> On Wed 17-01-18 20:28:31, Theodore Ts'o wrote:
> > On Wed, Jan 17, 2018 at 05:09:36PM -0800, Omar Sandoval wrote:
> > > 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?
> > 
> > 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...

Yeah, I'll just disable these tests. Thanks, Jan and Ted.