From: Jan Kara <jack@suse.cz>
To: Aditya Kali <adityakali@google.com>
Cc: Jan Kara <jack@suse.cz>,
adilger@dilger.ca, tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2] ext4: make quota as first class supported feature
Date: Tue, 30 Aug 2011 01:17:03 +0200 [thread overview]
Message-ID: <20110829231703.GL5672@quack.suse.cz> (raw)
In-Reply-To: <CAGr1F2EXgaWVywbRUUdOhPmvv3ZXwt1nnOpkyuBgygSYvJ+h-A@mail.gmail.com>
On Mon 29-08-11 15:42:36, Aditya Kali wrote:
> On Mon, Aug 29, 2011 at 2:57 PM, Jan Kara <jack@suse.cz> wrote:
> > On Fri 19-08-11 12:06:09, Aditya Kali wrote:
> >> This patch is an attempt towards supporting quotas as first class
> >> feature in ext4. It is based on the proposal at:
> >> https://ext4.wiki.kernel.org/index.php/Design_For_1st_Class_Quota_in_Ext4
> >> This patch introduces a new feature - EXT4_FEATURE_RO_COMPAT_QUOTA which, when
> >> turned on, enables quota accounting at mount time iteself. Also, the
> >> quota inodes are stored in two additional superblock fields.
> >> Some changes introduced by this patch that should be pointed out are:
> >> 1) Two new ext4-superblock fields - s_usr_quota_inum and s_grp_quota_inum
> >> for storing the quota inodes in use.
> >> 2) If the QUOTA feature and corresponding quota inodes are set in superblock,
> >> Quotas are turned on at mount time irrespective of the quota mount options.
> >> Thus the mount options 'quota', 'usrquota' and 'grpquota' are completely
> >> ignored with the new QUOTA feature flag.
> > Hmm, cannot we automatically enable 'usrquota' and 'grpquota' options
> > when we see QUOTA feature enabled? Quota tools still need these options to
> > identify a filesystem they can work with (although another option would be
> > to change quota tools to use GETFMT with ext4 filesystem to identify
> > whether quotas are enabled or not).
> >
> In my current change, these options are just ignored, and the user can
> still set them if any user tools depend on them while
> mounting/remounting the filesystem.
> The design wiki
> (https://ext4.wiki.kernel.org/index.php/Design_For_1st_Class_Quota_in_Ext4#How_can_userspace_tell_if_quota_is_enabled.3F)
> mentions that 'usrquota' & 'grpquota' options won't be used (so I was
> under impression that they are being deprecated). Also, if these are
> set automatically on mount, it would mean that the user wont be able
> to set these options anymore.
OK, probably makes sense in the long run. I'll update quota tools to use
GETFMT quotactl then...
> >> 3) Default quota inodes are: inode#3 for tracking userquota and inode#4 for
> >> tracking group quota. The superblock fields can be set to use other inodes
> >> as well.
> >> 4) mke2fs or tune2fs will initialize these inodes when quota feature is
> >> being set. The default reserved inodes will not be visible to user as
> >> regular files.
> >> 5) Once quotas are turned on, they cannot be turned off while the FS is
> >> mounted. This is because we do not want to let the quota get inconsistent.
> > Both xfs and ocfs2 allow for mode in which usage is tracked (i.e. quota
> > information is kept uptodate) but limits are not enforced. I imagine this
> > might be useful in some cases and also from consistency point of view it
> > would be nice.
> >
> > In ocfs2 I implemented it so that on mount, updating of quota information
> > is enabled (when appropriate fs feature is enabled) but limits are not
> > enforced. Quotaon/quotaoff commands then toggle enforcement of quota
> > limits. XFS has mount options which decide whether quota information should
> > be kept uptodate and whether it should be enforced or not.
>
> Enabling only usage on mount makes sense. The limits can then be
> turned on using quotaon. I assume then we will also need to allow
> turning the limits off by user (instead of completely denying
> quotaoff)?
Yes.
> >> 6) With the QUOTA feature set, since the quota inodes are hidden, some of the
> >> utilities from quota-tools will no longer work correctly. Instead, e2fsprogs
> >> will include support for fixing the quota files.
> > I think it might be useful in some cases to enable only user quotas but
> > leave group quotas disabled (it slightly reduces quota overhead - mainly
> > because we have less quota structures to update on disk). So it would be
> > useful to have USRQUOTA and GRPQUOTA features separate...
> >
> It is possible to enable only one type of quotas. Instead of having
> two filesystem features, there are already two superblock fields
> s_usr_quota_inum and s_grp_quota_inum. The enabling can be disabled by
> setting the corresponding field to '0'. This is also supported via
> tune2fs:
>
> # to enable only user quotas and not group quotas:
> $ tune2fs -Q usrquota /dev/ram1 # this will set the 'quota' feature in
> superblock and initialize only usrquota inode.
>
> # to enable both user and group quotas:
> $ tune2fs -Q usrquota,grpquota /dev/ram1
Ah, I see. OK.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-08-29 23:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 19:06 [PATCH v2] ext4: make quota as first class supported feature Aditya Kali
2011-08-20 15:58 ` Andreas Dilger
2011-08-21 13:29 ` Dmitry Monakhov
2011-08-22 7:08 ` Aditya Kali
2011-08-29 20:46 ` Jan Kara
2011-09-09 15:40 ` Christoph Hellwig
2011-09-10 20:24 ` Jan Kara
2011-10-02 14:34 ` Christoph Hellwig
2011-08-29 21:57 ` Jan Kara
2011-08-29 22:42 ` Aditya Kali
2011-08-29 23:17 ` Jan Kara [this message]
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=20110829231703.GL5672@quack.suse.cz \
--to=jack@suse.cz \
--cc=adilger@dilger.ca \
--cc=adityakali@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).