RAID программного обеспечения с ext4, но без поддержки на 64 бита
в прошлом году я настроил программное-обеспечение-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 - это даже возможно без переформатирования?
но ни одно из этих "решений" достаточно хорошо не документировалось/тестировалось или не было опцией как указано выше, таким образом, я теперь застреваю с a /dev/md0 из 18 ТБ, содержащих ext4 файловую систему только с 15 ТБ и 3 ТБ свободного пространства. У кого-либо есть идея, что еще я мог try/do/consider?
Я столкнулся с точно таким же SNAFU на аппарате CentOS 6. Мое ядро имеет 64-битную поддержку, но файловая система изначально не была отформатирована с набором 64-битных флагов. Нет поддержки >16TB. :-( Могу подтвердить, что 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 ТБ, иначе вам понадобится и внешнее хранилище в миксе.
.