linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).