У меня 3ware 9650se с 2 дисками по 2 ТБ в топологии raid-1.
Недавно я заменил диски на 2 больших (3 ТБ), один за другим. Вся миграция прошла гладко. Проблема, с которой я столкнулся сейчас, заключается в том, что я не знаю, что еще мне нужно сделать, чтобы система знала об увеличении размера этого диска.
Некоторая информация:
root@samothraki:~# tw_cli /c0 show all
/c0 Model = 9650SE-4LPML
/c0 Firmware Version = FE9X 4.10.00.024
/c0 Driver Version = 2.26.02.014
/c0 Bios Version = BE9X 4.08.00.004
/c0 Boot Loader Version = BL9X 3.08.00.001
....
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-1 OK - - - 139.688 Ri ON
u1 RAID-1 OK - - - **1862.63** Ri ON
VPort Status Unit Size Type Phy Encl-Slot Model
------------------------------------------------------------------------------
p0 OK u0 139.73 GB SATA 0 - WDC WD1500HLFS-01G6
p1 OK u0 139.73 GB SATA 1 - WDC WD1500HLFS-01G6
p2 OK u1 **2.73 TB** SATA 2 - WDC WD30EFRX-68EUZN0
p3 OK u1 **2.73 TB** SATA 3 - WDC WD30EFRX-68EUZN0
Обратите внимание, что диски p2 & p3 правильно определены как 3 ТБ, но массив raid1 u1 все еще видит массив 2 ТБ.
Следуя руководству по Кодовый набор LSI 3ware 9650se 10.2 (примечание: руководство пользователя codeset 9.5.3 содержит точно такую же процедуру).
Я тройной sync мои данные и umount рейдовый массив u1. Затем я удаляю массив raid из командной строки с помощью команды:
tw_cli /c0/u1 remove
и, наконец, я повторно просматриваю контроллер, чтобы снова найти массив:
tw_cli /c0 rescan
к сожалению новый u1 массив по-прежнему идентифицировал диск 2 ТБ.
Что могло быть не так?
Некоторая дополнительная информация. в u1 массив соответствует dev/sdb/ , что, в свою очередь, соответствует физическому тому большего LVM-диска. Теперь, когда я заменил оба диска, оказалось, что таблица разделов пуста. И все же диск LVM работает нормально. Это нормально ?!
root@samothraki:~# fdisk -l /dev/sdb
Disk /dev/sdb: 2000.0 GB, 1999988850688 bytes
255 heads, 63 sectors/track, 243151 cylinders, total 3906228224 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@samothraki:~#
хорошо, этот ответ добавляется к grs's ответ. так что кредиты идут туда за 70% ответа.
Ноты:
резюмируйте ситуацию:
Таким образом, ключ состоит в том, чтобы удалять по одному диску и каждый раз воссоздавать новый массив. . В общем и целом:
разделить массив raid1. Это сгенерирует 2 массива со старым размером дисков (в моем случае 2 ТБ).
tw_cli /c0/u1 migrate type=single
драгоценный /dev/sdX который указывал на raid1 /u1, все еще должен существовать (и работать!). и вы также получите новый юнит /u2 который основан на 2-м приводе зеркала.
удалить диск зеркала, который больше не используется (принадлежит новому устройству) /u2 в моем случае и должен был приобрести новый /dev/sdX дескриптор файла после перезапуска).
tw_cli /c0/u2 del
создать новый single блок с неиспользуемым диском. ПРИМЕЧАНИЕ. Я выполнил этот шаг из BIOS, поэтому не уверен, что именно так следует делать, как я указываю ниже. В BIOS я сделал «создать модуль», а не «перенести». Кто-нибудь, пожалуйста, подтвердите это.
tw_cli /c0/u2 migrate type=single disk=3
новый /u2 устройство должно «видеть» все 3 ТБ.
вперед и перенесите данные с диска 2 ТБ на диск 3 ТБ.
как только данные будут на новом устройстве, обновите все ссылки на новый / dev / sdX.
оставшийся диск емкостью 2 ТБ (должен быть!) теперь не используется, поэтому удалите его.
tw_cli /c0/u1 del
создать новый single блок с неиспользуемым диском.
tw_cli /c0/u1 migrate type=single disk=2
новый /u1 теперь у устройства должно быть 3 ТБ.
наконец, сделайте глубокий вдох и объедините 2 отдельных диска в новый расширенный raid1
tw_cli /c0/u2 migrate type=raid1 disk=2
/u1 должен исчезнуть, а единица /u2 следует начать восстановление.
Наслаждаться жизнью. Серьезно.
Вам нужно будет обновить u1 size перед увеличением файловой системы изнутри ОС. Последний не «увидит» новый размер, пока контроллер 3ware не уведомит об этом.
Увеличение единичной мощности в 3ware называется миграцией. Я уверен, что это работает для RAID5 и 6, не пробовал с RAID1. Вот пример выполнения команды миграции:
# tw_cli /c0/u1 migrate type=raid1 disk=p2-p3
Когда это завершится fdisk -l /dev/sdb должен дать 3 ТБ и vgdisplay <VG name> перечислит пустое место. Оттуда вы увеличите размер VG, затем соответствующий LV и, наконец, файловую систему внутри LV.
Изменить: Я думаю, вам не повезло - см. Стр. 129 на Гид пользователя.
Вы можете перенести свой RAID1 на другой тип массива.
Вот альтернатива (это связано с определенным риском, поэтому убедитесь, что ваши резервные копии в порядке):
tw_cli /c0/u1 migrate type=single - это разобьет ваш u1 агрегат на два одинарных привода;tw_cli /c0/u1 migrate type=raid1 disk=2-3 - этот должен перенести единый блок обратно на RAID1 с правильным размеромКонечно, есть альтернативные подходы к этому, тот, который я перечислил выше, предназначен на тот случай, если вы хотите, чтобы ваши данные всегда были в сети.
Возможно, ваше ядро не получало обновлений от контроллера.
Попробуйте обновить информацию о дисках, набрав:
partprobe /dev/sdb
Это заставит ядро перечитать таблицы разделов и свойства дисков.
Также попробуйте:
hdparm -z /dev/sdb
и / или:
sfdisk -R /dev/sdb
потому что partprobe не всегда работает ...
Вкратце и вкратце - обратитесь в службу поддержки LSI, чтобы получить сценарий миграции.
Я почти уверен, что у меня один и тот же контроллер в конфигурациях с 2 и 4 портами, и когда я хотел обновить с 1 Gig Raid 1 до 2 Gig, я заменил один из дисков на 2 Gig, а затем заменил другой диск после восстановления.
На данный момент у меня еще был 1 Гиг Raid 1, но сидящий на 2 Гиговых дисках. Затем я отправил в LSI некоторые сведения о размерах дисков в качестве запроса поддержки, а они, в свою очередь, прислали мне (очень Technical), который при запуске выполнил миграцию за меня.
Я никогда не был удовлетворен, почему эту миграцию нельзя выполнить без поддержки LSI, но в конце концов все прошло нормально.
Это всего лишь несколько примечаний к nass's ответ. Исходя из памяти, так что это может быть не совсем правильно, и на этих этапах была произведена некоторая перезагрузка.
Шаги 1-2: 🗸
Шаг 3. Добавление нового single блок из cli: tw_cli /c0 add type=single disk=3
Шаг 4: я использовал dd if=/dev/sdX of=/dev/sdY bs=64K клонировать диск. Чтобы определить, какие устройства были правильными, перед шагом 3 я попытался установить некоторые устройства (например, sudo mount -t ntfs /dev/sda1 /mnt/a) и изучая содержимое, чтобы узнать, какое устройство было моим источником из модуля /c0/u1. (Вероятно, есть лучший способ определить это.)
Также перед шагом 3 я ls /dev/sd*, отметили, на каком устройстве уже есть sdY1 но нет sdY, а затем после шага 3 еще раз проверьте, для чего sdY был создан. Я также использовал sudo hdparm -I /dev/sdY на каждом устройстве до / после шага 3, чтобы убедиться, что все в порядке. ПРИМЕЧАНИЕ: Перезагрузка может изменить, какое устройство является каким, поэтому избегайте этого между проверкой и dd'ing.
Шаги 5-6: 🗸
Шаги 7-8: Создание нового отдельного устройства из неиспользуемого диска и последующая миграция у меня не сработали (Invalid disk ошибка или что-то в этом роде). Вместо этого следует пропустить шаг 7 и сразу перейти к шагу 8.
Шаг 9: Подойдет. Спасибо за помощь!
Некоторые другие заметки из моего опыта с этим:
Для большей части этого я использовал Knoppix Live CD. Чтобы установить на него tw-cli:
sudo nano /etc/apt/sources.list
Добавить deb http://hwraid.le-vert.net/ubuntu precise main на вершине.
sudo apt-get update
sudo apt-get install tw-cli 3dm2
Я делал это на загрузочном диске установки Windows, переходя с дисков 2 ТБ на диски 4 ТБ. Перед запуском я забыл проверить, является ли диск MBR или GPT. Оказывается, это была MBR, а это означает, что я не могу получить доступ к большей части дополнительного места на диске без преобразования в GPT.