Date:	Tue, 30 Aug 2011 01:17:03 +0200
From:	Jan Kara <jack@...e.cz>
To:	Aditya Kali <adityakali@...gle.com>
Cc:	Jan Kara <jack@...e.cz>, adilger@...ger.ca, tytso@....edu,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2] ext4: make quota as first class supported feature

On Mon 29-08-11 15:42:36, Aditya Kali wrote:
> On Mon, Aug 29, 2011 at 2:57 PM, Jan Kara <jack@...e.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@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists