LINUX.ORG.RU
ФорумAdmin

mdadm расширение объема

 


0

2

Перенес RAID1 с дисков по 640ГБ на диски по 1Тб средствами Clonezilla.
Массив как положено остался размером 640ГБ
Далее команда:

mdadm --grow /dev/md0 --size=max
никаких сообщений не возвращает и изменение массива не происходит
resize2fs /dev/md0
Выдает:
resize2fs 1.40.4 (31-Dec-2007)
The filesystem is already 151161584 blocks long.  Nothing to do!
Все действия выполнял в single mode с отмонтированным массивом.
Как расширить массив на весь диск?



Последнее исправление: IceTony (всего исправлений: 2)

Ответ на: комментарий от anonymous

на обоих дисках? массив не развалится?

IceTony
() автор топика

У тебя там не gpt случаем?

У меня с такой разметкой были проблемы при переезде на больший диск. Надо было с помощью fdisk чинить размер, чтобы «увидеть» хвост диска.

Radjah ★★★★★
()

Перенес RAID1 с дисков по 640ГБ на диски по 1Тб средствами Clonezilla.

Вы массив как собирали - из целых дисков (/dev/sda и /dev/sdb, например), или из разделов (/dev/sda1 и /dev/sdb1)?

Если второй вариант, то выше верно посоветовали - начать надо с увеличения разделов.

на обоих дисках? массив не развалится?

Да, при правильном увеличении - не развалится.

Впрочем, можно все манипуляции и с одним диском проводить, имея второй в качестве бекапа на случай ошибки. После успешного увеличения массива второй диск можно очистить и подсунуть в массив в качестве hotspare для восстановления избыточности.

Но насколько я понял, у Вас и так есть бекап (массив на исходных дисках), так что для Вас это неактуально.

Serge10 ★★★★★
()
Ответ на: комментарий от IceTony

Массив собран из разделов sda2 и sdb2

Т. е. на дисках есть и другие разделы (как минимум, sda1 и sdb1)?

В таком случае, как уже написано выше, Вам необходимо увеличивать сами разделы, из которых RAID собран. Если помимо sda1 и sdb1 есть и другие «посторонние» разделы, то перед увеличением 2 раздела их двигать придется, если, конечно, данные, расположенные на них, нужны.

Ну и присоединяюсь к вопросу anc - нужны данные о таблице разделов исходных дисков и Ваши представления о том, что должно получиться в итоге.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Там сначала корень sda1 и sdb1 идут, потом sda2 и sdb2 и все.
Перед увеличением разделов средствами resize2fs нужно ли выводить их из массива?

IceTony
() автор топика
Ответ на: комментарий от IceTony

Там сначала корень sda1 и sdb1 идут, потом sda2 и sdb2 и все.

Все-таки покажите fdisk -l на новом массиве

Перед увеличением разделов средствами resize2fs нужно ли выводить их из массива?

Надеюсь вы про изменение фс а не самих разделов. Конечно не нужно, у вас раздел /dev/md0 на нем fs, resize2fs изменяет размер фс.

anc ★★★★★
()
Ответ на: комментарий от IceTony

Перед увеличением разделов средствами resize2fs нужно ли выводить их из массива?

Resize2fs увеличивает размер файловой системы. Сейчас у нас с Вами речь об увеличении размера разделов диска. Если то, что Вы говорите о таблице разделов, соответствует истине (надежнее было бы последовать совету anc и привести вывод команды fdisk -l вместо словесного описания), то достаточно просто удалить разделы sda2 и sdb2 и создать их заново с теми же начальными секторами и до конца диска. После этого Вы увеличиваете размер самого RAID (mdadm --grow) и только потом дело доходит до увеличения файловой системы (resize2fs).

Диски выводить из массива не нужно.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

А можно и еще проще, т.к. речь в топике про офлайн, скопировать на вновь созданный раздел обычным cp

anc ★★★★★
()
Ответ на: комментарий от anc

т.к. речь в топике про офлайн, скопировать на вновь созданный раздел обычным cp

IMHO, это займет гораздо больше времени, чем описанные выше процедуры.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

С уже полученным вариантом, да, согласен. Тем более если завели в прод.(Хотя кто так будет делать если не получилось? Лучше оставить старые и тестировать отдельно)
А так, перелить максимум 640Гб на одной машинке не так уж и долго. ТС уже делал такое один раз. Просто повторить.

anc ★★★★★
()
Ответ на: комментарий от Serge10

fdisk -l:

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        2550    20482843+  fd  Linux raid autodetect
/dev/sda2            2551       77825   604646437+  fd  Linux raid autodetect

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1        2550    20482843+  fd  Linux raid autodetect
/dev/sdb2            2551       77825   604646437+  fd  Linux raid autodetect
Удалить и создавать заново sda2, sdb2 нет возможности, так как на них свежая инфа.

