3

So all the tutorials and documentation for the Linux quota system has left me confused. For each filesystem with quotas enabled/on where is the actual quota information stored? Is it filesystem metadata or is it in a file?

Say user foo creates a new file on /home. How does the kernel determine whether user foo is below their hard limit? Does the kernel have to tally up quota information on that filesystem each time or is it in the superblock or somewhere else?

As far as I understand, the kernel consults the aquota.user file for the actual rules, but where is the current quota usage data stored? Can this be viewed with any tools outside repquota and the like? TIA!!

Update:

Thanks for the help. I had already read that mini-HOWTO. I am pretty clear on the usage of the user space tools. What I was unclear on is whether the usage data was ALSO in the file that stored per-user limits and you answered this with a yes.

From what I can tell, rc.sysinit runs quotacheck and quotaon on startup. The quotacheck program analyzes the filesystem, updates the aquota.* files. It then makes use of quota.h and the quotactl() syscall to inform the kernel of quota info.

From this point forward the kernel hashes that information and increments/decrements quota stats as changes occur. Upon shutdown, the init.d/halt script runs the quotaoff command RIGHT before the filesystems are unmounted. The quotaoff command does not appear to update the aquota.* files with the information the kernel has in memory. I say this because the {a,c,m}times for the aquota.user file are only updated upon a reboot of the system or by manual running the quotacheck command. It appears - as far as I can tell - that the kernel just drops it's up-to-date usage data on the floor at shutdown. This information is never used to update the aquota.* files. They are updated during startup by quotacheck(rc.sysinit). Seems silly to me since that updated info had already been collected by the kernel. So...in conclusion I am still not entirely clear on the methods. ;)

2 Answers 2

3

For each filesystem with quotas enabled/on where is the actual quota information stored?

See e.g. the quotaon manpage. There will be files named .quota* in the filesystem root directory, which contain the necessary information (.quota.user,.quota.group, .quota.ops.user, .quota.ops.group).

Say user foo creates a new file on /home. How does the kernel determine whether user foo is below their hard limit? Does the kernel have to tally up quota information on that filesystem each time or is it in the superblock or somewhere else?

No, the kernel continually tracks fs usage, so it does not need to recalculate that on each allocation (which would be prohibitively expensive). It will do the calculation once when quotas are enabled, and then update that. The initial calculation is performed by quotacheck.

As far as I understand, the kernel consults the aquota.user file for the actual rules, but where is the current quota usage data stored? Can this be viewed with any tools outside repquota and the like? TIA!!

Quota information is stored in .quota* (see above). I'm not aware of any tools to generate quota usage reports, apart from repquota. But you should be able to generate most reports using/scripting repquota. Or you'll have to hack the source...

BTW:

The Quota mini-HOWTO give a good overview over the Linux quota system. It's a bit dated, but the fundamentals have not changed much.

1
  • Thanks, updated post. Wouldn't mind it if you or someone else could clarify on the updated info in the post. Mar 1, 2010 at 11:34
1

From reading through your update it seems that you're wondering about why all the quota info the kernel has would be tossed when the machine is shut down instead of written to the aquota.* files.

Well, the kernel doesn't update the file on the fly since this would be expensive in terms of time. Basically once quotas are enabled the kernel tracks usage in case a soft/hard limit is reached and it has to do something, this means that it's tracking this every time it has to allocate any fs blocks for any user/group on the system. If it then had to update the aquota.* files while attempting to allocate fs blocks you could see where this would end up causing problems on even moderately busy systems, and it's not needed since the kernel is watching this for you and will log any transgressions for you, so you know to come run quotacheck. Even the quota calculation can cause issues, which is why you have the tunable sysctl - dquot-max - and the reporting sysctl - dquot-nr - more info can be seen here:

http://www.mjmwired.net/kernel/Documentation/sysctl/fs.txt

As for the placement of quotacheck during the init process and not the halt process, it's all about time and how you think of things. Usually when you halt a server you want it to go down, fast. Not spend a bunch of time tabulating quotas, we're a lot more accustomed to init's taking longer. Also, think of this process as init setting up the initial quota counts when the system started, rather than cleaning up as it's shutting down. What if the FS's were mounted on another system without quotas enabled then restarted normally, you'd want to know where you're starting from everytime, and since you're going to init after every halt that's where it's setup.

Hope that helps.

1
  • 1
    I wasn't saying the kernel should update the file on each and every change, that would OBVIOUSLY be too expensive (that would make atime updates look good). I was confused though as to why the kernel can't update the file when the system is being shutdown, one operation. Now obviously the kernel isn't in the business of modifying system files directly, but if a syscall existed to dump the up-to-date quota information then a userspace quota utility could be called on system shutdown and possibly eliminate the need for time consuming quotacheck runs on boot. May 14, 2010 at 6:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .