Программный RAID с ext4, но без поддержки 64 бит

В прошлом году я установил Software-RAID5 с 5x3 ТБ, что дает 12 ТБ полезной емкости. Только сегодня, когда мне понадобилось больше памяти, я закончил наращивать RAID до двух дисков объемом 3 ТБ:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[7] sde1[6] sdb1[4] sda1[5] sdc1[2] sdg1[1] sdf1[0]
      17580801024 blocks super 1.2 level 5, 512k chunk, algorithm 2 [7/7] [UUUUUUU]

unused devices: <none>

Это означает, что теперь у меня должно быть приблизительно 6x3 ТБ = 18 ТБ /dev/md0, resize2fsВызванный без параметра размера, теперь сказал мне, что новый размер невозможен в 32-битном режиме. Некоторые исследования показали, что это обычная проблема, которую нелегко решить без особых усилий, что я не хочу делать.

tune2fs подтвердил, что 64bit-флаг действительно отсутствовал:-(хотя в конфигах auto_64-bit_support = 1 установлен (и должен был быть установлен при создании файловой системы). Но бесполезно ныть о чем-то, что я не могу потом изменить.

К сожалению, полное резервное копирование и восстановление - это не вариант (я знаю, что должна существовать резервная копия всех данных, но денег на резервное копирование действительно важной части достаточно).

Затем я попытался изменить размер файловой системы до 16 ТБ с resize2fs -S 128 /dev/md0 16T который, казалось, работал, но вернулся с ошибкой, сообщившей, что на устройстве недостаточно места, и посоветовав запустить e2fsck -fy /dev/md0 - странная вещь. Мое сердце стучало как сумасшедшее, пока этот чек не вернулся хорошо! Говоря, чтобы изменить размер 15T работал, хотя.

Я думаю, что мы можем прожить около 15 ТБ в течение еще нескольких месяцев, но примерно 3 ТБ без дела - это то, что мне действительно не нравится. Мой вопрос сейчас, как я могу использовать эти 3 ТБ. Мои направления исследований были

  • Преобразование в btrfs, которое, кажется, поддерживает файловые системы размером более 16 ТБ и возможно без цикла резервного копирования / восстановления - но разные источники говорят, что это ненадежно и не должно использоваться в производстве.
  • Разметка /dev/md0 создать вторую файловую систему на оставшихся 3 ТБ - кажется невозможным (тип таблицы разделов loop)
  • Настройка LVM - возможно ли это даже без переформатирования?

но ни одно из этих "решений" не было достаточно хорошо задокументировано / протестировано или не было вариантом, как указано выше, поэтому я застрял с /dev/md0 из 18 ТБ, содержащая файловую систему ext4 с только 15 ТБ и 3 ТБ свободного места. У кого-нибудь есть идея, что еще я мог бы попробовать / сделать / рассмотреть?

Источник

1 ответ

Я столкнулся с точно таким же SNAFU на компьютере с CentOS 6. Мое ядро ​​имеет 64-битную поддержку, но файловая система изначально не была отформатирована с установленным 64-битным флагом. Нет>16 ТБ поддержки.:-(Я могу подтвердить, что tune2fs здесь не поможет. Вы не можете преобразовать файловую систему ext2/3/4 в 64-битную.

Однако мне повезло, что я использую LVM поверх массива MD, поэтому я немного прибавил пространство к массиву, создав еще один LV с свободным пространством в массиве MD и отформатировав его. что с использованием 64-битной опции. Затем я перемещаю некоторые данные из старой в новую файловую систему, затем сокращаю старую файловую систему, изменяю размер (сокращаю старые, увеличиваю новые) группы томов LVM, увеличиваю 64-разрядную файловую систему и повторяю (несколько раз), Это не идеально, но я рекомендую переразбить массив md и сделать это таким образом. Это возможно. (GParted будет очень полезен здесь)

Чтобы обратиться к вашим направлениям исследований, исходя из моего опыта сисадмина:

  • Преобразование в BTRFS, вероятно, не вариант. Как показывают документы, BTRFS все еще находится в разработке (даже 3.12, которая включена в ядро ​​3.1) и не должна использоваться для хранения критических (а не резервных) данных. Хотя нечего предположить, что ваша файловая система спонтанно повредила себя, это немного опаснее, чем использование ext4.

  • Разбиение - это путь, и он намного проще с такими инструментами, как GParted. На LVM еще проще...

  • Вы можете установить LVM и попробовать сторонний инструмент под названием Blocks для преобразования массива md (блочного устройства) в группу томов и хранилищ LVM. Это сделает перераспределение и изменение размера немного легче. Хотя вам не нужно конвертировать корневую файловую систему, этот инструмент может помочь в создании LVM. Я бы ошибался, если бы не пошел по этому маршруту в случае, если что-то станет FUBAR. Я бы тренировался заранее на испытательном стенде.

Возможно, просто придерживайтесь переразметки (и ручного форматирования вашего нового раздела с помощью mkfs.ext4 -O 64bit ....) с помощью GParted и перемещайте данные вручную. Убедитесь, что все ваши файлы имеют размер < 3 ТБ, в противном случае вам также понадобится внешнее хранилище в миксе.

Источник
Другие вопросы по тегам