From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>, Omar Sandoval <osandov@osandov.com>,
fstests@vger.kernel.org, Eryu Guan <eguan@redhat.com>
Subject: Re: ext4 quota tests fail with CONFIG_QFMT_V2=n
Date: Wed, 24 Jan 2018 11:44:25 +0100 [thread overview]
Message-ID: <20180124104425.qhsnjywna4fjukji@quack2.suse.cz> (raw)
In-Reply-To: <20180119171457.GA31450@thunk.org>
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
next prev parent reply other threads:[~2018-01-24 10:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-18 1:09 ext4 quota tests fail with CONFIG_QFMT_V2=n Omar Sandoval
2018-01-18 1:28 ` Theodore Ts'o
2018-01-18 2:16 ` Omar Sandoval
2018-01-18 4:08 ` Theodore Ts'o
2018-01-18 8:17 ` Omar Sandoval
2018-01-18 12:08 ` Jan Kara
2018-01-18 23:26 ` Dave Chinner
2018-01-18 12:21 ` Jan Kara
2018-01-18 16:03 ` Theodore Ts'o
2018-01-19 8:46 ` Jan Kara
2018-01-19 17:14 ` Theodore Ts'o
2018-01-24 10:44 ` Jan Kara [this message]
2018-01-18 18:07 ` Omar Sandoval
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180124104425.qhsnjywna4fjukji@quack2.suse.cz \
--to=jack@suse.cz \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.