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