LINUX.ORG.RU
Форум — Admin  

dmraid isw, пропадает файл устройства раздела


0

1

Коллеги, подскажите, в чем может быть дело.
Есть Debian Lenny, есть Intel Software RAID в режиме зеркала.

dmraid его видит:

dmraid -r
/dev/sdc: isw, «isw_cgfjfgibie», GROUP, ok, 1953525166 sectors, data@ 0
/dev/sdb: isw, «isw_cgfjfgibie», GROUP, ok, 1953525166 sectors, data@ 0

# dmraid -s
*** Group superset isw_cgfjfgibie
--> Active Subset
name : isw_cgfjfgibie_mirror
size : 1953519872
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0


В /dev/mapper raid виден.
# ls -l /dev/mapper/
итого 0
crw-rw---- 1 root root 10, 60 Янв 18 16:08 control
brw-rw---- 1 root disk 254, 0 Янв 18 16:08 isw_cgfjfgibie_mirror

Создаю раздел в parted (использую GPT вместо MBR, но это не принципиально, полагаю), появляется файл устройства isw_cgfjfgibie_mirror1 в /dev/mapper с major/minor 254/1 , на нем делаю mkfs.ext3, монтирую - все нормально.

Но после перезагрузки ОС файл раздела isw_cgfjfgibie_mirror1 пропадает. Пробовал по наивности создать через mknod с major/minor 254,1, но смонтировать уже не получилось.

Как сделать, чтобы файл раздела не пропадал? Или появлялся после какой-либо команды (м.б. dmraid как-то особо вызвать?) Подтолкните в нужную сторону. Прошерстил гугл, но в итоге вынужден спросить здесь.

★

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

шоето за сотонинские термины названия устройств и почему во всём посте не встречается mdadm? вы пытаетесь пользоваться интеловыми дровами от их недоконтроллера?

пользуйтесь линуксовым софтрейдом, и ваши волосы будут мягкие и шелковистые

anonymous
()

Ага. Объясните, пожалуйста, в чём преимущество этого штеуд-недорейда по сравнению с расово-верным mdadm --level=1? Ведь, как известно, fake-RAID, как биологический вид, появился для обхода [к]анальной позиции MS, выдравшей из не-серверных вариантов винды возможность создания soft-RAID и, как правило, убог и глючен.

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

Рискну предположить, что штеуд-недорейд обеспечивает распараллеливание запросов к дискам, в отличие от последовательного алгоритма «round-robin» у mdadm.

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

> штеуд-недорейд обеспечивает распараллеливание запросов к дискам,

Я считаю, что вы не правы. При однопоточном чтении запросы к зеркалу распараллелить, как мне кажется, в принципе невозможно. Иначе чем бы RAID1 на чтении от RAID0 отличался, а? Как контроллер может предугадать, какой блок будет запрошен следующим? Или в fake-RAID применяется-таки libastral, а мужики-то и не знают?

nbw ★★★
()

>> Как сделать, чтобы файл раздела не пропадал?

Используй нормальный софтовый рейд. Всяко надёжнее этих загадочных поделок.

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

> загадочных

+500 Непойми что вообще. LSI Mega-RAID, к-рый очень любят распаивать на серверные интеловские мамки, например, после выдёргивания одного винта из RAID1 начинает жутко тормозть, хотя такого, по логике устройтва RAID 1-го уровня, быть не должно. Не RAID5 в degraded mode же, в конце концов.

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

>>после выдёргивания одного винта из RAID1 начинает жутко тормозть, хотя такого, по логике устройтва RAID 1-го уровня, быть не должно.

есть такое, а совсем недавно был случай полный адиос - видать не выдержал бедняга дополнительной нагрузки и кернел паник выдал. есть подозрения, что это особенность линукса... на солярке такого не было замечено. хотя я предпочитаю использовать svm или некую файловую систему, которая сама это умеет, но некоторые личности все-таки делают этот говно-рэйд.

наче чем бы RAID1 на чтении от RAID0 отличался, а?


дак в нормальных реализациях он и не отличается, а линейное io мало кого интересует.

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

это очередной аргументированный ответ от красноглазых гуру?
продолжай потешать публику.

зы а что, батхерт, что у других как надо все работает?

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

> сть такое, а совсем недавно был случай полный адиос - видать не выдержал бедняга дополнительной нагрузки и кернел паник выдал. есть подозрения, что это особенность линукса...

Ага, щас. Это наблюдалось под WinSrv 2003 x86_64 c дровами от производителя. На линуксах у меня только софт-RAID. Да и вин-сервер этот пришлось на софт-RAID перевести, после прочтения пары каментов о странных отказах этого самого LSI RAID, после которых инфа превращалась в кашу.

nbw ★★★
()

>использую GPT вместо MBR, но это не принципиально, полагаю

Напрасно полагаете. Переразбейте в MBR, всё нормально заведётся.

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

у других?

у меня на рейде1 и рейде10 чтение с sda в /dev/null показывает 1.1гб/с — следовательно, либо линупс закешировал sda, либо у красноглазых гуру что-то другое

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

