Всем привет!
Есть вопросик про mdadm:
Я собирал на lvm-е raid-1 размером 20G
как-то так:
lvcreate -L20g -n lv1 lvgroup
lvcreate -L20g -n lv2 lvgroup
mdadm -C /dev/md666 --level=1 --raid-devices=2 /dev/lvgroup/lv1 /dev/lvgroup/lv2
Потом ставил туда виртуалкой xen винду.
Потом ради эксперимента решил проверить как оно будет работать на новом томе, если сделать с dd с этого рэйда:
lvcreate -L20g -n lv3 lvgroup
dd if=/dev/md666 of=/dev/lvgroup/lv3
Запускаю виртуалку. Оно радостно работает.
Но потом я вспоминаю про то, что мне все таки нужно, чтобы виртуалка жила на raid а не просто на lvm.
К сожалению исходный raid с которого создавалась виртуалка (/dev/md666) был успешно похерен.
Я попытался безуспешно залить данные этого lv3 на новый raid1 c помощью того же dd:
lvcreate -L20g -n lv4 lvgroup
lvcreate -L20g -n lv5 lvgroup
mdadm -C /dev/md111 --level=1 --raid-devices=2 /dev/lvgroup/lv4 /dev/lvgroup/lv5
Последующая команда дала сбой: не хватило места
dd if=/dev/lvgroup/lv3 of=/dev/md111
Подозреваю что дело вот в чем: когда я создал md666 на томе размером 20G в начале выделилось место под суперблок 256 байт в случае 1.2 версии. Если после этого делать dd с этого массива, то он захватит эти 256 байт с собой на новый том. Если потом (как это делаю я) создать еще один md111 того же размера что и md666 то на нем не хватит места для имэйджа, который хочеться на него залить. потому что md111 при своем создании то же выделит 256 байт места и при попытки записи весь имейдж сместиться на 256 байт, в итоге самый хвост имэйджа не влезет на новый рэйд.
Кто знает как быть? кроме как создавать новый том больше на 256 байт?
Я подумал, что можно попробовать сделать dd с офсетом в 256 байт, вдруг прокатит?
LinuxForum.Fans
dd from/to software raid
Автор: slonokot
13 сообщений
3756 просмотров
коллега говорит, что при чтении dd c raid он не читает суперблок. Тогда я вообще не понимаю в чем проблема.
Я подумал, что можно попробовать сделать dd с офсетом в 256 байт, вдруг прокатит?
можно. ничего, что суперблоков много, они разбросаны по всему диску, и имеют длину значительно больше 256, а вы всё перепутали?
коллега говорит, что при чтении dd c raid он не читает суперблок.
читает. вы кстати не сказали, какой тип ФС.
Тогда я вообще не понимаю в чем проблема.
вы всё перепутали
:(
testdisk скачайте, восстановите данные, и больше ТАК не делайте.
[quote=slonokot]Я подумал, что можно попробовать сделать dd с офсетом в 256 байт, вдруг прокатит?
можно. ничего, что суперблоков много, они разбросаны по всему диску, и имеют длину значительно больше 256, а вы всё перепутали?[/quote]
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
The "version-1" superblock format is currently used in three different "sub-versions".
The sub-versions differ primarily (solely?) in the location on each component device at which they actually store the superblock.
1.0 At the end of the device
1.1 At the beginning of the device
1.2 4K from the beginning of the device
Первый раз слышу про разбросаность суперблоков. Где я могу прочитать подтверждающую инфу на эту тему?
[quote=slonokot]коллега говорит, что при чтении dd c raid он не читает суперблок.
читает. вы кстати не сказали, какой тип ФС.
Как это проверить?
Тогда я вообще не понимаю в чем проблема.
вы всё перепутали
:([/quote]
Что я перепутал?
Тип фс - угадайте, если там винда стоит)) NTFS конечно.
testdisk скачайте, восстановите данные, и больше ТАК не делайте.
С testdisk поиграюсь, спасибо:)
Первый раз слышу про разбросаность суперблоков. Где я могу прочитать подтверждающую инфу на эту тему?
я про суперблоки ФС, которые читает dd. А суперблок рейда это естественно совсем другое, и dd его естественно НЕ читает.
Тип фс - угадайте, если там винда стоит)) NTFS конечно.
там вообще "суперблоков" нет, там MFT - один такой большой "суперблок" посредине диска. Потому dd тут не поможет.
В общем все как я и говорил с небольшим уточнением:
Делаем dd с исходного raid:
получаем на lvm-е назначения партишн + свободное место в конце потому как размер источника меньше на 4к+256байт суперблока.
Делаем dd на новый raid:
получаеться что как раз этот конец не записывается на новый массив. Тут есть тонкий момент: что если читать дефолтными block size во второй раз то вообще не должно быть никаких проблем, так как их размер 512 байт. А если взять например и сделать
dd if=/dev/lvgroup/lv3 of=/dev/md111 bs=10M
то он не сможет прочитав последние 10M из /dev/lvgroup/lv3 записать их в конец /dev/md111 и операция будет сброшена. В результате самый конец партиции + свободное место (4k + 256 байт) не будут записаны. - fail.
slonokot, я-бы восстановил данные прямо из образа тестдиском. win. победителей не судят :)
slonokot, я-бы восстановил данные прямо из образа тестдиском. win. победителей не судят :)
Че-то я тыкался тыкался, но до победно конца дойти удалось только без всяких извращений (кому не интересно читайте 3-ий пункт):
1. Я сделал дамп партишена в image.dd с помощью testdisk
2. сделал дамп MBR с помощью dd if=/dev/templatelv of=/mnt/backups/templatelv.mbr count=1
Попытался все это записать на рэйд несколькими способами способами:
1. подряд:
dd if=/mnt/backups/templatelv.mbr of=/dev/md9
dd if=/mnt/backups/image.dd of=/dev/md9 skeep=1
Не заработало, не может загрузить операционную систему, партишн находит
2. с пропуском 62 секторов перед началом ntfs (так как testdisk показывал, что начинается ntfs партишн на 63 секторе):
dd if=/mnt/backups/templatelv.mbr of=/dev/md9
dd if=/mnt/backups/image.dd of=/dev/md9 skeep=62
3. Ну и просто попытка скопировать данный с помощью dd со стандартным bs увенчалась успехом.
dd if=/dev/lvgroup/lv1 of=/dev/md9
К сожалению я не понял, как пользоваться полезной утилитой, чтобы записать куда-либо сохраненые партиции. Печалька.
К сожалению я не понял, как пользоваться полезной утилитой, чтобы записать куда-либо сохраненые партиции. Печалька.
тестдиском?
[console]# testdisk image.dd[/console]
ну и кнопки давить. желательно читая, что там пишут...
Войдите или зарегистрируйтесь, чтобы ответить.
