All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: 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: Mon, 11 Jul 2016 18:15:56 +0200	[thread overview]
Message-ID: <20160711161556.GB9334@quack2.suse.cz> (raw)
In-Reply-To: <20160708050228.GH19871@thunk.org>

On Fri 08-07-16 01:02:28, Ted Tso wrote:
> On Thu, Jul 07, 2016 at 10:19:27PM -0500, Eric Sandeen wrote:
> > I don't know how we got to the point where we have 2 parallel
> > quota infrastructures, it's an unfortunate mess IMHO.  :(
> 
> Actually, I've been staring at the quotatools source code and it's
> even more complicated than that.  There are newer quotactl
> subcommands, such as Q_XGETQSTAT and Q_XGETQSTATV, which currently
> quotatools only tries using if it thinks the quota format (which in
> this sense seems to be system API, not the actual quota file format
> --- these two concepts seem to have been overloaded at some point) is
> "xfs".

quota-tools currently assume that certain quotactl(8) calls are fine only
for certain quota formats. And this has been long true - since its
beginning, XFS and VFS quota stacks were pretty independent including
supported quotactl calls. Only recently (about year and half ago) I have
added necessary plumbing so that "XFS quotactls" and "VFS quotactls" can be
used independently of the underlying filesystem. The distinction still
remained in quota-tools because there was no real need in unifying them and
we still have to keep knowing about the distinction so that quota-tools can
work with older kernels.

> Currently quotatools only assumes the "xfs" quota format should be
> used for "xfs" and "gfs" --- but it works for other file systems,
> including ext4 as well.  As a result, there's certain information,
> such as whether ext4 is doing limits enforcement as well as quota
> tracking, which is *not* being exposed to the user.  I suspect one of
> the reasons for this is the tests in quotatools for which kernel
> interfaces are present are fairly primitive, and in fact there are
> some comments in quotasys.c which makes references to behaviours of
> certain specific Red Hat kernel versions to decide which interfaces
> are available.  :-(

No, the reason is that until recently there was no kernel interface
to convey this information to userspace for VFS based quotas and nobody
complained :). If there is some functionality you miss in quota-tools, then
I can have a look at implementing it. E.g. reporting whether only tracking
or also enforcement is enabled is relatively simple to add.
 
> And if we just did the simple thing to enable use of the "new" (aka
> "xfs", although this is ***massive*** misnomer) quota format in
> quotatools, it would break if the latest quota tools were ever
> compiled on older Enterprise Linux systems.

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.

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

  reply	other threads:[~2016-07-11 16:15 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 [this message]
2016-07-11 17:12               ` Theodore Ts'o
2016-07-12 10:59                 ` Jan Kara
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=20160711161556.GB9334@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.