А если разобрать раид и собрать по новому?

Так при этом разве суперблок не будет создан заново и данные не будут покоцаны?

О! спасибо тебе добрый человек.

Итак решение простое.
Стопнуть рэйд:
mdadm -S /dev/md0

Собрать рэйд сказав ему что размер девайсов вырос (обновляем инфу в суперблоках каждого девайса):
mdadm -A /dev/md0 -U devicesize /dev/testdeb/blockdev[1-2]

После этого mdadm сможет увидеть что девайс стал больше и сможет корректно выполнить увеличение raid массива:
mdadm -G -z max /dev/md0

Ну и естественно сделает resync.

Да. я эту процедуру проделал на виртуалке линуксовой. С виндой не пробовал еще.

извращение)))

Может и так. Но если хочеться построить бюджетное решение которое будет и отказоустойчивыми и гибким, то я других вариантов не знаю... ну кроме как заменить софтверный рэйд дисков на аппаратный. А чтобы ресайзить диски виртуалок при этом иметь постоянную отказоустойчивую копию диска виртуалки я других способов не знаю. (ну да есть ISCSI... но у меня его нет)

Есть 2-а сервера на котором сконфигурировано следующее извращение:
Машина имеет 4 диска по 1 Тб.
16 Гб памяти ddr3
Установлен debian squeeze x64:

root@xen2:~# uname -a
Linux xen2 2.6.32-5-xen-amd64 #1 SMP Wed Jan 12 05:46:49 UTC 2011 x86_64 GNU/Linux

Конфигурация дисков:
первые 256 Мб + 32 Гб двух из 4 дисков использовались под raid1 разделы для /boot и swap соответственно
остальное место около 970 Гб на всех 4-ех дисках используется под raid10.
Поверх этого raid10 установлен LVM2 volume group называется xenlvm
/ , /var, /home расположены на lv небольших размеров (сейчас обнаружил, что напутал с выбором lv-ов под диры, ну да не суть):

root@xen2:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/XENLVM-home
                      9.2G  6.0G  2.8G  69% /
tmpfs                 7.6G     0  7.6G   0% /lib/init/rw
udev                  7.1G  316K  7.1G   1% /dev
tmpfs                 7.6G     0  7.6G   0% /dev/shm
/dev/md3              223M   31M  180M  15% /boot
/dev/mapper/XENLVM-var
                      9.2G  150M  8.6G   2% /home
/dev/mapper/XENLVM-root
                      9.2G  2.5G  6.3G  29% /var

Порядка 900 Гб на VG оставлены свободными для создания новых LV, которые предполагается исползовать в качестве блочных девайсов для создания raid 1 c использованием ata over ethernet: вторым блочным устройством для создания такого raid1 должен служить aoe девайс (например e0.1).
Все это нужно чтобы запускать xen-виртуалки для которых дисками будут эти самые raid1 (поверх lvm и aoe).
У машин по две сетевушки. Одной они смотрят в локалку, а вторые служат для соеденения cross кабелем со скоростью 1 Гбит/c для работы с ata over ethernet.

Сразу скажу что это богатство работает:) и довольно шустро, что приятно.

Теперь пример:
xen1 и xen2 - названия машин с одинаковой (описанной выше конфигурацией)
xenlvm - названия volume group на каждой из них
20gigs - название lvm раздела на каждой из них (соответствующего размера)
на машине xen1 том 20gigs вещается по ata over ethernet как e0.1, вот так это выглядит когда смотришь с xen2:

root@xen2:~# aoe-stat
            e0.1        21.474GB       eth0 4096  up

собираем raid1:
mdadm -C /dev/md5 --level=1 --raid-devices=2 /dev/xenlvm/20gigs /dev/etherd/e0.1

Девайс собирается на ура.
Далее я ставлю туда винду на этот раздел (с Xen-a). Винда летает (c pvops драйвером конечно).

Ну а теперь то зачем я все это писал:) :

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

Пробую:
1. увеличиваю размеры lv-ов 20gigs на xen1 и xen2.

root@xen2:~# lvextend -L+5G /dev/xenlvm/20gigs

root@xen2:~# lvdisplay  /dev/XENLVM/20gigs

--- Logical volume ---
LV Name                /dev/XENLVM/20gigs
VG Name                XENLVM
LV UUID                rp3mvd-C2Ld-S0tv-SBGE-YkyH-h2hh-5pckbr
LV Write Access        read/write
LV Status              available
# open                 0
LV Size                25.00 GiB
Current LE             6400
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     4096
Block device           253:7

Сразу добавлю, что  пришлось полностью прибить вещание девайса e0.1 на xen1 и перезапустить его заново, так как aoe-модуль судя по всему не умеет на лету менять размер вещаемых им девайсов.

2. Следующий шаг - увеличить размер /dev/md5 raid1:
его характеристики до попытки увеличения:

md5 : active (auto-read-only) raid1 dm-7[0] etherd/e0.2[1]
      20970496 blocks super 1.2 [2/2] [UU]

Увеличиваем размер:

root@xen2:~# mdadm --grow /dev/md5 --size=max
mdadm: component size of /dev/md5 has been set to 20970496K

И тут собственно мы видимо что нифига не изменилось: потому что девайс был размером 20Гб до попытки его увеличить и таким и остался.

Я было начал грешить на AoE -девайс. Но он был не виноват: я создал два тестовых lvm раздела по 5 Гб на xen2 машине , увеличил их на 2 Гб каждый. собрал из них raid1 /dev/md6. сделал mkfs.ext2 на нем. Попытался его увеличить:

root@xen2:~# mdadm --grow /dev/md6 --size=max
mdadm: component size of /dev/md6 has been set to 5241856K

Собственно та же ситуация.

После этого попробовал воспользоваться разными хаутушками с инетов:

http://www.debian-administration.org/articles/424
http://mkfblog.blogspot.com/2007/11/res … ition.html
http://www.howtoforge.com/how-to-resize … k-and-grow

Не помогло.
Я пробовал fail-ить один из разделов и увеличивать raid когда в нем 1 диск:

root@xen2:~# mdadm /dev/md6 --fail /dev/XENLVM/test2 --remove /dev/XENLVM/test2
mdadm: set /dev/XENLVM/test2 faulty in /dev/md6

затем grow:

root@xen2:~# mdadm -G /dev/md6 -z max
mdadm: component size of /dev/md6 has been set to 5241856K

Как видите тот же результат.

Есть у кого-нибудь идеи, если не утомились читать?:)