IceTony
() автор топика
Ответ на: комментарий от Radjah

извините за глупый вопрос, разве тут ни как в винде?)) удаление раздела ведет к полной потере данных

IceTony
() автор топика
Ответ на: комментарий от IceTony

Удаление раздела - это удаление записи в MBR. Данные на диске не затираются.

В винде таким образом пересоздавать раздел не пробовал.

На деле fdisk перезапишет только таблицу разделов.

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

Все понял, значит делаю так:

umount /dev/md0

fdisk /dev/sda
d sda2
n sda2
fdisk /dev/sdb
d sdb2
n sdb2

mdadm --grow /dev/md0 --size=max

resize2fs /dev/md0
ничего не забыл?

IceTony
() автор топика
Ответ на: комментарий от Radjah

Что то пошло не по плану) после:

fdisk /dev/sda
d sda2
n sda2
fdisk /dev/sdb
d sdb2
n sdb2
массив вообще исчез, теперь по новой его создавать через mdadm --create /dev/md0?
При создании массива с диска же данные сотрутся?

IceTony
() автор топика
Ответ на: комментарий от IceTony

статус какой у рейда?

cat /proc/mdstat
может просто стартовать его?
mdadm --start /dev/md0
предварительно проверь что с разделами
mdadm --examine /dev/sda2
mdadm --examine /dev/sdb2

fbiagent ★★★
()
Ответ на: комментарий от fbiagent
cat /proc/mdstat

в списке вообще не стало этого рейда...

mdadm --create /dev/md0 --level=1 --raid-disks=2 missing /dev/sda2
появился, все ок, добавил второй диск
mdadm --add /dev/md0 /dev/sdb2
синк пошел, теперь размер массива увеличился, я так понимаю --grow уже делать не нужно?
осталось только после синка выполнить
resize2fs /dev/md0

IceTony
() автор топика
Ответ на: комментарий от IceTony

Что то пошло не по плану) после:

Скорее всего, Вы забыли поменять тип разделов на fd (Linuх autoraid). Это команда t в fdisk. По умолчанию при создании нового раздела ему присваивается тип 83 (Linux).

Serge10 ★★★★★
()
Ответ на: комментарий от IceTony

mdadm --create /dev/md0

Не было у бабы забот, купила баба порося.

Зачем заново создавать? Собрать его с missing вместо одного диска.

Radjah ★★★★★
()
Ответ на: комментарий от Deleted

а ведь предлагался нормальный способ в предыдущем треде :)

Morin ★★★★
()
Ответ на: комментарий от Radjah

я так и сделал, все норм, все получилось)

IceTony
() автор топика
23 февраля 2020 г.
Ответ на: комментарий от Radjah

Я тоже сейчас буду менять в массиве диски на большего объёма, с 3 на 4Тб. Пробежался по теме, не очень понял, какие действия мне делать, а какие нет. У меня gpt раздел на весь объём диска, новые диски будут на Тб больше. Нужно ли вручную копировать раздел как это сделал топикстартер? Ведь массив сам должен продублироваться на новый диск?

В противном случае придется подымать ещё один рейд рядом и просто копировать с rsync, но хотелось бы по уму прокачать скилл с raid.

hikikomori ★★★
()
Ответ на: комментарий от hikikomori

ИМХО как минимум придётся склонировать один диск, изменить размер GPT, изменить размер раздела, поднять массив с одним диском и добавить раздел со второго диска.

Я бы для начала на виртуалке проверил, чтобы потом не было мучительно больно.

Radjah ★★★★★
()
Ответ на: комментарий от hikikomori

размер раздела должен быть больше, чем размер зеркала

вот у тебя зеркало на двух дисках 3ТБ + 3ТБ, ты добавишь два диска по 4ТБ

3ТБ+3ТБ+4ТБ+4ТБ, но на новых дисках реально будет задействовано 3ТБ, когда ты удалишь диски по 3ТБ, у тебя будут два диска 4ТБ+4ТБ, но размер зеркала будет 3ТБ хотя диски (разделы по 4ТБ)

вот тогда и приходит время для mdadm –grow …

futurama ★★★★★
()
Ответ на: комментарий от Radjah

Нет ресурсов на виртуалки, у меня это выльется в пошаговую стратегию. Если не разберусь в теории, то придется городить лишний огород в железе.

hikikomori ★★★
()
Ответ на: комментарий от futurama

Это я логически понял, спасибо что подробно объяснили, и что никаких подводных камней и плясок с бубном?
А участие resize2fs тут не нужно?

Странно что не спросили, обычно в подобных темах сразу спрашивают: нет, lvm нет.

hikikomori ★★★
()
Ответ на: комментарий от futurama

Ну вот, я же говорил, это не полный список действий, что я ещё не знаю? начнёшь тележку толкать, как уже состав потянется.

