У нас достаточно места на другом навесном устройстве. Поскольку раздел / var остается относительно статичным с точки зрения размера (около 8-10 ГБ из-за больших журналов, которые нам нужны), я был бы счастлив просто заполнить наше текущее пространство / var на 65%, а не на 75%. Другими словами, нам не нужно много двигаться. Вот снимок того, что там сейчас:
4.0K ./account 119M ./cache 0 ./clamd 292M ./cpanel 8.0K ./crash 12M ./csectsh 528M ./data 16K ./db 16K ./empty 6.1G ./lib 4.0K ./local 24K ./lock 1003M ./log 16K ./lost+found 0 ./mail 120K ./named 4.0K ./nis 4.0K ./opt 8.0K ./portsentry 20M ./pravda 4.0K ./preserve 84K ./profiles 236K ./run 115M ./spool 470M ./tmp 4.0K ./yp
Мы только что перераспределили кучу вещей на нашем производственном сервере, поэтому мне не хочется планировать больше простоев, тем более что я считаю, что у нас есть SLA с клиентом. Я знаю, что у многих родительских процессов этих файлов будут проблемы с символьными ссылками, но я далек от эксперта, так как это унаследованная система. Кто-нибудь знает верные ставки на вещи, которые могут двигаться?
мне бы сильно Предлагаем не использовать символические ссылки, а вместо этого использовать привязку.
Таким образом, пространство четко отслеживается, а не становится более бессмысленным, как с символическими ссылками.
http://aplawrence.com/Linux/mount_bind.html имеет хорошее вступление для привязки маунтов.
Вероятно, у вас есть MySQL в / var / lib - переместите его в другое место или установите для него новый диск. Вы можете либо создать символическую ссылку, либо изменить конфигурацию MySQL.
Что в ./data? Это нестандартный каталог и выглядит хорошим кандидатом. Я также предлагаю вам глубже изучить ./lib. Что-то там занимает много места и может быть удалено или перемещено.