поигрался с кешами, размерами блоков, количеством — рейд10 не отличается от рейд1 больше чем на 10%. От 70 до 210мб/с, сервера под нагрузкой, правда.

И два поста назад мне надо было мерять чтение с /dev/md1

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

>>и да, у меня баттхёрт от того, что какой-то клоун заполонил форум глупостями

оно всегда так кажется, когда не в теме...

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

>Рискну предположить, что штеуд-недорейд обеспечивает распараллеливание запросов к дискам, в отличие от последовательного алгоритма «round-robin» у mdadm.

Народ советует ставить RAID10 на два диска, чтобы добиться 2х скорости при чтении.

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

>>sda в /dev/null показывает 1.1гб/с

либо линупс закешировал


все бы так - сам спросил, сам ответил.

И два поста назад мне надо было мерять чтение с /dev/md1


не вот еще узнать бы что мерить...

поигрался с кешами, размерами блоков, количеством

сервера под нагрузкой, правда.


вы все еще хотите поговорить про глупости?

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

просто уймитесь, у меня уже впечатление о том, что орацле состоит не только из адвокатов и отдела сбыта, но и форумных фанатиков

из серии экспериментов с sync+dd чтение на более нагруженной ноде из 4гб файла, лежащего на ехт3, на томе лвм, на рейд1 в среднем 177мб/с

из серии экспериментов с sync+dd чтение на менее нагруженной ноде из 4гб файла, лежащего на ехт3, на томе лвм, на рейд10 в среднем 185мб/с

гугление по запросу «linux raid1 read performance» также подтверждает удвоение скорости чтения в рейд1

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

>Напрасно полагаете. Переразбейте в MBR, всё нормально заведётся.
Спасибо, это помогло! :-)
И почему бы мне сразу не попробовать...

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

>Переразбейте в MBR, всё нормально заведётся.

Спасибо, это помогло! :-)


Что, правда помогло? Но почему?!

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

Потому что фейк-рейды - УГ. Я тоже пытался юзать это поделие, ибо было интегрировано аж две штуки (интел и адаптек) в мамку, после GPT разбивки рейд не собирался, а с MBR были какие то непонятные глюки на ich9r. Забил на это поделие и заюзал mdadm.

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

Что то вроде: [code] /dev/mapper/raid-array -> контроллер дисков |-> диск 1 |-> диск 2 [/code]

Когда mdadm работает, вроде по принципу: [code] /dev/md0 |-> контроллер -> диск 1 |-> контроллер -> диск 2 [/code]

Хотелось бы комментариев знающих людей +)

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

Потому что фейк-рейды - УГ. Я тоже пытался юзать это поделие, ибо было интегрировано аж две штуки (интел и адаптек) в мамку, после GPT разбивки рейд не собирался, а с MBR были какие то непонятные глюки на ich9r. Забил на это поделие и заюзал mdadm.

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

Что то вроде: 

/dev/mapper/raid-array -> контроллер дисков |-> диск 1
                                            |-> диск 2

Когда mdadm работает, вроде по принципу: 

/dev/md0 |-> контроллер -> диск 1
         |-> контроллер -> диск 2

Хотелось бы комментариев знающих людей +)

//лоркод, блин >_<

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

Типа dmraid тупо не понимает GPT. :)
Теоретически проблема с GPT вроде как решаема, но надо шаманить на этапе загрузки (запускать kpartx).

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

Типа dmraid тупо не понимает GPT. :)

Я в курсе этого. Он и MBR не понимает. Для (полу-)аппаратных рейдов нужны только RAW-носители без разметки, так как вся служебная информация и программа бутстрапа пишутся на каждый из носителей без учёта другой служебной информации на них (естественно, затирая последнюю, если она была). А уже когда рейд сконфигурирован из BIOS, на виртуальном диске уже можно делать разметку.

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

Когда mdadm работает, вроде по принципу:

mdraid умеет распараллеливать несколько потоков по дискам:

root ~ # lvcreate -L5G -ntest vg
  Logical volume "test" created
root ~ # mkfs.ext3 /dev/mapper/vg-test 

<skipped>

root ~ # mount /dev/mapper/vg-test /mnt/temp/
root ~ # dd if=/dev/zero of=/mnt/temp/000 bs=10M count=200
200+0 records in
200+0 records out
2097152000 bytes (2.1 GB) copied, 26.5104 s, 79.1 MB/s
root ~ # dd if=/dev/zero of=/mnt/temp/001 bs=10M count=200
200+0 records in
200+0 records out
2097152000 bytes (2.1 GB) copied, 27.879 s, 75.2 MB/s

Читаем один файл:

root ~ # pv /mnt/temp/000 > /dev/null 
1.95GB 0:00:20 [95.3MB/s] [=================================>] 100%

Читаем оба файла в два потока:

root ~ # (cat /mnt/temp/000 & cat /mnt/temp/001) | pv > /dev/null 
3.91GB 0:00:22 [ 179MB/s] [                      <=>                          ]

Вуаля! Почти удвоенная скорость. Перед каждым чтением делалось 

echo 3 > /proc/sys/vm/drop_caches

GotF ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin