Починка second-level квоты без остановки машины
У нас часто бывает, что квота второго уровня для какого-то пользователя сбивается. Уж не знаю, по каким причинам это происходит, но - факт налицо: с машиной извне ничего не делается, а квота оказывается посчитана неверно (причем включая квоту в ядре, как показывает vzquota stat -t). Например, я только что зашел внутрь виртуальной машины и удалил 3 больших AVI-файла, созданных пользователем с группой 42526, а групповая квота не пересчиталась: [внутри виртуальной машины]# quota -g 42526 Disk quotas for group *** (gid 42526): Filesystem blocks quota limit grace files quota limit grace /dev/simfs 6472396* 0 46080 1824 0 50000 vzquota stat -t показывает те же самые цифры для 42526. Я запускал lsof и убедился: удаленные файлы никто открытыми не держит. Итак, вопросы: 1. Можно ли как-то "на лету" пересчитать квоты для конкретного пользователя? Уж очень не хочется каждый раз из-за одного юзера останавливать целую виртуальную машину... 2. Можно ли определить, что файл квот в настоящий момент является "битым"? 3. Сейчас для группы 42526 не только квоты не обновились, но еще они и не учитываются (т.е. удается успешно создавать под ней файлы). У меня есть догадка: возможно, файл квот в настоящий момент является "битым", и ядро, зная об этом, даже не пытается использовать какие-либо лимиты. Может такое быть?
Re: Починка second-level квоты без остановки машины
1. проверять правильная ли quota нужно после остановки VPS. ядро делает многие оперции асинхронно, поэтому и реальный disk usage меняется вовсе не тогда, когда вы думаете. 2. а вот рассказ про удачное создание файла, превышающего квоту - интересный. Можете рассказать поподробнее? У Вас это воспроизводится?
да, забыл спросить, а у вас квота 2-го уровня включена? для этого надо поставить например QUOTAUGIDLIMIT=500 в vps.conf или воспользоваться соответствующей опцией vzctl set, а затем перегрузить VPS.
Что касается того, почему удавалось создать файл, превышающий квоту - действительно, надо было запустить quotaon / внутри виртуальной машины (это вообще-то делается в rc3.d - странно, что оно не запустилось при старте), так что это ложная тревога. Простите, не могли бы Вы все же ответить на вопросы: 1. Починить квоты, не останавливая виртуальную машину, нельзя. Верно? 2. Можно ли определить, что файл квот в настоящий момент является "битым"?
1. нельзя, ядро само считает квоты. если квоты были правильными при старте VPS, то они будут правильными все время, т.к. ядро их обновляет. соответственно, если чинить и надо, то при старте. чинить можно с полмощью vzquota init или новой командой vzctl quotainit (vzctl-3.0.0-6). 2. нет, к сожалению, ни в стандартной linux quota, ни в OVZ, понять что цифры в квоте не соответствуют реальному disk space usage нельзя например, выкючили квоту, поменяли файлы, включили квоту.
ОК, все ясно. На самом деле, очень жаль, что нельзя на лету пересчитывать. Теоретически же это возможно сделать: сборсить все счетчики квот в ядре, начать подсчет, а как только подсчет закончится, приплюсовать сюда еще и счетчики из ядра (положительные или отрицательные, если файлы были удалены). Можно это даже делать не спеша по cron-у. Возможно, реализация данного метода связано с какими-то другими техническими сложностями.
к сожалению, это не возможно все изменения асинхронны. чтобы вы не насчитали в user space и ядре, складывать эти величины будет нельзя. т.е. сделать результат достоверно правильным при таком подходе нельзя