BTRFS не может быть смонтирован после холодной перезагрузки (total_rw_bytes вдвое больше)
Один из моих пользователей в исследовательской среде вызвал нехватку памяти на сервере, который монтирует раздел 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, и раньше у меня не было проблем с монтированием этого раздела.
Раздел:
- большой и займет много времени, и места у меня нет,для резервного копирования
- имеет важные данные для моего исследования
- имеет снимки состояния
- его можно смонтировать с помощью -o rescue, ro
Можно ли позвонить btrfs rescue fix-device-size ?
Могу ли я исправить это другим безопасным способом?
«Безопасно ли вызывать btrfs rescue fix-device-size ?»
Это потенциально безопасно, и это, скорее всего, решение. Он «не должен» съесть весь ваш объем и несколько кошек. Если эта файловая система BTRFS имеет несколько дисков (например, в BTRFS RAID), я внезапно теряю уверенность в этом утверждении.
Если у вас есть механизм моментальных снимков на основе блоков ниже 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 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 entry:
/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 и перезагрузка.
С этими изменениями у меня больше нет ошибки несоответствия размера. У меня не было ошибок ввода-вывода, которые вы видите.