| Summary: | Некорректно работают квоты | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Evgenii Terechkov <evg> |
| Component: | kernel-image-ovz-el | Assignee: | Gleb F-Malinovskiy <glebfm> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | boyarsh, dubrsl, glebfm, kernelbot, ldv, mike, mithraen, rider, sbolshakov, shrek, sin, vitty, vsu, vt, zerg |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
В смысле, на актуальном Squeeze на этой самой HN (В ответ на комментарий №1)
> В смысле, на актуальном Squeeze на этой самой HN
А в чем ошибка?
Ну как же: в вызове setquota мы установили лишь жесткий лимит на _диск_ и отсутствие лимитов на inode, а в выводе repquota для этой же группы получили, что нет лимитов на диск, но зато установлены лимиты на inode (один из них точно такой, какой мы ставили на диск, а количество использованных inode якобы равно занимаемому на диске месту). Налицо путаница диск<->inode. Так и обнаружил: программа, парсящая вывод repquota -g показывает дисковое пространство как "0 из 0". Аналогично и на CentOS-5.6 Пришлось собрать quota-4.00 и фигню все равно показывает Проверил где 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
Похоже на то, что это проблема repquota. Setquota устанавливает именно то, что ее попросили установить и, например, edquota это корректно показывает. Пока могу предложить в контейнерах использовать edquota. Т.е. проблема, видимо, в апстримном коде, раз воспроизводится и на ALT и на Debian с CentOS? (В ответ на комментарий №8) > Т.е. проблема, видимо, в апстримном коде, раз воспроизводится и на ALT и на > Debian с CentOS? Я еще не понял где конкретно ошибка, но факт состоит в том, что repquota не работает в контейнере, но работает, например, в HN. Так что проблема скорее всего в реализации vzaquota. А на rhel5 в контейнерах все работает нормально? У меня такого нет под рукой. dubrsl? (В ответ на комментарий №9) > (В ответ на комментарий №8) > > Т.е. проблема, видимо, в апстримном коде, раз воспроизводится и на ALT и на > > Debian с CentOS? > > Я еще не понял где конкретно ошибка, но факт состоит в том, что repquota > не работает в контейнере, но работает, например, в HN. Так что проблема > скорее всего в реализации vzaquota. См. также http://bugzilla.openvz.org/show_bug.cgi?id=1854 |
В свежесозданной 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.