Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

[tytso@mit.edu]

On Fri, Mar 26, 2010 at 11:54:41AM +0100, Jan Kara wrote:
>   Yes, this should be a good option. I imagine we would create RO_COMPAT
> features USRQUOTA and GRPQUOTA meaning that the filesystem maintains
> quotas in hidden files. And mkfs would directly create these files if
> it was asked to.

Technically we don't even need to make this be an RO_COMPAT feature; a
COMPAT feature might suffice.  We just need to have new superblock
fields which indicate the inode numbers for the user and group quotas.
If the inode number is the reserved inode for user or group quotas,
then it's the hidden inode.  If it's the number corresponding to a
user-visible file then we simply haven't transitioned the file over.
See e2fsck to see how we handle automatically transinition a user
visible .journal file to inode #8.  That part's not hard.

I am worried about the transition to a model where quotas are always
enforced; that's quite different from what we had before.  What
happens if someone uses the command quotaoff command?  Does it turn
off quotas?  If the quota files are now hidden, a system administrator
can't use quotacheck (which is an on-line command) to fix bad quotas;
now they have to use e2fsck, which is normally an off-line checker.  I
suppose we could make e2fsck be able to run in an on-line quotacheck
mode, where it only updates quotas and accepts that there may be some
race conditions where the blocks/inodes-in-use numbers won't be
exactly right.

What about use cases where people were accustomed to letting BSD or
MacOS access an ext3 file system, and either accept the quota being
slightly off, or relying on quotacheck to fix tihngs up at some point
later?

These are all things which can be quite surprising to system
administrators...

					- Ted

P.S.  We can add a new superblock field, which is a "quota last
updated time", and if that is less than the superblock write time, it
could be a hint that e2fsck needs to do a quotacheck run.  That could
partially help address the situation of 3rd party OS's/tools accessing
the file system directly....