From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
Theodore Ts'o <tytso@mit.edu>,
Dmitry Monakhov <dmonakhov@openvz.org>, Ben Myers <bpm@sgi.com>,
xfs@oss.sgi.com, Li Xi <pkuelelixi@gmail.com>
Subject: Re: [RFC] directory quota survey on xfs
Date: Tue, 21 Jan 2014 15:07:06 +0800 [thread overview]
Message-ID: <20140121070706.GA1819@gmail.com> (raw)
In-Reply-To: <20140115213207.GJ3431@dastard>
Hi Dave,
On Thu, Jan 16, 2014 at 08:32:07AM +1100, Dave Chinner wrote:
> On Wed, Jan 15, 2014 at 11:03:22AM -0700, Andreas Dilger wrote:
> > On Jan 15, 2014, at 1:12 AM, Zheng Liu <gnehzuil.liu@gmail.com> wrote:
> > > On Mon, Dec 23, 2013 at 12:42:22PM +1100, Dave Chinner wrote:
> > >> I'd also strongly suggest that you use the XFS userspace quota API
> > >> for managing project quotas, so that we can use the same management
> > >> tools and tests to verify that they behave the same. Please don't
> > >> invent a new version of the quota API to implement this - everything
> > >> you need ifor managing project/directory quotas is already there in
> > >> xfs_quota.....
> > >
> > > Frankly, I don't like this, really. Now we have quota-tool to manage
> > > the quota in ext4. So IMHO we'd better go on using this tool because it
> > > is natural for ext4 users.
>
> Zheng - you're confusing the userspace tool that users run with
> the quotactl API the tool uses to communicate with the kernel.
Thanks for pointing it out.
>
> > > I still couldn't accept this fact that I
> > > need to install xfsprogs for using a feature of ext4. Further, it could
> > > make users puzzled because they use quota to control user/group quota in
> > > ext4, but it uses xfs_quota to control project quota. It could bring
> > > some troubles for the ext4 users who have written some scripts to manage
> > > their machines.
> >
> > Please see Li Xi's recent email "Directory/Project quota supports" on
> > the linux-ext4 list. He has already added some prototype support for
> > project quotas to quota-tools.
>
> So, while it is a prototype, lets do it the right way. i.e. let's
> not reinvent the wheel.
Yes, I agree with you and Andreas that we shouldn't reinvent the wheel.
>
> > I think it might make sense to keep the same API as XFS for the ext4
> > quotas (to keep compatibility for existing XFS deployments), but add
> > support into quota-tools so that it is usable by all filesystems.
>
> Well, yes. If you are writing a generic quota tool, then it needs to
> support all filesystems. We already have a fully featured quota API
> that can provide this support - it's the API that XFS has been using
> since it was ported to Linux. We have the opportunity to unify the
> quota APIs that ext4 and XFS, so we should take the opportunity
> while it is here. Don't create a new API for ext4 simply because of
> NIH syndrome.
These days I was thinking about your comment that uses quotactl API to
communicate the userspace tool with the kernel. But I am still
confusing about your comment that unifies the quota API between ext4 and
XFS.
Now we have two flag sets in quotactl(2). One (Q_QUOTAON, Q_GETQUOTA,
etc...) is used by extN file system (I am not sure whether other file
systems use these flags or not), and another (Q_XQUOTAON, Q_XGETQSTAT,
etc...) is used by XFS.
In xfs_quota it uses an ioctl(2) to get/set/check project id, and calls
quotactl(2) with Q_XSETQLIM/Q_XGETQUOTA to set/get project quota. On
kernel side, ->set_dqblk()/get_dqblk() is called when we try to set/get
project quota in XFS. In ext4 the same callback functions are used to
set/get user/group quota, although on userspace we use Q_SETQUOTA/
Q_GETQUOTA to set/get quota. I am not sure I fully understand your
meaning that unifies the quota API between ext4 and XFS. Do you mean
that we should use Q_XSETQLIM/Q_XGETQUOTA flags to set/get quota on ext4?
Or using quotactl(2) is fine for you.
Please correct me if I miss something.
Thanks,
- Zheng
WARNING: multiple messages have this Message-ID (diff)
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Andreas Dilger <adilger@dilger.ca>, Theodore Ts'o <tytso@mit.edu>,
xfs@oss.sgi.com, Ben Myers <bpm@sgi.com>,
Dmitry Monakhov <dmonakhov@openvz.org>,
Li Xi <pkuelelixi@gmail.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] directory quota survey on xfs
Date: Tue, 21 Jan 2014 15:07:06 +0800 [thread overview]
Message-ID: <20140121070706.GA1819@gmail.com> (raw)
In-Reply-To: <20140115213207.GJ3431@dastard>
Hi Dave,
On Thu, Jan 16, 2014 at 08:32:07AM +1100, Dave Chinner wrote:
> On Wed, Jan 15, 2014 at 11:03:22AM -0700, Andreas Dilger wrote:
> > On Jan 15, 2014, at 1:12 AM, Zheng Liu <gnehzuil.liu@gmail.com> wrote:
> > > On Mon, Dec 23, 2013 at 12:42:22PM +1100, Dave Chinner wrote:
> > >> I'd also strongly suggest that you use the XFS userspace quota API
> > >> for managing project quotas, so that we can use the same management
> > >> tools and tests to verify that they behave the same. Please don't
> > >> invent a new version of the quota API to implement this - everything
> > >> you need ifor managing project/directory quotas is already there in
> > >> xfs_quota.....
> > >
> > > Frankly, I don't like this, really. Now we have quota-tool to manage
> > > the quota in ext4. So IMHO we'd better go on using this tool because it
> > > is natural for ext4 users.
>
> Zheng - you're confusing the userspace tool that users run with
> the quotactl API the tool uses to communicate with the kernel.
Thanks for pointing it out.
>
> > > I still couldn't accept this fact that I
> > > need to install xfsprogs for using a feature of ext4. Further, it could
> > > make users puzzled because they use quota to control user/group quota in
> > > ext4, but it uses xfs_quota to control project quota. It could bring
> > > some troubles for the ext4 users who have written some scripts to manage
> > > their machines.
> >
> > Please see Li Xi's recent email "Directory/Project quota supports" on
> > the linux-ext4 list. He has already added some prototype support for
> > project quotas to quota-tools.
>
> So, while it is a prototype, lets do it the right way. i.e. let's
> not reinvent the wheel.
Yes, I agree with you and Andreas that we shouldn't reinvent the wheel.
>
> > I think it might make sense to keep the same API as XFS for the ext4
> > quotas (to keep compatibility for existing XFS deployments), but add
> > support into quota-tools so that it is usable by all filesystems.
>
> Well, yes. If you are writing a generic quota tool, then it needs to
> support all filesystems. We already have a fully featured quota API
> that can provide this support - it's the API that XFS has been using
> since it was ported to Linux. We have the opportunity to unify the
> quota APIs that ext4 and XFS, so we should take the opportunity
> while it is here. Don't create a new API for ext4 simply because of
> NIH syndrome.
These days I was thinking about your comment that uses quotactl API to
communicate the userspace tool with the kernel. But I am still
confusing about your comment that unifies the quota API between ext4 and
XFS.
Now we have two flag sets in quotactl(2). One (Q_QUOTAON, Q_GETQUOTA,
etc...) is used by extN file system (I am not sure whether other file
systems use these flags or not), and another (Q_XQUOTAON, Q_XGETQSTAT,
etc...) is used by XFS.
In xfs_quota it uses an ioctl(2) to get/set/check project id, and calls
quotactl(2) with Q_XSETQLIM/Q_XGETQUOTA to set/get project quota. On
kernel side, ->set_dqblk()/get_dqblk() is called when we try to set/get
project quota in XFS. In ext4 the same callback functions are used to
set/get user/group quota, although on userspace we use Q_SETQUOTA/
Q_GETQUOTA to set/get quota. I am not sure I fully understand your
meaning that unifies the quota API between ext4 and XFS. Do you mean
that we should use Q_XSETQLIM/Q_XGETQUOTA flags to set/get quota on ext4?
Or using quotactl(2) is fine for you.
Please correct me if I miss something.
Thanks,
- Zheng
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-01-21 7:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-22 9:59 [RFC] directory quota survey on xfs Zheng Liu
2013-12-23 1:42 ` Dave Chinner
2013-12-23 1:42 ` Dave Chinner
2013-12-23 9:12 ` Arkadiusz Miśkiewicz
2013-12-23 23:43 ` Dave Chinner
2013-12-23 23:43 ` Dave Chinner
2014-01-15 8:12 ` Zheng Liu
2014-01-15 8:12 ` Zheng Liu
2014-01-15 18:03 ` Andreas Dilger
2014-01-15 21:32 ` Dave Chinner
2014-01-21 7:07 ` Zheng Liu [this message]
2014-01-21 7:07 ` Zheng Liu
2014-01-23 22:32 ` Dave Chinner
2014-01-23 22:32 ` Dave Chinner
2014-01-24 0:06 ` Darrick J. Wong
2014-01-24 0:06 ` Darrick J. Wong
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=20140121070706.GA1819@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=adilger@dilger.ca \
--cc=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=pkuelelixi@gmail.com \
--cc=tytso@mit.edu \
--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.