hikikomori ★★★
()
Ответ на: комментарий от hikikomori

Ты спросил про рейд. Это одно, просто блочное устройство. Что на нем, lvm, разделы, фс, … неизвестно. Кроме того увеличение размера рейда завязано только на него самого. Увеличишь рейд, потом смотри кто следующий на увеличение.

futurama ★★★★★
()
Ответ на: комментарий от Radjah

Удаление раздела - это удаление записи в MBR. Данные на диске не затираются.

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

Jurik_Phys ★★★★★
()
Последнее исправление: Jurik_Phys (всего исправлений: 1)
Ответ на: комментарий от Jurik_Phys

исчезает вся информация о том, что это были за файлы и где.

С какого перепуга она исчезает, если редактор разделов туда ничего не пишет?

Создаешь заново раздел с началом в том же месте и концом по границе старого раздела или далее, и ПРОИСХОДИТ ЧУДО! Данные опять доступны!

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

Хм, всегда для восстановления раздела использовал testdisk, для управления разделами gparted. «Чуда» не замечал, но надо будет протестировать, интересный момент.

Всё верно, в сети есть экспримент тыц.

Jurik_Phys ★★★★★
()
Последнее исправление: Jurik_Phys (всего исправлений: 1)
Ответ на: комментарий от futurama

Кажется всё идёт по плану...
Единственное, что показалось сложным, это диллема первичности
mdadm --grow над resize2fs и что расширять, /md0 или /sdd1.

Опишу ход своих мыслей, вдруг кому потом пригодится.

Удалось логикой догадаться самому - у sdd1 и sdc1 размер изначально был 4Тб, малый размер был у зеркала с 3Тб, которое склонировалось на новый диск, следовательно менять размер надо у массива. И чтобы не делать пустую работу дважды, я занялся этим между первым копированием со старого рейда на один новый диск и заменой оставшегося старого на новый. Таким образом сейчас клонируется новый массив на 4Тб на второй новый 4Тб диск. Старые два диска полностью выведены из raid и физически отключены от системы.

sudo mdadm --grow /dev/md0 --size=max
mdadm: component size of /dev/md0 has been set to 3906884608K

sudo resize2fs /dev/md0                                                                             
resize2fs 1.45.5 (07-Jan-2020)                                                                                                                
Filesystem at /dev/md0 is mounted on /mnt/R'lyeh; on-line resizing required                                                                   
old_desc_blocks = 350, new_desc_blocks = 466                                                                                                  
The filesystem on /dev/md0 is now 976721152 (4k) blocks long.     

Я ограничился тем, что выключил на всё время миграции приложение хранящее файлы в массиве. Конечно надо было демонтировать массив, но на удивление в онлайне всё прошло быстро и и без проблем.

Но перед добавлением диска в массив приходится отключать самосмонтировавшийся диск:
sudo parted /dev/sdd unit s p free  # уточняю что sdd указан правильно.
sudo umount --verbose --all-targets /dev/sdd1


И завершающий шаг, добавляю в массив из одного диска его второго собрата wd red 4tb:
sudo mdadm --manage /dev/md0 --add /dev/sdd1
mdadm: added /dev/sdd1


Сейчас идёт recovery aka spare rebuilding. Продлится примерно 4-5 часов и всё. Кстати, старые диски TOSHIBA DT01ACA300 в процессе recovery на новый red сильно тормозили систему, а новые нет. Смотрю каталоги и запускаю файлы без задежки. Это или сильные ошибки убитых сервером тошиб, либо многопоточная магия wdred)

hikikomori ★★★
()
Ответ на: комментарий от Radjah

А вот запоздалый вопрос, скажите, как вообще узнать, сколько времени ушло на [>....................] recovery = 4.3% ? Вот допустим когда я запустил я примерно помню, а когда завершилось, это я тогда уже спал)

sudo mdadm --detail /dev/md0 даёт только Update Time, когда было начато последнее обновление массива, а когда закончилось, как узнать?

hikikomori ★★★
()
Ответ на: комментарий от Radjah

А других способов нет? Про прошлый раз ничего не пишет, сейчас снова массив на новые диски зеркалирую, и тоже не ясно:

sudo dmesg |grep md0
[    3.199015] md/raid1:md0: active with 1 out of 2 mirrors
[    3.230284] md0: detected capacity change from 0 to 3000453038080
[    3.694858] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
[  578.447012] md: recovery of RAID array md0
[  586.200351] md: md0: recovery interrupted.
[  586.391366] md: recovery of RAID array md0


Вот 586.391366 это по-человечески что такое? Я думал там дата будет. Не люблю dmesg, так и не научился его готовить, лучше бы текстовые конфиги были.

hikikomori ★★★
()
Последнее исправление: hikikomori (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.