[mephi-hpc] [!!Mass Mail]Re: Disk quota
Кумпан Александр
avkumpan at mephi.ru
Thu Apr 16 19:25:55 MSK 2015
Добрый вечер!
1. Мне наконец-то удалось отследить источник проблемы с такой
ошибкой. Дело в том, что vi по умолчанию при открытии документа создает
swap-файл, который, в случае чего-то непредвиденного, может быть
использован для восстановления изменений. Но если места на диске нет, он
не может ничего создать и честно об этом пишет.
Воспроизведение ошибки возможно при:
$ date
Thu Apr 16 19:14:02 MSK 2015
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 40G 25G 15G 64% /
devtmpfs 63G 0 63G 0% /dev
tmpfs 13G 864K 13G 1% /run
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
shm 51G 0 51G 0% /dev/shm
/dev/sda2 236G 236G 0 100% /home
/dev/sdb 7.3T 5.1T 1.8T 74% /mnt/storage
192.168.101.1:/home 74G 70G 3.5G 96% /mnt/unicluster/home
$ date
Thu Apr 16 19:14:04 MSK 2015
Далее, через достаточно короткий промежуток времени, диск освобождается:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 40G 25G 15G 64% /
devtmpfs 63G 0 63G 0% /dev
tmpfs 13G 864K 13G 1% /run
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
shm 51G 0 51G 0% /dev/shm
/dev/sda2 236G 236G 56K 100% /home
/dev/sdb 7.3T 5.1T 1.8T 74% /mnt/storage
192.168.101.1:/home 74G 70G 3.5G 96% /mnt/unicluster/home
$ date
Thu Apr 16 19:16:32 MSK 2015
И я снова могу редактировать файлы. Но затем:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 40G 25G 15G 64% /
devtmpfs 63G 0 63G 0% /dev
tmpfs 13G 864K 13G 1% /run
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
shm 51G 0 51G 0% /dev/shm
/dev/sda2 236G 236G 0 100% /home
/dev/sdb 7.3T 5.1T 1.8T 74% /mnt/storage
192.168.101.1:/home 74G 70G 3.5G 96% /mnt/unicluster/home
$ date
Thu Apr 16 19:16:35 MSK 2015
$
Еще через короткий промежуток времени все исправляется:
$ date
Thu Apr 16 19:18:54 MSK 2015
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 40G 25G 15G 64% /
devtmpfs 63G 0 63G 0% /dev
tmpfs 13G 864K 13G 1% /run
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
shm 51G 0 51G 0% /dev/shm
/dev/sda2 236G 236G 79M 100% /home
/dev/sdb 7.3T 5.1T 1.8T 74% /mnt/storage
192.168.101.1:/home 74G 70G 3.5G 96% /mnt/unicluster/home
$ date
Thu Apr 16 19:18:57 MSK 2015
Поэтому ошибка получается плавающей, и ее бывает очень трудно
воспроизвести.
Можно ли сделать так, чтобы, даже в случае практически полного
заполнения диска каким-либо процессом(ами), оставался какой-то
минимальный объем, который позволил бы интерактивное редактирование
небольших файлов?
2. Дополнительно:
Пусть, условно, на кластере занято 100 ядер из 300. Насколько
жестко действуют квоты по ядрам? Иными словами, сколько ядер кластер
может выделить пользователю в этом случае? Оборвет ли он, например,
попытку занять 50 ядер из свободных 200?
3. И еще такой момент.
В руководстве пользователя написано:
"/В силу ограниченности ресурсов, дисковое пространство для каждого
пользователя в $HOME ограничено размером 2 GB и количеством файлов 100
000. Ограничения можно кратковременно превышать в определённых пределах,
однако, при длительном превышении (7 дней и более) пользователь будет
автоматически заблокирован/"
Можно уточнить, в каких пределах можно кратковременно превышать
ограничения по дисковой квоте, чтобы это не противоречило правилам
работы на кластере?
On 04/13/2015 06:22 PM, anikeev wrote:
>> On Mon, 2015-04-13 at 16:21 +0300, Кумпан Александр wrote:
>>> Прошу прощения, забыл указать: ферма Basov
>>>
>>> On 04/13/2015 04:20 PM, Кумпан Александр wrote:
>>>
>>>> Уважаемая Администрация!
>>>>
>>>> Не могли бы вы помочь мне разобраться с квотами?
>>>>
>>>> Проблема возникает при работе с vi:
>>>>
>>>> 1. Запуск vi на открытие файла:
>>>>
>>>> $ vi /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>>>> E297: write error in a swap file
>>>>
>>>> 2. Попытка сохранения с любым изменением, например, поставив
>>>> комментарий:
>>>>
>>>> "runE_Bgr_DetVess_U.mac" E514: write error (file system
>>>> full?)
>>>> Press ENTER or type command to continue
>>>>
>>>> 3. В то же время, quota -s выдает:
>>>> $ quota -s
>>>> Disk quotas for user akumpan (uid 1046):
>>>> Filesystem space quota limit grace files
>>>> quota limit grace
>>>> /dev/root 20K 1954M 7813M 18
>>>> 100k 500k
>>>> /dev/sda2 80920K 1954M 9766M 1823
>>>> 100k 200k
>>>> 192.168.101.1:/home
>>>> 1163M 1954M 9766M 47053
>>>> 100k 200k
>>>>
>>>> Если я правильно понял, то я "уперся" в одну из квот. Не могли
>>>> бы вы помочь разобраться, в какую именно?
>>>> user: akumpan
>>>>
>>>>
>>>> --
>>>> С уважением,
>>>> Кумпан А.В.
>>>> Лаборатория 344
>>> --
>>> С уважением,
>>> Кумпан А.В.
>>> Лаборатория 344
>>> _______________________________________________
>>> hpc mailing list
>>> hpc at lists.ut.mephi.ru
>>> http://lists.ut.mephi.ru/listinfo/hpc
>> Добрый день!
>>
>> Проблему повторить не могу. Как Вы можете видеть, Ваши квоты на Basov не
>> исчерпаны. Первая цифра - это то, что Вы уже заняли, вторая - квота,
>> третья - предел немедленной блокировки. В случае превышения квоты Вы
>> увидите звёздочку напротив превышенного значения и grace период,
>> например:
>>
>> Disk quotas for user test (uid 1002):
>> Filesystem usage quota limit grace files quota limit grace
>> /usr 65* 50 75 5days 7 50 60
>> /usr/var 0 50 75 0 50 60
>>
>> Я зашёл под Вашим пользователем на ферму и смог успешно сохранить и
>> прочитать файл:
>>
>> master.basov anikeev # su -l akumpan
>> akumpan at master.basov ~ $ echo test > test
>> akumpan at master.basov ~ $ ls -lah test
>> -rw-r--r-- 1 akumpan users 5 Apr 13 17:54 test
>> akumpan at master.basov ~ $ cat test
>> test
>>
>> Более того, у меня получается редактировать указанный Вами файл в vim
>> (посмотрите на время редактирования):
>>
>> akumpan at master.basov ~ $ ls
>> -lah /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>> -rw-r--r-- 1 akumpan users 2.7K Apr 13
>> 15:54 /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>> akumpan at master.basov ~ $
>> vim /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>> akumpan at master.basov ~ $ ls
>> -lah /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>> -rw-r--r-- 1 akumpan users 2.7K Apr 13
>> 18:03 /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>>
>> Возможно, Вы повредили временный файл, связанный с открытым документом.
>> После его закрытия проблема могла решиться сама собой. Попробуйте ещё
>> раз. Если у Вас продолжаются проблемы, попробуйте выполнить
>>
>> strace vim /home/akumpan/RED100_git/runE_Bgr_DetVess_U.mac
>>
>> и отправить нам вывод команды.
>>
>> С уважением,
>> инженер отдела UNIX-технологий,
>> Аникеев Артём.
>
--
С уважением,
Кумпан А.В.
Лаборатория 344
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ut.mephi.ru/pipermail/hpc/attachments/20150416/844381da/attachment.html>
More information about the hpc
mailing list