lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGr1F2EXgaWVywbRUUdOhPmvv3ZXwt1nnOpkyuBgygSYvJ+h-A@mail.gmail.com>
Date:	Mon, 29 Aug 2011 15:42:36 -0700
From:	Aditya Kali <adityakali@...gle.com>
To:	Jan Kara <jack@...e.cz>
Cc:	adilger@...ger.ca, tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2] ext4: make quota as first class supported feature

Thanks for your feedback.


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.

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

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


>                                                                Honza

--
Aditya
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