Bug 25432 - Некорректно работают квоты
Summary: Некорректно работают квоты
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-ovz-el (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Gleb F-Malinovskiy
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-12 12:02 MSK by Evgenii Terechkov
Modified: 2011-04-22 12:16 MSK (History)
15 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evgenii Terechkov 2011-04-12 12:02:05 MSK
В свежесозданной VE (5.1. обновлённый до актуального Сизифа) наблюдаю такое:

[root@test ~]# adduser teer
[root@test ~]# setquota -g teer  0 1280000 0 0 /dev/simfs
[root@test ~]# repquota -g /           
*** Report for group quotas on device /dev/simfs
Block grace time: 00:00; Inode grace time: 00:00
                        Block limits                File limits
Group           used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --       1       0       0        213950464     0 29283087024128       
wheel     --       1       0       0          32768     0 8589934592       
rpm       --       1       0       0        99897344     0 794568949760       
shadow    --       1       0       0          20480     0 12884901888       
rpc       --       0       0       0           4096     0 4294967296       
utmp      --       0       0       0           8192     0 8589934592       
nobody    --       1       0       0           4096     0 4294967296       
klogd     --       1       0       0           8192     0 8589934592       
teer      --       0       0       0         135168 1280000 133143986176       
#122880   --      32       0 8589934592              5     0     0       
#4096     --       8       0 8589934592             14     0     0       
#16384    --       4       0 4294967296             24     0     0       
#962560   --      84       0 30064771072            102     0     0       

[root@test ~]# du -sh /home/teer/
132K    /home/teer/
[root@test ~]# uname -rs
Linux 2.6.32-ovz-el-alt15

т.е. ядро некорректно возвращает что-то в юзерспейс. Считаю так потому, что на актуальном Squeeze тоже наблюдается. Начало наблюдаться по крайней мере с 2.6.32-ovz-el-alt14.
Comment 1 Evgenii Terechkov 2011-04-12 12:14:22 MSK
В смысле, на актуальном Squeeze на этой самой HN
Comment 2 aspsk 2011-04-12 17:17:57 MSK
(В ответ на комментарий №1)
> В смысле, на актуальном Squeeze на этой самой HN

А в чем ошибка?
Comment 3 Evgenii Terechkov 2011-04-12 17:44:52 MSK
Ну как же: в вызове setquota мы установили лишь жесткий лимит на _диск_ и отсутствие лимитов на inode, а в выводе repquota для этой же группы получили, что нет лимитов на диск, но зато установлены лимиты на inode (один из них точно такой, какой мы ставили на диск, а количество использованных inode якобы равно занимаемому на диске месту). Налицо путаница диск<->inode.
Comment 4 Evgenii Terechkov 2011-04-12 17:46:29 MSK
Так и обнаружил: программа, парсящая вывод repquota -g показывает дисковое пространство как "0 из 0".
Comment 5 Slava Dubrovskiy 2011-04-14 19:33:44 MSK
Аналогично и на CentOS-5.6
Пришлось собрать quota-4.00 и фигню все равно показывает
Comment 6 Slava Dubrovskiy 2011-04-14 19:45:48 MSK
Проверил где HN и VPS - сизиф.
Ядро 2.6.32-ovz-el-alt13

[root@stat-ua2 ~]# adduser slava
[root@stat-ua2 ~]# setquota -u slava  0 1280000 0 0 /dev/simfs
[root@stat-ua2 ~]# repquota -su /
*** Report for user quotas on device /dev/simfs
Block grace time: 00:00; Inode grace time: 00:00
                        Space limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --      1K      0K      0K           410m     0 46846g       
adm       --      1K      0K      0K           8192     0 8590m       
news      --      1K      0K      0K           8192     0 8590m       
ftp       --      0K      0K      0K           8192     0 8590m       
squid     --      1K      0K      0K           8192     0 8590m       
rpcuser   --      0K      0K      0K           8192     0 8590m       
rpc       --      1K      0K      0K           8192     0 8590m       
popa3d    --      1K      0K      0K           8192     0 8590m       
postgres  --      1K      0K      0K           8192     0 8590m       
ldap      --      0K      0K      0K           8192     0 8590m       
exim      --      0K      0K      0K           8192     0 8590m       
apache    --      1K      0K      0K           8192     0 8590m       
klogd     --      1K      0K      0K           8192     0 8590m       
slava     --      0K      0K      0K           144k 1280k  155g       
#8192     --      8K      0K   8192G              2     0     0
Comment 7 aspsk 2011-04-15 16:58:04 MSK
Похоже на то, что это проблема repquota. Setquota устанавливает именно то, что ее попросили установить и, например, edquota это корректно показывает. Пока могу предложить в контейнерах использовать edquota.
Comment 8 Evgenii Terechkov 2011-04-15 18:11:18 MSK
Т.е. проблема, видимо, в апстримном коде, раз воспроизводится и на ALT и на Debian с CentOS?
Comment 9 aspsk 2011-04-15 18:19:11 MSK
(В ответ на комментарий №8)
> Т.е. проблема, видимо, в апстримном коде, раз воспроизводится и на ALT и на
> Debian с CentOS?

Я еще не понял где конкретно ошибка, но факт состоит в том, что repquota
не работает в контейнере, но работает, например, в HN. Так что проблема
скорее всего в реализации vzaquota.

А на rhel5 в контейнерах все работает нормально?
Comment 10 Evgenii Terechkov 2011-04-15 18:53:59 MSK
У меня такого нет под рукой. dubrsl?
Comment 11 aspsk 2011-04-19 15:35:19 MSK
(В ответ на комментарий №9)
> (В ответ на комментарий №8)
> > Т.е. проблема, видимо, в апстримном коде, раз воспроизводится и на ALT и на
> > Debian с CentOS?
> 
> Я еще не понял где конкретно ошибка, но факт состоит в том, что repquota
> не работает в контейнере, но работает, например, в HN. Так что проблема
> скорее всего в реализации vzaquota.

См. также http://bugzilla.openvz.org/show_bug.cgi?id=1854
Comment 12 Repository Robot 2011-04-22 12:16:09 MSK
kernel-image-ovz-el-2.6.32-alt16 -> sisyphus:

* Thu Apr 21 2011 Anton Protopopov <aspsk@altlinux> 2.6.32-alt16
- VZDQUOTA: downgrade quota revision from 1 to 0 for quota version 2
  (ALT #25432, #25056)