All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@sandeen.net>,
	Dave Chinner <david@fromorbit.com>,
	Wang Shilong <wangshilong1991@gmail.com>,
	fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
	sihara@ddn.com, lixi@ddn.com, Wang Shilong <wshilong@ddn.com>
Subject: Re: [PATCH v2] xfstests, generic: add project quota attribute tests
Date: Tue, 12 Jul 2016 12:59:08 +0200	[thread overview]
Message-ID: <20160712105908.GE16460@quack2.suse.cz> (raw)
In-Reply-To: <20160711171242.GA21285@thunk.org>

On Mon 11-07-16 13:12:42, Ted Tso wrote:
> On Mon, Jul 11, 2016 at 06:15:56PM +0200, Jan Kara wrote:
> > 
> > What would you like to achieve with this? There is 'QF_META' format which
> > is different from 'QF_XFS' format basically only in the set of quotactls
> > used. As I said above it might be nice to separate kernel-api from the
> > underlying-quota-format but in reality these two were bound together in
> > older kernels so they are not really independent.
> 
> The main reason why I noticed is with the new (err, "latest") ext4
> quota (enabled via mke2fs -t ext4 -O quota) implementation, we enable
> quota tracking at mount time.  (This may be true with journalled quota
> as well, actually).  But we don't actually enable quota *enforcement*
> until quotaon is given.

Yes.

> The problem is that quotaon -p prints the status of whether or not
> quota *tracking* is enabled, and with the new ext4 quota, quota
> tracking is *always* enabled.  So quota -p doesn't report anything
> useful for new ext4 quota systems, and when I started to look at how
> to change things, that's when I noticed that we weren't using the new
> quotactl commands with ext4 even though they worked, and that the new
> quotactl implementation had more functionality than the older ones.

OK. But with XFS you'd notice that quotaon -p also returns 'on' whenever
the accounting is turned on. So ext4 and xfs behave in the same way.
Arguably it would be more useful if quotaon -p reported 'off', 'accounting',
'enforcement'. Maybe I'll do that.

> BTW, I've seriously been thinking about changing the default so that
> if you use mke2fs -O quota, quota enforcement is also enabled by
> default at mount time, and we use a mount option to disable quota
> enforcement.  If we then added a way of selectively enabling and
> disabling quota enforcement via quota-tools, then we would be bringing
> behaivour of how ext4 quota works to like how xfs treats quota.  The
> question I have is how to do this in a way that isn't surprising for
> people who are used to the old behaviour --- but mke2fs -O quota is
> still relatively new, so maybe we could get away with it without
> having to add more superblock flags.

So currently if you use quotaon(8) it will turn on/off only enforcement in
ext4 (accounting is always on when the feature is enabled) - don't get
confused with 'quotaon -p' output - that tests something different.

Speaking of automatic enabling of quota enforcement: I wanted to keep the
old behavior where no enforcement happens until you run quotaon(8) which is
how things traditionally worked for ext2/3/4. That's why things default to
having enforcement off. If we want to make things more consistent with XFS,
one option I can see is that when e.g. 'usrquota' mount option is set, then
user quota enforcement will be turned on. That is essentially how XFS
works (including the mount option name). What do you think?

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

  reply	other threads:[~2016-07-12 10:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06  6:22 [PATCH v2] xfstests, generic: add project quota attribute tests Wang Shilong
2016-07-06 16:10 ` Eric Sandeen
2016-07-06 23:35 ` Dave Chinner
2016-07-07  2:47   ` Eric Sandeen
2016-07-08  0:51     ` Dave Chinner
2016-07-08  2:46       ` Theodore Ts'o
2016-07-08  3:19         ` Eric Sandeen
2016-07-08  4:57           ` Dave Chinner
2016-07-08  5:02           ` Theodore Ts'o
2016-07-11 16:15             ` Jan Kara
2016-07-11 17:12               ` Theodore Ts'o
2016-07-12 10:59                 ` Jan Kara [this message]
2016-07-12 14:32                   ` Jan Kara
2016-07-12 16:15                   ` Theodore Ts'o
2016-07-14 13:13                     ` Jan Kara
2016-07-15  1:15                       ` Wang Shilong
2016-07-18 10:20                         ` Jan Kara
2016-07-18 12:45                           ` Wang Shilong

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=20160712105908.GE16460@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=lixi@ddn.com \
    --cc=sandeen@sandeen.net \
    --cc=sihara@ddn.com \
    --cc=tytso@mit.edu \
    --cc=wangshilong1991@gmail.com \
    --cc=wshilong@ddn.com \
    /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.