не удается возобновить LV после изменения размера

Вопрос или проблема

Я пытался изменить размер точки монтирования на моем разделе. У меня достаточно свободного места на диске, мне просто нужно было увеличить /dev/mapper/var_log с 50G до 230G.

Я изменил размер своего физического тома sda3, чтобы получить свободное место на sda, затем сделал lvextend для var_log.

lvs показывает, что var_log был изменен, но df-h все еще показывает его как 50G.

[root@NAME me]# lvs
  WARNING: Device /dev/sda3 has size of 225017856 sectors which is smaller than corresponding PV size of 666892288 sectors. Was device resized?
  WARNING: One or more devices used as PVs in VG rhel_name have changed sizes.
  LV            VG              Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home          rhel_name -wi-ao---- 1012.00m
  root          rhel_name -wi-ao----   37.00g
  swap          rhel_name -wi-ao----    5.91g
  tmp           rhel_name -wi-ao----    3.90g
  var           rhel_name -wi-ao----    5.00g
  var_log       rhel_name -wi-so----  231.00g
  var_log_audit rhel_name -wi-ao----    3.00g
  var_tmp       rhel_name -wi-ao----  496.00m

[root@name me]# df -h
Filesystem                                 Size  Used Avail Use% Mounted on
devtmpfs                                   4.0M     0  4.0M   0% /dev
tmpfs                                      5.8G   48M  5.7G   1% /dev/shm
tmpfs                                      2.3G  916K  2.3G   1% /run
efivarfs                                   256K   58K  194K  23% /sys/firmware/efi/efivars
/dev/mapper/rhel_name-root            37G  2.0G   35G   6% /
/dev/mapper/rhel_name-home           948M   39M  910M   5% /home
/dev/mapper/rhel_name-var            5.0G  332M  4.7G   7% /var
/dev/sda2                                  960M  226M  735M  24% /boot
/dev/mapper/rhel_name-tmp            3.9G   60M  3.8G   2% /tmp
/dev/sda1                                  599M  7.1M  592M   2% /boot/efi
/dev/mapper/rhel_name-var_tmp        432M   29M  404M   7% /var/tmp
/dev/mapper/rhel_name-var_log         51G  729M   51G   2% /var/log
/dev/mapper/rhel_name-var_log_audit  3.0G  142M  2.8G   5% /var/log/audit
tmpfs                                      1.2G     0  1.2G   0% /run/user/1000

Я также получал это сообщение, когда расширил логический том.

  WARNING: Device /dev/sda3 has size of 225017856 sectors which is smaller than corresponding PV size of 666892288 sectors. Was device resized?
  WARNING: One or more devices used as PVs in VG rhel_name have changed sizes.
  Size of logical volume rhel_name/var_log changed from 51.00 GiB (13056 extents) to 231.00 GiB (59136 extents).
  device-mapper: resume ioctl on  (253:2) failed: Invalid argument
  Unable to resume rhel_name-var_log (253:2).
  Problem reactivating logical volume rhel_name/var_log.
  Releasing activation in critical section.
  libdevmapper exiting with 1 device(s) still suspended.

Я только начинаю работать в Linux, поэтому не уверен, как решить это или что я сделал неправильно.

Спасибо за вашу помощь

Ответ или решение

Решение проблемы, связанной с невозможностью возобновления работы логического тома (LV) после его изменения, может быть сложной задачей, особенно для начинающего пользователя Linux. В данном случае вы сталкиваетесь с ошибкой, имеющей отношение к изменению размеров разделов и логических томов на диске. Давайте рассмотрим теоретические основы, возможные причины проблемы и шаги для её решения.

Теория

В системе Linux Logical Volume Manager (LVM) предоставляет гибкость в управлении дисковыми пространствами через концепцию физических и логических томов. Физические тома (Physical Volumes, PV) объединяются в группы томов (Volume Groups, VG), из которых затем создаются логические тома (Logical Volumes, LV). Логические тома могут быть динамически изменены и перераспределены на нескольких физических устройствах. Однако при изменении размера физического или логического тома могут возникнуть некоторые проблемы, если все этапы не выполняются правильно.

Пример

В вашем случае вы попытались увеличить размер логического тома /dev/mapper/rhel_name-var_log с 50G до 230G, расширив сначала физический том /dev/sda3. Несмотря на то, что команда lvextend показала, что размер тома был увеличен, команда df -h всё ещё показывала старый размер 50G. Более того, вы получили предупреждение и ошибку о том, что изменить размер не удалось, и устройство /dev/sda3 остался значительно меньше в секторах по сравнению с размером использованного физического тома.

Применение

Для решения проблемы вам нужно выполнить несколько шагов:

  1. Проверка и исправление физических томов (PV):

    • Убедитесь, что физический том /dev/sda3 действительно расширен. Используйте команду pvresize для обновления информации о размере.
      pvresize /dev/sda3
    • Убедитесь, что физический том теперь отображает корректный размер через pvdisplay.
  2. Убедитесь, что логический том (LV) правильно расширен:

    • Проверьте, действительно ли были созданы необходимые расширения для логического тома. Использование команды lvdisplay поможет вам увидеть текущее состояние логического тома.
  3. Расширение файловой системы:

    • Даже после того как логический том расширен, сама файловая система нуждается в расширении, чтобы использовать новое дисковое пространство. В зависимости от типа файловой системы используйте соответствующие команды.
    • Для файловой системы ext4:
      resize2fs /dev/mapper/rhel_name-var_log
    • Для файловой системы xfs используйте:
      xfs_growfs /var/log
  4. Проверка ошибок и повторная активация логического тома:

    • После всех изменений убедитесь, что логический том доступен. Попробуйте выполнить деактивацию и повторную активацию тома:
      lvchange -an /dev/rhel_name/var_log
      lvchange -ay /dev/rhel_name/var_log
    • Проверьте вывод на наличие ошибок.
  5. Проверка и сообщение о состоянии:

    • После завершения всех шагов используйте lvs, pvs, и df -h, чтобы подтвердить корректность всех изменений.

Заключение

Ваша проблема, скорее всего, связана с тем, что логический том был расширен, но файловая система осталась прежнего размера, что и привело к сбою. Правильное выполнение всех указанных шагов должно помочь вам решить данную проблему. Если вы продолжаете сталкиваться с трудностями, возможно, имеются дополнительные аппаратные ограничения или ошибки конфигурации, которые требуют более глубокого анализа. В случае необходимости не стесняйтесь обращаться за помощью к более опытным профессионалам или в сообщество Linux, предоставляя как можно более полные детали проблемы.

Оцените материал
Добавить комментарий

Капча загружается...