Безопасное уменьшение логического тома LVM с файловой системой Btrfs

Безопасное уменьшение логического тома LVM с файловой системой Btrfs

Старая статья. В тот момент я ещё не знал, что btrfs сам способен подменить LVM. Я отнёсся к ней, как к обычной файловой системе.

2019-12-26

Я произвёл несколько опытов по сжатию LVM тома с Btrfs на борту и сделал для себя следующие выводы.

Описание безопасного способа

Самый безопасный способ заключается в следующем: с LVM2 использовать ext4 с возможностью уменьшения и увеличения тома. Или использовать надёжную xfs с возможностью только увеличения тома. Или всё-таки использовать btrfs, но без попыток уменьшать том, то есть, как и в случае с xfs, только увеличивать том.

Сейчас могу дополнить, что при попытках уменьшить btrfs-том на LV, который занимает несколько PV, то от потери данных нас отделяет один шаг. Будет логичнее, если занимать несколько PV (и при необходимости освобождать PV), используя средства btrfs. То есть добавлять/удалять в/из существующего btrfs-тома дополнительные PV или даже разделы блочных устройств (не учавствующие в LVM2), без использования прослойки LV.

Так как LVM2 не может отследить границы занятого Btrfs пространства на томе, то безопасней произвести сокращение Btrfs до меньших значений, чем задуманный уменьшенный размер тома. Не забыть сделать сброс кэша командой sync и подождать какое-то время для физического завершения этого процесса. Потом, после последующего сокращения тома командой lvresize, произвести расширение Btrfs с опцией max для заполнения всего выделенного пространства.

Пример уменьшения размера тома с Btrfs.

В данном примере том /dev/vg/btrfs-tmp примонтирован к директории /mnt/tmp. Сначала уменьшим Btrfs на 1100MiB. Затем уменьшим том LVM на 1GiB. И в конце увеличим Btrfs на ~100Mib, чтобы занять всё доступное дисковое пространство.

Для операции уменьшения размера Btrfs необходимо, чтобы ФС была примонтирована, то есть все операции делаются онлайн. При задании размеров дискового пространства параметром m или M, независимо от регистра оба символа указывают на МебиБайт.

Команда lvresize ... выдаёт предупреждение, что возможно нарушение целостности данных. Не обращаем внимания на это сообщение, так как, предположительно, понимаем что делаем и контролируем ситуацию.

# btrfs filesystem resize -1100m /mnt/tmp
# sync 
# lvresize -L -1000m /dev/vg/btrfs-tmp
# btrfs filesystem resize max /mnt/tmp

Команда уменьшения размера btrfs может закончиться неудачей ERROR: unable to resize '/mnt/tmp': No space left on device. Это происходит из-за недостатка свободного места на Btrfs, даже если команда btrfs filesystem usage показывает достаточно свободного места. После прочтения FAQ Btrfs приходит понимание, что с free space на томах Btrfs всё сложнее, чем кажется.

Как я это проверял

  1. Создавался том размером один GiB.
  2. Том форматировался mkfs.btrfs с опцией --mixed.
  3. На отформатированном томе для его полного заполнения создавалось два файла.
  4. Вычислялись хэши файлов с помощью sha256sum.
  5. Удалялся первый файл.
  6. Производилась операция уменьшения Btrfs.
  7. Давалась команда sync.
  8. Производилась операция уменьшения LV.
  9. Вычислялись хэши файлов с помощью sha256sum.

Пару раз я намеренно установил размер тома на один экстент (PE) меньше, чем выделил под Btrfs. Последующая проверка sha256sum завершилась ошибкой чтения файла. Вновь отодвинув границу тома на один экстент больше, то есть вернув файловой системе доступ к отнятым ранее 4Mib, я повторил вычисление хэша файла, которое на это раз завершилось успешно с верным результатом.

Bear in mind

Если помнить, что LVM выделяет дисковое пространство блоками по умолчанию, Physical Extent (PE), по 4MiB, то можно вычислить точные значения новых границ Btrfs и тома с точностью до одного PE.

Минимальный размер файловой ситемы Btrfs составляет 109MiB. Из-за размера PE в 4MiB, попытка уменьшить размер тома до 109MiB командой lvresize приведёт к уменьшению тома до 112MiB, о чём будет указано в выводе команды.

Есть вероятность, что администратор при добавлении Физического Тома (PV) в Группу Томов (VG) указал другой размер PE. То есть для точного вычисления новых границ Btrfs и LV необходимо сначала получить информацию о размере PE командой pvdisplay.

Отсюда следует, что безопасней следовать совету из первого абзаца.

mkfs.btrfs

-M|--mixed

Normally the data and metadata block groups are isolated. The mixed mode will remove the isolation and store both types in the same block group type. This helps to utilize the free space regardless of the purpose and is suitable for small devices. The separate allocation of block groups leads to a situation where the space is reserved for the other block group type, is not available for allocation and can lead to ENOSPC state.

The recommended size for the mixed mode is for filesystems less than 1GiB. The soft recommendation is to use it for filesystems smaller than 5GiB. The mixed mode may lead to degraded performance on larger filesystems, but is otherwise usable, even on multiple devices.