The Quota feature
The quota feature causes the quota files (i.e., user.quota and group.quota which existed in the older quota design) to be hidden inodes, so they can not be corrupted by user space progams. Instead, these inodes are managed directly via e2fsprogs, and quota will be automatically as soon as the file system is mounted. This way, it strongly reduces the possibility that the usage tracking performed by the file system will get out of sync.
Support for the quota feature first appeared in the 3.6 upstream kernel version. There is a bug which will not be fixed until v3.8 which will cause ext4 to fail to mount a file system with quotas if the quota code is built as a module. So users who wish to experiment with this feature are strongly encouraged to build with the following configuration options:
Support for the quota feature first appeared in e2fsprogs 1.42, although it is not enabled by default. It must enabled via a compile-time configuration option, --enable-quota. There are bug fixes which have been applied in various 1.42.x maintenance branch releases, so users who wish to experiment with the quota feature are strongly encouraged upgrade to the latest e2fsprogs 1.42.x maintenance release. As of this writing the following bugs are still in e2fsprogs 1.42.7, which means use of file systems with the quota feature in production can not be recommended:
- The e2fsck check of the on-disk quota inodes won't notice if there is a missing uid record. (i.e., if some uid, say daemon owns a bunch of files, but that uid record is not in the quota inode, e2fsck won't say boo.)
2) If e2fsck *does* notice a discrepancy between the usage information recorded in the hidden quota inodes, and the actual number of blocks used by a particular user id or group id, it will overwrite the user or group quota inode with all of the information it has. Unfortunately, in the process it will zero out all of the current quota limits set. This is unfortunate....