From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, jack@suse.cz, xfs@oss.sgi.com
Subject: Re: [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA
Date: Mon, 25 Jan 2016 16:07:10 +0100 [thread overview]
Message-ID: <20160125150710.GN24938@quack.suse.cz> (raw)
In-Reply-To: <1453487136-12681-1-git-send-email-sandeen@redhat.com>
On Fri 22-01-16 12:25:29, Eric Sandeen wrote:
> This adds a new quotactl, Q_GETNEXTQUOTA.
>
> Q_GETNEXTQUOTA is exactly like Q_GETQUOTA, except that it will
> return quota information for the id equal to or greater than
> the id requested. In other words, if the specified id has
> no quota, the command will return quota information for the
> next higher id which does have a quota set. If no higher id
> has an active quota, -ESRCH is returned.
>
> So if you ask for id X, you can get back quota for id X,
> id X+N, or -ESRCH if no higher id has a quota.
>
> This allows filesystems to do efficient iteration in kernelspace,
> much like extN filesystems do in userspace when asked to report
> all active quotas.
>
> Today, filesystems such as XFS require getpwent()-style iterations,
> and for systems which have i.e. LDAP backends, this can be very
> slow, or even impossible if iteration is not allowed in the
> configuration.
>
> Patches 1 and 4 are just small fixups that turned up along the way;
> 2 and 3 add the actual quota plumbing, and the rest are xfs-specific
> to allow xfs to support this new interface.
>
> For non-xfs quota, this does require a new structure which is
> able to pass back the discovered ID along with the quota info.
> For xfs-quota, the id is already present in the structure.
>
> V3:
> * Remove 32-bit compat stuff (i686/x86_64 at least works w/o it...)
> * Require CAP_SYS_ADMIN for these calls
> * Pass back found ID in &qid passed to ->get_nextdqblk, rather
> than modifying struct qc_dqblk
> * Munge that found ID back through user-namespace conversions
> before returning it in the user structure.
So I've taken patch 1/7 into my tree since that is completely independent.
Patches 2/7 and 3/7 look mostly good to me (except for that small omission
in 3/7) so I can take them to my tree as well. Once I'll finish testing
some UDF changes I have pending I'll push the tree to:
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
and Dave can pull from there to have a basis for XFS patches. I want to
implement Q_GETNEXTQUOTA for VFS quota formats as well and those will go
through my tree so that's why I want the interface changes go via my tree.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, jack@suse.cz,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA
Date: Mon, 25 Jan 2016 16:07:10 +0100 [thread overview]
Message-ID: <20160125150710.GN24938@quack.suse.cz> (raw)
In-Reply-To: <1453487136-12681-1-git-send-email-sandeen@redhat.com>
On Fri 22-01-16 12:25:29, Eric Sandeen wrote:
> This adds a new quotactl, Q_GETNEXTQUOTA.
>
> Q_GETNEXTQUOTA is exactly like Q_GETQUOTA, except that it will
> return quota information for the id equal to or greater than
> the id requested. In other words, if the specified id has
> no quota, the command will return quota information for the
> next higher id which does have a quota set. If no higher id
> has an active quota, -ESRCH is returned.
>
> So if you ask for id X, you can get back quota for id X,
> id X+N, or -ESRCH if no higher id has a quota.
>
> This allows filesystems to do efficient iteration in kernelspace,
> much like extN filesystems do in userspace when asked to report
> all active quotas.
>
> Today, filesystems such as XFS require getpwent()-style iterations,
> and for systems which have i.e. LDAP backends, this can be very
> slow, or even impossible if iteration is not allowed in the
> configuration.
>
> Patches 1 and 4 are just small fixups that turned up along the way;
> 2 and 3 add the actual quota plumbing, and the rest are xfs-specific
> to allow xfs to support this new interface.
>
> For non-xfs quota, this does require a new structure which is
> able to pass back the discovered ID along with the quota info.
> For xfs-quota, the id is already present in the structure.
>
> V3:
> * Remove 32-bit compat stuff (i686/x86_64 at least works w/o it...)
> * Require CAP_SYS_ADMIN for these calls
> * Pass back found ID in &qid passed to ->get_nextdqblk, rather
> than modifying struct qc_dqblk
> * Munge that found ID back through user-namespace conversions
> before returning it in the user structure.
So I've taken patch 1/7 into my tree since that is completely independent.
Patches 2/7 and 3/7 look mostly good to me (except for that small omission
in 3/7) so I can take them to my tree as well. Once I'll finish testing
some UDF changes I have pending I'll push the tree to:
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
and Dave can pull from there to have a basis for XFS patches. I want to
implement Q_GETNEXTQUOTA for VFS quota formats as well and those will go
through my tree so that's why I want the interface changes go via my tree.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2016-01-25 15:07 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 18:25 [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 1/7] quota: remove unused cmd argument from quota_quotaon() Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-25 14:47 ` Jan Kara
2016-01-25 14:47 ` Jan Kara
2016-01-25 14:49 ` Jan Kara
2016-01-25 14:49 ` Jan Kara
2016-01-22 18:25 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-25 14:51 ` Jan Kara
2016-01-25 14:51 ` Jan Kara
2016-01-26 12:57 ` Jan Kara
2016-01-26 12:57 ` Jan Kara
2016-01-26 15:00 ` Eric Sandeen
2016-01-26 15:00 ` Eric Sandeen
2016-01-26 17:52 ` Jan Kara
2016-01-26 17:52 ` Jan Kara
2016-01-26 17:57 ` Eric Sandeen
2016-01-26 17:57 ` Eric Sandeen
2016-01-26 18:39 ` Eric Sandeen
2016-01-26 18:39 ` Eric Sandeen
2016-01-26 20:40 ` Jan Kara
2016-01-26 20:40 ` Jan Kara
2016-01-22 18:25 ` [PATCH 3/7] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-25 14:51 ` Jan Kara
2016-01-25 14:51 ` Jan Kara
2016-01-22 18:25 ` [PATCH 4/7] xfs: don't overflow quota ID when initializing dqblk Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 5/7] xfs: get quota inode from mp & flags rather than dqp Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 6/7] xfs: Factor xfs_seek_hole_data into helper Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 7/7] xfs: wire up Q_XGETNEXTQUOTA / get_nextdqblk Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-26 18:40 ` [PATCH 7/7 V4] " Eric Sandeen
2016-01-26 18:40 ` Eric Sandeen
2016-01-25 15:07 ` Jan Kara [this message]
2016-01-25 15:07 ` [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA Jan Kara
2016-01-25 16:04 ` Eric Sandeen
2016-01-25 16:04 ` Eric Sandeen
2016-01-26 13:10 ` Jan Kara
2016-01-26 13:10 ` Jan Kara
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=20160125150710.GN24938@quack.suse.cz \
--to=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--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 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.