Один из моих пользователей в исследовательской среде вызвал нехватку памяти на сервере, который монтирует раздел btrfs размером 52 ТБ. Мне пришлось выключить и снова включить сервер. После перезагрузки мой раздел btrfs не может быть смонтирован в режиме чтения-записи.
mount /mnt/storage/ mount: /mnt/storage: wrong fs type, bad option, bad superblock on /dev/mapper/fc_trunk-part3, missing codepage or helper program, or other error.
Журналы ядра показывают проблему с размером устройства:
Mar 19 15:10:52 mamut kernel: BTRFS error (device dm-5): open_ctree failed Mar 19 15:10:52 mamut kernel: BTRFS info (device dm-5): use lzo compression, level 0 Mar 19 15:10:52 mamut kernel: BTRFS info (device dm-5): disk space caching is enabled Mar 19 15:10:52 mamut kernel: BTRFS info (device dm-5): has skinny extents Mar 19 15:10:52 mamut systemd[1]: mnt-storage.mount: Mount process exited, code=killed, status=15/TERM Mar 19 15:10:52 mamut systemd[1]: mnt-storage.mount: Failed with result 'timeout'. Mar 19 15:10:52 mamut systemd[1]: Failed to mount /mnt/storage. Mar 19 15:10:52 mamut kernel: BTRFS error (device dm-5): super_total_bytes 52798547820544 mismatch with fs_devices total_rw_bytes 105597095641088 Mar 19 15:10:52 mamut kernel: BTRFS error (device dm-5): failed to read chunk tree: -22 Mar 19 15:10:52 mamut kernel: BTRFS error (device dm-5): open_ctree failed [...] Mar 19 15:15:52 mamut systemd-helper[9798]: IO Error (subvolume is not a btrfs subvolume). Mar 19 15:15:52 mamut systemd-helper[9798]: number cleanup for 'storage' failed. Mar 19 15:15:52 mamut systemd-helper[9798]: running timeline cleanup for 'storage'. Mar 19 15:15:52 mamut systemd-helper[9798]: IO Error (subvolume is not a btrfs subvolume). Mar 19 15:15:52 mamut systemd-helper[9798]: timeline cleanup for 'storage' failed. Mar 19 15:15:52 mamut systemd-helper[9798]: running empty-pre-post cleanup for 'storage'. Mar 19 15:15:52 mamut systemd-helper[9798]: IO Error (subvolume is not a btrfs subvolume). Mar 19 15:15:52 mamut systemd-helper[9798]: empty-pre-post cleanup for storage failed. Mar 19 15:15:52 mamut systemd[1]: snapper-cleanup.service: Main process exited, code=exited, status=1/FAILURE Mar 19 15:15:52 mamut systemd[1]: snapper-cleanup.service: Failed with result 'exit-code'.
Super_total_bytes = 52798547820544 - это правильный размер раздела в байтах, сообщаемый fdisk. fs_devices total_rw_bytes = 105597095641088 ровно в два раза больше.
Я попытался запустить проверку btrfs, но получил эту ошибку:
btrfs check /dev/mapper/fc_trunk-part3 Opening filesystem to check... Checking filesystem on /dev/mapper/fc_trunk-part3 UUID: 40a2e65b-f34a-4d33-946d-055d93fe7ffa [1/7] checking root items ERROR: failed to repair root items: Input/output error
Теперь я знаю о btrfs rescue fix-device-size, но я никогда не запускал его раньше. На странице руководства говорится:
fix-device-size
fix device size and super block total bytes values that are do
not match
Kernel 4.11 starts to check the device size more strictly and
this might mismatch the stored value of total bytes. See the
exact error message below. Newer kernel will refuse to mount the
filesystem where the values do not match. This error is not fatal
and can be fixed. This command will fix the device size values if
possible.
BTRFS error (device sdb): super_total_bytes 92017859088384 mismatch with fs_devices total_rw_bytes 92017859094528
The mismatch may also exhibit as a kernel warning:
WARNING: CPU: 3 PID: 439 at fs/btrfs/ctree.h:1559 btrfs_update_device+0x1c5/0x1d0 [btrfs]
Версия ядра изменилась после перезагрузки, но обе версии> 4.11, и раньше у меня не было проблем с монтированием этого раздела.
Раздел:
Безопасно ли звонить btrfs rescue fix-device-size?
Могу я исправить это другим безопасным способом?
"Можно ли звонить btrfs rescue fix-device-size? "
Это потенциально безопасно, и это, скорее всего, решение. Он «не должен» съесть весь ваш объем и несколько кошек. Если эта файловая система BTRFS имеет несколько дисков (например, в RAID-массиве BTRFS), я вдруг теряю уверенность в этом утверждении.
Если у вас есть механизм моментальных снимков на основе блоков ниже BTRFS (похоже, вы могли бы - это том LVM, поддерживающий его?), Тогда сделайте снимок перед этим. Возможно, вам потребуется добавить больше физических томов в эту группу томов, чтобы разместить сам моментальный снимок, в зависимости от того, как эта группа томов (если это так) уже выделена. Снимок LVM будет увеличиваться в размере по мере изменения данных пропорционально объему измененных данных. Снимок LVM также повлечет за собой двукратное снижение производительности записи в активном состоянии, поэтому не храните его после того, как закончите. Это просто для того, чтобы вы могли откатиться, если дела пойдут очень плохо.
Если это действительно важных данных, сделайте резервное копирование на основе блоков на другой, совершенно несвязанный том, прежде чем что-либо делать, особенно если вы плохо знакомы со снимками LVM или их нет на LVM. dd хорошая команда для этого.
dd if=/dev/disk/with-btrfs of=/large/enough/volume/backup.img bs=4M
У меня была аналогичная проблема с несоответствием размера между super_total_bytes и fs_devices total_rw_bytes с большим томом btrfs поверх устройства md. При попытке смонтировать при загрузке я получил сообщение BTRFS error super_total_bytes XXX mismatch with fs_devices total_rw_bytes XXXXXX. Вот ссылка на сайт, который описывает проблему и исправление запуска устройства сканирования btrfs.
В моем случае мне повезло, что он не сработал с первой попытки при загрузке, но затем успешно смонтировался, если я вручную запустил команду монтирования. Я предполагаю, что существует состояние гонки между тем, когда mdadm повторно собрал устройство / dev / md127, и когда ядро / systemd определило, что есть тома btrfs, которые нужно смонтировать. Ядро видит два диска, принадлежащих тому, потому что / dev / md127 и, скажем, / dev / sdb имеют одинаковые UUID, потому что / dev / sdb является ведущим компонентом / dev / md127, который содержит начало объем btrfs.
Я решил это, создав новый модуль systemd, btrfs-scan-device.service, это просто работает btrfs scan device, и сделал его зависимостью в /etc/fstab варианты монтирования для устройства md. Это проверяет устройства в / dev на наличие томов btrfs.
/etc/systemd/system/btrfs-device-scan.service:
[Unit]
Description=run btrfs device scan before mounting so that mdadm devices are not misdetetected
Requires=local-fs.target
After=local-fs.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/btrfs device scan
StandardOutput=journal
[Install]
WantedBy=multi-user.target
Запись в / etc / fstab:
/dev/md127 /md127 btrfs noatime,nofail,x-systemd.mount-timeout=1000,x-systemd.requires=btrfs-device-scan.service,x-systemd.after=btrfs-device-scan.service 0 0
затем systemctl daemon-reload и systemctl enable btrfs-device-scan и перезагрузитесь.
С этими изменениями у меня больше нет ошибки несоответствия размера. У меня не было ошибок ввода-вывода, которые вы видите.