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.... -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
