Difference between revisions of "Disk quota, df and stat weird behaviour"
m (II, III parts reviewed and checked.) |
(Summary table is added) |
||
Line 94: | Line 94: | ||
<math>s</math> - amount of space used by not [[VE]]s private area: templates, locks, etc. | <math>s</math> - amount of space used by not [[VE]]s private area: templates, locks, etc. | ||
''' | ''' | ||
+ | {| border="1" cellpadding="5" cellspacing="0" align="center" | ||
+ | |+'''Summarizing table''' | ||
+ | | colspan="2" | Quota off | ||
+ | | <math>total_{simfs} = total_{ext2}</math> | ||
+ | <math>free_{simfs} = free_{ext2}</math> | ||
+ | |||
+ | <math>avail_{simfs} = avail_{ext2}</math> | ||
+ | |- | ||
+ | | rowspan = 3 | Quota on | ||
+ | | <math>free_{ext2} \ge quota_{limit} - quota_{used}</math> | ||
+ | <math>avail_{ext2} \ge quota_{limit} - quota_{used}</math> | ||
+ | | <math>total_{simfs} = quota_{barrier}</math> | ||
+ | |||
+ | <math>free_{simfs} = quota_{limit} - quota_{used}</math> | ||
+ | |||
+ | <math>avail_{simfs} = quota_{limit} - quota_{used}</math> | ||
+ | |- | ||
+ | | <math>free_{ext2} \ge quota_{limit} - quota_{used}</math> | ||
+ | <math>avail_{ext2} \le quota_{limit} - quota_{used}</math> | ||
+ | | <math>total_{simfs} = quota_{barrier}</math> | ||
+ | |||
+ | <math>free_{simfs} = quota_{limit} - quota_{used}</math> | ||
+ | |||
+ | <math>avail_{simfs} = avail_{ext2}</math> | ||
+ | |- | ||
+ | | <math>free_{ext2} \le quota_{limit} - quota_{used}</math> | ||
+ | <math>avail_{ext2} \le quota_{limit} - quota_{used}</math> | ||
+ | | <math>total_{simfs} = total_{ext2} - ( quota_{barrier} - quota_{usage} )</math> | ||
+ | |||
+ | <math>free_{simfs} = free_{ext2}</math> | ||
+ | |||
+ | <math>avail_{simfs} = avail_{ext2}</math> | ||
+ | |} | ||
----- | ----- | ||
TODO: add info about inconsistent quota problems | TODO: add info about inconsistent quota problems |
Revision as of 14:25, 27 November 2006
The aim of this article is to understand where the numbers that are shown by stat
/df
utils in VE come from.
Consider typical OpenVZ setup, where ext2
separate filesystem is mounted on /vz
. ext2
is called underlying filesystem in such situation.
Linux VFS design allows every filesystem to export to userspace the following information concerning disk space (here and further I use subscript to specify paricular filesystem type):
- - total amount of disk space that potentially can be acquired (e.g. HDD capacity)
- - amount of disk space that is still free
- - amount of disk space that is still available for non-root users
Note, that not all free blocks can be used by non-root users: some amount of disk space is reserved for root. For example on ext2
filesystem only root can use last free 5 percent (by default) of disk space. This is the difference between and . Also mark, that the following inequality is always true:
- (1)
Inside VE special filesystem type is used: simfs
. This filesystem allows to isolate particular VE from other VEs. Hence, when df
or stat
utils are invoked they get information from simfs
, which exports to them the following values (by analogy with ext2
):
This article is in fact devoted to how simfs filesystem calculates the values above.
To produce any calculations input data are required. What are input data for simfs
? Except already discussed information from underlying filesystem (, , ) one more element comes into force in OpenVZ environment. It is OpenVZ per-VE disk quotas. The values that provide this element are:
OpenVZ disk quota counts the number of blocks currently used by VE and prevents this number to be greater than the limit/barrier set.
Consider three basic scenarios, that are possible:
- Quota is off for VE
- If quota is off for VE (DISK_QUOTA=no), the total amount of space, that VE potentially can acquire, equals amount of total space on partition. Certainly some space can be used by other VEs, but potentially VE can have all the space on device. Number of free blocks for VE equals number of free blocks on partition. Note, that it implies that VE root user, can fill all the space, including the space, that is reserved for root user of HN. This is why, you shouldn't reside VEs private areas on root filesystem of your HN. Amount of available disk space for VE equals the number of available blocks for underlying filsystem. Thus, we have the following relationships:
- =
- =
- Rather valuable disadvantage of swithching OpenVZ quota off (besides having unlimited VEs!) is that you will not be able to get information about how much disk space is used by VE (without doing possibly long term
du
command) usingdf
/stat
. I mean, that - thus in VE you obtain information about disk usage of partition, but not disk usage of VE.
- Quota is on for VE and there is enough space on partition
- If quota is on, amount of disk space that VE potentially can acquire should be equal quota barrier:
- Amount of free space in this case should logically be the following:
- However here is a pitfall. Suppose that the amount of free disk space actually on underlying filesystem is less than it is estimated from quota using the formule above, i.e.:
- Then, definitely, amount of free disk space reported by
simfs
should be other! This situation will be considered in the next point and in this point we assume that there is enough space on partition, i.e- (2)
- As concerns amount of disk space available for non-root users, if there is enough disk space:
- then amount of disk space available for non-root users in VE equals free space estimated from quota:
- Quota is on for VE and there is NOT enough space on partition
- This is the most interesting and difficult to explain case. Nevertheless I tried to do it. So, our assumption is that:
- What should be reported as free space in such case? Of course, ! This is the actual amount of space that can be used by VE. Hence:
- And now consider the following situation. There is two VEs. One of VEs writes nothing to disk. Second VE writes to disc some information. Administrator of VE #1 looks at
df
output. He observes the "Usage" column. What does she see?- (3)
- decreases because VE #2 writes to disc, consequently increases! "What the hell is going on?!" - thinks the administrator - "Nobody writes on the disk in my VE, but the usage increases!" To avoid such situation the following approach is used in OpenVZ: decrease so, that remains the same, i.e.:
- (4)
- Substituting (4) in (3) obtain:
- In this case, administrator of VE #1 sees that total amount of space decreases, but usage however is constant.
- The same reasoning as with suits for calculating . Two cases are possible. If
- then
- and if
- then
The table below summarize all possible cases.
So we have three basic variants. Variant number one is not good, because VE administrator can't get information about VE disk usage and HN administrator can't limit VE disk usage. Variant three is not good 'cause we have some weird (but logical) values in df
/stat
output in VE, e.g. total disk space can decrease. Variant two is perfect. How can we provide this varaint always take place? Here is the simple rule:
Even if you want VE to be unlimited, consider reasonable values. Use the following formula:
- quota barrier for VE i
- total amount of space on underlying filesystem
- amount of space used by not VEs private area: templates, locks, etc.
Quota off |
| |
Quota on |
|
|
|
| |
|
|
TODO: add info about inconsistent quota problems
TODO: Add Roma's images
TODO: Add table
TODO: Add examples with stat/df