3

Я пробовал btrfs и заметил какое-то забавное поведение:

У меня есть два диска в конфигурации raid 1.

sudo btrfs fi show
Label: none  uuid: 52b9c6f6-ce5c-4727-861e-e2fd012e475f
    Total devices 2 FS bytes used 251.16GiB
    devid    1 size 298.09GiB used 252.01GiB path /dev/sdi
    devid    2 size 298.09GiB used 252.01GiB path /dev/sdh

Как вы можете видеть, они настроены как mdata=raid1, data=raid1:

sudo btrfs fi df /btr/.fsroot/
Data, RAID1: total=251.00GiB, used=250.57GiB
System, RAID1: total=8.00MiB, used=64.00KiB
Metadata, RAID1: total=1.00GiB, used=597.47Mi

Теперь, если мне не удается /dev/sdh (например, вытащить кабель sata), все работает как положено,

sudo btrfs fi show
Label: none  uuid: 52b9c6f6-ce5c-4727-861e-e2fd012e475f
    Total devices 2 FS bytes used 251.16GiB
    devid    1 size 298.09GiB used 252.01GiB path /dev/sdi
    *** Some devices missing

файловая система даже не подключена. Но что меня беспокоит, так это то, что происходит, если я терплю неудачу /dev/sdi: 

Label: none  uuid: 52b9c6f6-ce5c-4727-861e-e2fd012e475f
    Total devices 2 FS bytes used 251.16GiB
    devid    1 size 298.09GiB used 252.01GiB path /dev/sdi
    devid    2 size 298.09GiB used 252.01GiB path /dev/sdh

Так что в основном неисправный диск вообще не обнаруживается. Это даже нельзя исправить запуском btrfs device scan . Итак, как я могу обнаружить в производственной среде, что моего рейда больше нет?

|источник

1 ответ1

0

Вы очистили файловую систему BTRFS? Скраб должен прочитать и проверить все доступные копии. И рекомендуется запланировать скраб, например, как ежемесячный cronjob, так что вы будете получать уведомления.

Для справки в будущем: К сожалению, BTRFS, похоже, не может обнаружить неисправный диск "в рабочем состоянии", то есть, когда файловая система смонтирована (*).
Я предполагаю, что они не думали о серверных системах, которые работают месяцами или даже годами, не отключаясь. Будем надеяться, что это уже исправлено (пока вы читаете это)...

*: Цитирование записи в списке рассылки от 09/2015:

Разница в том, что у нас есть код для обнаружения устройства, отсутствующего при монтировании, у нас нет кода (пока), чтобы обнаружить его падение в смонтированной файловой системе. Почему правильное обнаружение исчезновения устройства не является приоритетом, я понятия не имею, но это отдельная проблема от поведения монтирования.

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html

ZFS, например, поймет, что диск, к которому необходимо получить доступ, пропал, и пометит его как неисправный. Для сервера, использующего BTRFS, возможно, было бы неплохо иметь пользовательскую проверку (задание cron), которая отправляет предупреждение, если хотя бы один из дисков в массиве RAID больше не доступен ...

Ухудшение монтирования . Любой, кто удаляет диск вручную для имитации сбоя, вероятно, подумает о монтировании файловой системы в деградированном режиме (например, для использования « btrfs replace »). Монтирование в ухудшенном (rw) режиме может быть опасным, оно может даже привести к потере данных, если вы не позаботитесь о повторной синхронизации вашей файловой системы (баланс):

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

Гораздо хуже, если вы не вычищаете и не балансируете, а затем повторяете тест, переставляя устройство, чтобы оно пропало. Теперь у вас есть несколько устройств, которые были rw, деградированы и смонтированы заново, и это повредит всю файловую систему.

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46519.html

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .