корневая файловая система слишком мала - что предпочтительнее?
После ряда обновлений и постоянного потока программного обеспечения исходная корневая файловая система начинает раскалываться по швам. Первоначальная настройка (Notebook):
(LVM) / 17G everything but "payload" data
sda1 /boot 228M
(LVM) swap 8G
(LVM) /home xxG home directories
(LVM) /export xxxG Collections that should not clog up home directories, have a
larger backup cycle, and can be restored from external sources.
Examples. src, install, iso-images, Video, ...
Первоначально у установки lvm был запас звука для расширения существующих файловых систем по мере необходимости, но это пространство было потрачено, поэтому некоторые вещи, которые никогда не использовались, были перенесены в фоновый сервер.
Варианты обработки сжатия:
- увеличивать корневую файловую систему за счет / export
- разделить корневую файловую систему
- / var содержит растущий набор архивных пакетов в / var / cache / apt / archives
- / usr - еще одно большое подмножество для разделения - растет с каждым установленным пакетом
2 ответа
17 Гбит должны быть больше тогда достаточно для /
, Чистят Ваши архивы. sudo apt-get clean all нет никакой потребности сохранить все теми устаревший .deb
, Если Вы все еще имеете проблему с/, вычищаете Вас старые журналы.
, Если у Вас все еще есть проблема с небольшим размером Вашего корневого раздела, тогда да, необходимо добавить пространство. Можно уменьшить существующий LV или добавить дополнительный PV. Нет никакого отдельного метода или лучшей практики.
единственная потенциальная проблема с LVM состоит в том, что может быть трудно уменьшить существующее LV.
, Ваша проблема будет с таким маленьким / разделом начальной загрузки, необходимо будет постоянно удалять старые ядра. Если 17 Гбит
Tradidional рассуждает для разделения:
А root файловая система, заполненная к краю, может быть очень неизящным зверем для обработки. Таким образом потребность разделить быстрорастущие файловые системы такой как /var (В конце концов, все те файлы журнала, кэши, буферные файлы исторически были агрегированы в /var для создания этого сценария возможным)
разделение /usr, вид предшествует системам пакета - это раньше было попыткой сохранить набор только для чтения программного обеспечения со специальным отношением к бездисковому (или уменьшенный диск) клиентами.
цель того разделения состояла в том, чтобы сохранить конфигурацию системы и чрезвычайную ситуацию roadset для обслуживания системы в корневой файловой системе на систему, и совместно использовать большой блок программного обеспечения, необходимого или желаемого пользователем (пользователями) без тиражирования.
А, отдельный /var идеально, позволил корневой файловой системе быть на разделе, смонтированном только для чтения, понятие, которое все еще будет казаться желательным для использования медиа с ограниченными циклами записи.
Так в настоящий момент, это действительно кажется желательным для хранения /var отдельным, но там, кажется, не реальная выгода для хранения /usr на собственном разделе - могло бы быть более выгодно присвоить то пространство root файловая система непосредственно, сохранив издержки для отдельного раздела.