I`ve been googling around for quite some time to find out how the Linux
quota system works. Unfortunately there is no definite source of
information on Linux quotas accessible on the net. That's why I have
decided to post a message to this list. I'd like to know the general
idea behind the Linux quota implemenation. Digging through the net I have
gathered some information that allowed me to create a coherent (I thought
so, anyway) image how quota might work, however my assumptions have been
contradicted by later findings. Here is my "version" how Linux quota
works (I assume that quota has been already configured):
"plain" quota: Each time the system boots 'quotacheck' command is being
run which updates the 'aquota.' files for the relevant filesystems with
the usage information gathered reading blocks allocation structures on
those filesystems. Quotas are being turned on and the kernel reads usage
information from 'aquota.' files. While the operating system is up and
running and new filesystem storage is being allocated to files or released
only the kernel tracks the usage information without updating the usage
information contained within the 'aquota.' files (such updates would be
"expensive"). Therefore as the operating system uptime grows the usage
information maintaned by the kernel and the usage information withing
'aquota.' files become more and more out of sync. When the system shuts
down the kernel does not update 'aquota.' files with the usage
information that it has. It doesn't do so because 'aquota.' files can not
be the authoritative source of usage information as it is possible that
the system can be booted with quotas disabled and then the usage
information contained within 'aquota.' files will become obsolete and
when the system is booted with quotas enabled it has no way to find out
that there previous periods when it was up and quota was disabled.
Therefore on each system boot 'quotacheck' command has to be run to
synchronize usage information gathered "browsing" through the filesystem
(which is the only authoritative source of information on usage)
with that contained in the 'aquota.' files and in that scenario updating
by the kernel 'aquota.*' files at system shutdown is redundant as this
action will overlap with the 'quotacheck' command run at system boot which
can not be avoided.
journaled quota: same as above with the difference that 'aquota.' files
are being updated by the kernel on the fly as it is much less "expensive"
as compared to "plain" quota. Also it is much less likely that 'aquota.'
files can become corrupted when the system is shut down uncleanly.
Anyway, with both "plain" quota and journaled quota 'quotacheck' command
has to be run at system start-up as the filesystem/filesystems for which
quotas are enabled can be the only authoritative source of information on
usage. And when I was 99% sure about the assumptions that I have made
above I looked at the quota initialization script in Debian 6.0 (Squezee)
('/etc/init.d/quota') and to my surprise I have found out that during
system start-up 'quotacheck' command is only run in two situations, that
is when the system was shut down uncleanly and when "quota is new" (I
assume quota has been configured, but no 'aquota.*' files exist yet), but
it seems that 'quotacheck' command is definitely not run on each boot
which is inconsistent with my 'mental image' how quota should work. So,
I'm puzzled here. I would really appreciate if anyone could elaborate on
the doubts that I have regarding quota implementation on Linux.
Best regards,
Przemyslaw Tokarski
National Centre for Nuclear Research
Department of Cosmic Ray Physics
Lodz, Poland
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for late reply. I forgot about your email...
"plain" quota: Each time the system boots 'quotacheck' command is being run which updates the 'aquota.'
This isn't quite true. Quotacheck(8) is run only when unclean shutdown is detected.
files for the relevant filesystems with the usage information gathered reading blocks allocation structures on those filesystems. Quotas are being turned on and the kernel reads usage information from 'aquota.' files.
This is correct.
While the operating system is up and running and new filesystem storage is being allocated to files or released only the kernel tracks the usage information without updating the usage information contained within the 'aquota.' files (such updates would be "expensive").
This isn't correct. Quota information is tracked by kernel and written to 'aquota.' files when QUOTAOFF or QUOTASYNC commands are run. That's why we don't have to run quotacheck(8) after clean shutdown.
Therefore as the operating system uptime grows the usage information maintaned by the kernel and the usage information withing 'aquota.' files become more and more out of sync. When the system shuts down the kernel does not update 'aquota.' files with the usage information that it has. It doesn't do so because 'aquota.' files can not be the authoritative source of usage information as it is possible that the system can be booted with quotas disabled and then the usage information contained within 'aquota.' files will become obsolete and when the system is booted with quotas enabled it has no way to find out that there previous periods when it was up and quota was disabled.
It is true that you can boot the system without quotas or you can simply turn quotas off while users are still using the fs and thus usage information gets out of sync. But quota system in general doesn't try to guard against such administration failures.
journaled quota: same as above with the difference that 'aquota.' files are being updated by the kernel on the fly as it is much less "expensive" as compared to "plain" quota. Also it is much less likely that 'aquota.' files can become corrupted when the system is shut down uncleanly.
With journaled quota, usage information in 'aquota.' files is updated as a part of a filesystem transaction doing the space allocation. Thus when a journal is replayed after a system crash, also space usage information in 'aquota.' files is properly updated. quotacheck(8) has to be run only in cases when fsck(8) finds some fs corruption and has to modify the filesystem.
Last edit: Jan Kara 2013-11-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
would you mind to develop a little more on the subject bellow?
"quotacheck(8) has to be run only in cases when fsck(8) finds some fs corruption and has to modify the filesystem."
For instance, shall the normal journal replay after a crash be always considered a modification of the filesystem in this regard?
We would like to avoid quotacheck at all, because in our case, it takes up to 1 hour to complete. However, as long as I've seen in init.d scripts on debian and centos, quotacheck is currently always executed after a system crash, no matter what is the exit code from fsck.
Any insights on whether it is safe to disable quotacheck in debian/centoOS init scripts (e.g. when the return status is 0 and 1) are welcome.
Best regards,
Luciano
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Journal replay isn't a modification of the filesystem which requires quotacheck to run. When quota is journaled, it has the same properties as any other filesystem metadata (quota changes are recorded in the journal along with other metadata modifications). Thus quotacheck is needed if and only if you need to run fsck manually to correct some errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello list!!
I`ve been googling around for quite some time to find out how the Linux
quota system works. Unfortunately there is no definite source of
information on Linux quotas accessible on the net. That's why I have
decided to post a message to this list. I'd like to know the general
idea behind the Linux quota implemenation. Digging through the net I have
gathered some information that allowed me to create a coherent (I thought
so, anyway) image how quota might work, however my assumptions have been
contradicted by later findings. Here is my "version" how Linux quota
works (I assume that quota has been already configured):
"plain" quota: Each time the system boots 'quotacheck' command is being
run which updates the 'aquota.' files for the relevant filesystems with
the usage information gathered reading blocks allocation structures on
those filesystems. Quotas are being turned on and the kernel reads usage
information from 'aquota.' files. While the operating system is up and
running and new filesystem storage is being allocated to files or released
only the kernel tracks the usage information without updating the usage
information contained within the 'aquota.' files (such updates would be
"expensive"). Therefore as the operating system uptime grows the usage
information maintaned by the kernel and the usage information withing
'aquota.' files become more and more out of sync. When the system shuts
down the kernel does not update 'aquota.' files with the usage
information that it has. It doesn't do so because 'aquota.' files can not
be the authoritative source of usage information as it is possible that
the system can be booted with quotas disabled and then the usage
information contained within 'aquota.' files will become obsolete and
when the system is booted with quotas enabled it has no way to find out
that there previous periods when it was up and quota was disabled.
Therefore on each system boot 'quotacheck' command has to be run to
synchronize usage information gathered "browsing" through the filesystem
(which is the only authoritative source of information on usage)
with that contained in the 'aquota.' files and in that scenario updating
by the kernel 'aquota.*' files at system shutdown is redundant as this
action will overlap with the 'quotacheck' command run at system boot which
can not be avoided.
journaled quota: same as above with the difference that 'aquota.' files
are being updated by the kernel on the fly as it is much less "expensive"
as compared to "plain" quota. Also it is much less likely that 'aquota.'
files can become corrupted when the system is shut down uncleanly.
Anyway, with both "plain" quota and journaled quota 'quotacheck' command
has to be run at system start-up as the filesystem/filesystems for which
quotas are enabled can be the only authoritative source of information on
usage. And when I was 99% sure about the assumptions that I have made
above I looked at the quota initialization script in Debian 6.0 (Squezee)
('/etc/init.d/quota') and to my surprise I have found out that during
system start-up 'quotacheck' command is only run in two situations, that
is when the system was shut down uncleanly and when "quota is new" (I
assume quota has been configured, but no 'aquota.*' files exist yet), but
it seems that 'quotacheck' command is definitely not run on each boot
which is inconsistent with my 'mental image' how quota should work. So,
I'm puzzled here. I would really appreciate if anyone could elaborate on
the doubts that I have regarding quota implementation on Linux.
Best regards,
Przemyslaw Tokarski
National Centre for Nuclear Research
Department of Cosmic Ray Physics
Lodz, Poland
Sorry for late reply. I forgot about your email...
"plain" quota: Each time the system boots 'quotacheck' command is being run which updates the 'aquota.'
This isn't quite true. Quotacheck(8) is run only when unclean shutdown is detected.
files for the relevant filesystems with the usage information gathered reading blocks allocation structures on those filesystems. Quotas are being turned on and the kernel reads usage information from 'aquota.' files.
This is correct.
While the operating system is up and running and new filesystem storage is being allocated to files or released only the kernel tracks the usage information without updating the usage information contained within the 'aquota.' files (such updates would be "expensive").
This isn't correct. Quota information is tracked by kernel and written to 'aquota.' files when QUOTAOFF or QUOTASYNC commands are run. That's why we don't have to run quotacheck(8) after clean shutdown.
Therefore as the operating system uptime grows the usage information maintaned by the kernel and the usage information withing 'aquota.' files become more and more out of sync. When the system shuts down the kernel does not update 'aquota.' files with the usage information that it has. It doesn't do so because 'aquota.' files can not be the authoritative source of usage information as it is possible that the system can be booted with quotas disabled and then the usage information contained within 'aquota.' files will become obsolete and when the system is booted with quotas enabled it has no way to find out that there previous periods when it was up and quota was disabled.
It is true that you can boot the system without quotas or you can simply turn quotas off while users are still using the fs and thus usage information gets out of sync. But quota system in general doesn't try to guard against such administration failures.
journaled quota: same as above with the difference that 'aquota.' files are being updated by the kernel on the fly as it is much less "expensive" as compared to "plain" quota. Also it is much less likely that 'aquota.' files can become corrupted when the system is shut down uncleanly.
With journaled quota, usage information in 'aquota.' files is updated as a part of a filesystem transaction doing the space allocation. Thus when a journal is replayed after a system crash, also space usage information in 'aquota.' files is properly updated. quotacheck(8) has to be run only in cases when fsck(8) finds some fs corruption and has to modify the filesystem.
Last edit: Jan Kara 2013-11-04
...thank You very much for the response. It definitely explains a lot.
Best regards,
Przemyslaw Tokarski
National Centre for Nuclear Research
Department of Cosmic Ray Physics
Lodz, Poland
Hello Jan,
would you mind to develop a little more on the subject bellow?
"quotacheck(8) has to be run only in cases when fsck(8) finds some fs corruption and has to modify the filesystem."
For instance, shall the normal journal replay after a crash be always considered a modification of the filesystem in this regard?
We would like to avoid quotacheck at all, because in our case, it takes up to 1 hour to complete. However, as long as I've seen in init.d scripts on debian and centos, quotacheck is currently always executed after a system crash, no matter what is the exit code from fsck.
Any insights on whether it is safe to disable quotacheck in debian/centoOS init scripts (e.g. when the return status is 0 and 1) are welcome.
Best regards,
Luciano
Journal replay isn't a modification of the filesystem which requires quotacheck to run. When quota is journaled, it has the same properties as any other filesystem metadata (quota changes are recorded in the journal along with other metadata modifications). Thus quotacheck is needed if and only if you need to run fsck manually to correct some errors.
Thank you!
Best regards.