linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>,
	fsdevel <linux-fsdevel@vger.kernel.org>,
	Eric Sandeen <sandeen@redhat.com>,
	xfs@oss.sgi.com
Subject: Re: [PATCH 0/4] quota: add new quotactl Q_XGETQUOTA2
Date: Mon, 18 Jan 2016 11:33:02 +0100	[thread overview]
Message-ID: <20160118103302.GD6850@quack.suse.cz> (raw)
In-Reply-To: <56992CD4.6030408@sandeen.net>

On Fri 15-01-16 11:31:00, Eric Sandeen wrote:
> Hi Jan -
> 
> On 1/15/16 3:35 AM, Jan Kara wrote:
> > On Wed 13-01-16 16:40:58, Eric Sandeen wrote:
> >> On 1/11/16 10:28 AM, Jan Kara wrote:
> 
> ...
> 
> >>> Actually, what I want from you is just an interface which is usable for VFS
> >>> quotas as well since I'd like to avoid adding GETQUOTA2 quotactl shortly
> >>> after XGETQUOTA2 :).
> >>
> >> Actually, that's exactly what I thought would *need* to happen ... we already
> >> have this weird 15-year-old split-brain quota interface, so if xfs and ext4
> >> both need the same functionality, then we'd probably add both GETQUOTA2 and
> >> XGETQUOTA2.  If we were doing this all from scratch, sure, but adding a new
> >> handles-both-quota-types interface when every other operation is already split
> >> between the two almost seems to make matters worse.
> > 
> > Well, currently GETQUOTA and XGETQUOTA (and all the other quotactls) are
> > actually translated so they work regardless of the underlying filesystem.
> > So the only difference between XFS and VFS quotactls is in the formatting
> > of input/output structures. So from kernel POV it seems somewhat pointless
> > to add two calls doing the same thing and differing just in the formatting
> > of output - especially when we want the call to be extensible.
> > 
> > I agree that having a unified call means having a new structure for passing
> > dquot info between kernel and userspace. So just for adding that one small
> > feature you want it seems like an overkill. But when thinking about new
> > extensible getquota quotactl it IMHO makes sense to unify the VFS/XFS split
> > brain. Thoughts?
> 
> My first lazy/hacky thought is "how terrible would it be to overload the
> quotactl syscall return value with quota ID for Q_GETQUOTA2 calls?"

As you said, that won't quite work...

> For a purpose-built interface of "find the next ID" that wouldn't require any
> structure or interface changes...
> 
> We could name it Q_GETNEXTQUOTA / Q_XGETNEXTQUOTA to make it explicit about
> the purpose, and document that return behavior.  Done & done.  ;)
>
> A new grand unified extensible quota call sounds like a great idea, I just
> hate to gate this work on designing a brand-new interface.

OK, ok. I like Dave's proposal for quotactl2(). So let's leave the unification
for later and implent Q_GETNEXTQUOTA and Q_XGETNEXTQUOTA with the
functionality of your original Q_XGETQUOTA2. Having separate call to get
next ID would save us one new quotactl but OTOH we would need two syscalls
(and quota structure lookups) to report one structure and there are
potentially *lots* of them.

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

  parent reply	other threads:[~2016-01-18 10:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 16:56 [PATCH 0/4] quota: add new quotactl Q_XGETQUOTA2 Eric Sandeen
2016-01-08 16:57 ` [PATCH 1/4] " Eric Sandeen
2016-01-08 16:57 ` [PATCH 2/4] xfs: get quota inode from mp & flags rather than dqp Eric Sandeen
2016-01-08 16:58 ` [PATCH 3/4] xfs: Factor xfs_seek_hole_data into helper Eric Sandeen
2016-01-11 15:57   ` Jan Kara
2016-01-11 16:01   ` [PATCH 3/4 V3] " Eric Sandeen
2016-01-08 16:59 ` [PATCH 4/4] xfs: wire up Q_XGETQUOTA2 / get_dqblk2 Eric Sandeen
2016-01-08 18:36 ` [PATCH] linux-quota: wire Q_XGETQUOTA2 into generic repquota Eric Sandeen
2016-01-09  7:26 ` [PATCH 0/4] quota: add new quotactl Q_XGETQUOTA2 Christoph Hellwig
2016-01-11 13:26   ` Jan Kara
2016-01-11 16:07     ` Eric Sandeen
2016-01-11 16:28       ` Jan Kara
2016-01-13 22:40         ` Eric Sandeen
2016-01-15  9:35           ` Jan Kara
2016-01-15 17:31             ` Eric Sandeen
2016-01-15 19:38               ` Eric Sandeen
2016-01-18 10:33               ` Jan Kara [this message]
2016-01-18 11:00                 ` Christoph Hellwig
2016-01-18 15:18                 ` Eric Sandeen
2016-01-18 15:40                   ` Jan Kara
2016-01-15 22:50             ` Dave Chinner

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=20160118103302.GD6850@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).