LINUX.ORG.RU

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

поясните свою точку зрения, пожалуйста?


Ну тут все очевидно, хардварные рейды быстрее (mdraid сливает жутко при чтении с нулевого рейда даже встроенному в мою дешевую материнскую плату в полтора раза), поэтому хардварные рейды сосут. Типа не по красноглазому это, все работает сразу, скучно, уныло, быстро. НЕ тру в общем. Надо обязательно слаку, древнее кривое ядро, или еще лучше ФриБСД.

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

А ненормальные люди ради ZFS, смешно сказать, — ставят дырявый Linux и студенческую поделку ZFS-FUSE. Ж)) Зато быть упёртым фанатиком КРУТО! ЧСВ, говорят, от этого повышается. Ж))

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

Я от них не завишу.

У тебя зависимость от ZFS.

Эй, кто-нибудь знает хорошего нарколога? Изя страдает.

sdio ★★★★★
()

По-моему, из недорогих лучше ставить mdraid. Ну или другое проверенное софтовое решение на свой вкус.

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

Exorcizo te, immundíssime spíritus, omnis incúrsio adversárii, omne phantasma, omnis légio, in nómine Dómini nostri Jesu+Christi eradicáre, et effugáre ab hoc plásmate Dei +. Ipse tibi ímperat, qui te de supérnis cæaelórum in inferióra terræ demérgi præcépit. Ipse tibi ímperat, qui mari, ventis et tempestátibus imperávit. Audi ergo, et time, sátana, inimice fidei, hostis géneris humáni, mortis addúctor, vitæ raptor, justítiæ declinátor, malórum radix, fomes vitiórum, sedúctor hóminum, próditur géntium, incitátor invídiæ, origo avaritiæ, causa discórdiæ, excitátor dolórum: quid stas, et resistis, cum scias, Christum Dóminum vias tuas pérdere? Illum métue, qui in Isaac immolátus est, in Joseph venúndatus, in agno occísus, in hómine crucifixus, deinde inférni triumphátor fuit. Sequentes crucis fiat in fronte obsessi. Recéde ergo in nómine Patris +, et Fílii +, et Spíritus + Sancti: da locum Spirítui Sancto, per hoc signum sanctæ + Crucis Jesu Christi Dómini nostri: Qui cum Patre et eódem Spíritu Sancto vivit et regnat Deus, per ómnia sæcula sæculórum.

Amen.

Изыди в свою клоаку, срамная рогатая тварь!

as33 ★☆☆
()

ты видел sas-контроллер за 5-10к?

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

mdraid — это случайно не тот, который недавно научили не рассыпаться?

По первой ссылке анонизмус сделал очевидную херню - перезаписал кусок файловой системы случайными данными в обход механизма md. RAID1 не проверяет (и не должен проверять) целостность данных, он «помогает» только от ошибок самих дисков, которые они сами могут определять. Иными словами, анонизмус продемонстрировал классический приём с дверью и яйцами.

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

Hardware контроллер имеет проприетарный формат хранения данных.

По-русски, сдох контроллер - можете выкинуть винчестеры.

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

По первой ссылке анонизмус сделал очевидную херню - перезаписал кусок файловой системы случайными данными в обход механизма md. RAID1 не проверяет (и не должен проверять) целостность данных, он «помогает» только от ошибок самих дисков, которые они сами могут определять.

Раз так, то почему он выдаёт мусор при чтении файлов(!) и не индицирует никаким образом отказ попытки чтения заведомо неверных данных?

Проверил у себя GEOM Mirror в аналогичной ситуации (В ОБХОД GEOM запортил один из носителей). Так gmirror status показал, что RAID в порядке. Однако данных на зеркале не оказалось. И только после выбрасывания запорченного носителя из зеркала и перемонтирования ФС всё восстановилось.

Так как, говорите, должен работать Soft-RAID? В Linux md-raid-1 выдаёт непредсказуемый мусор. В FreeBSD GEOM Mirror не выдаёт ничего, пока не будет устранена [НЕ ЕГО] проблема.

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

Вы это... К доктору сходите :)
Бред - это очень плохой симптом.
Возможно еще не все потеряно.

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

Раз так, то почему он выдаёт мусор при чтении файлов(!) и не индицирует никаким образом отказ попытки чтения заведомо неверных данных?

Во-первых, он выдаёт не мусор, а данные, записанные на одном из дисков, входящих в зеркало. Во-вторых, RAID1 никак не может узнать - целы ли данные. В нём просто не предусмотрено никакого контроля целостности. Максимум - он может считать данные со всех дисков массива и сравнить, но это всё равно не позволит точно сказать где правильные данные, а где - нет. Весь расчёт на то, что диск сам сообщит об ошибке чтения (например при поломке или появившихся бэд-блоках).

Проверил у себя GEOM Mirror в аналогичной ситуации (В ОБХОД GEOM запортил один из носителей). Так gmirror status показал, что RAID в порядке. Однако данных на зеркале не оказалось. И только после выбрасывания запорченного носителя из зеркала и перемонтирования ФС всё восстановилось.

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

Так как, говорите, должен работать Soft-RAID?

Я говорил не про Soft-RAID, а про RAID1. Любой RAID1, в т.ч. аппаратный. Контроль целостности данных - не его забота. Если два диска рассинхронзировались, а RAID-контроллер или модуль ядра с программной реализацией об этом не знают, то они с равной вероятностью могут выдать данные с любого из входящих в зеркало дисков.

В Linux md-raid-1 выдаёт непредсказуемый мусор.

Повторяю - это не мусор, это данные с одного из дисков массива.

В FreeBSD GEOM Mirror не выдаёт ничего, пока не будет устранена [НЕ ЕГО] проблема.

Думаю тебе просто повезло и ты запорол не только данные в файле, но и айнод или другие структуры ФС. Как я уже писал выше, лучше попробовать провести эксперимент без ФС. Причём несколько раз.

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

Как я уже писал выше, лучше попробовать провести эксперимент без ФС. Причём несколько раз.

Хорошо. Попробую и отпишусь.

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

Вот как это на линуксе выглядит:

$ dd if=/dev/zero of=test0 bs=1024 count=1024
1024+0 записей считано
1024+0 записей написано
 скопировано 1048576 байт (1,0 MB), 0,0178764 c, 58,7 MB/c

$ dd if=/dev/zero of=test1 bs=1024 count=1024
1024+0 записей считано
1024+0 записей написано
 скопировано 1048576 байт (1,0 MB), 0,0148253 c, 70,7 MB/c

$ sudo losetup /dev/loop0 test0

$ sudo losetup /dev/loop1 test1

$ sudo mdadm --create /dev/md0 -n 2 -l 1 /dev/loop0 /dev/loop1 
mdadm: array /dev/md0 started.

$ cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 loop1[1] loop0[0]
      960 blocks [2/2] [UU]
      
unused devices: <none>

$ for i in $( seq 100 ); do sudo md5sum /dev/md0; done | sort -u
63a6c5a8b8da92e30cd0ef23c56d4f06  /dev/md0

$ sudo dd if=/dev/urandom of=/dev/md0 bs=1 seek=1024 count=10240
10240+0 записей считано
10240+0 записей написано
 скопировано 10240 байт (10 kB), 0,0323391 c, 317 kB/c

$ for i in $( seq 100 ); do sudo md5sum /dev/md0; done | sort -u
91f9e337cf8058b79cec1f88b950d146  /dev/md0

$ sudo dd if=/dev/urandom of=/dev/loop0 bs=1 seek=1024 count=10240
10240+0 записей считано
10240+0 записей написано
 скопировано 10240 байт (10 kB), 0,0437183 c, 234 kB/c

$ sync

$ for i in $( seq 100 ); do sudo md5sum /dev/md0; done | sort -u
5f0865f2270d28d9be766a58cabb7937  /dev/md0
91f9e337cf8058b79cec1f88b950d146  /dev/md0

$ echo repair | sudo dd of=/sys/block/md0/md/sync_action 
0+1 записей считано
0+1 записей написано
 скопировано 7 байт (7 B), 2,7098e-05 c, 258 kB/c

$ for i in $( seq 100 ); do sudo md5sum /dev/md0; done | sort -u
5f0865f2270d28d9be766a58cabb7937  /dev/md0
Видно, что после записи мусора на один диск из массива, система читат то одни данные, то другие. Если диски большие и мусора на один диск записать тоже много - то количество вариантов должно увеличится, т.к. система начнёт читать данные не целиком с одного диска, а кусками то с одного, то с другого.

Deleted
()
Ответ на: комментарий от Deleted
% date
среда, 16 декабря 2009 г. 17:37:05 (VOLT)
% uname -rsm
FreeBSD 8.0-STABLE amd64
% dd if=/dev/random of=/usr/local/disk1 bs=1M count=250
250+0 records in
250+0 records out
262144000 bytes transferred in 3.672529 secs (71379691 bytes/sec)
% mdconfig -a -t vnode -f /usr/local/disk1
md0
% gmirror status
gmirror: Command 'status' not available.
% gmirror load
% gmirror status
% gmirror label -v Data /dev/md0
Metadata value stored on /dev/md0.
Done.
% md5 /dev/mirror/Data 
MD5 (/dev/mirror/Data) = d41d8cd98f00b204e9800998ecf8427e
% dd if=/dev/random of=/usr/local/disk2 bs=1M count=250
250+0 records in
250+0 records out
262144000 bytes transferred in 3.685353 secs (71131317 bytes/sec)
% mdconfig -a -t vnode -f /usr/local/disk2
md1
% gmirror insert Data /dev/md1
% gmirror status && date 
       Name    Status  Components
mirror/Data  DEGRADED  md0
                       md1 (91%)
среда, 16 декабря 2009 г. 17:43:11 (VOLT)
% gmirror status && date
       Name    Status  Components
mirror/Data  COMPLETE  md0
                       md1
среда, 16 декабря 2009 г. 17:43:21 (VOLT)
% md5 /dev/mirror/Data
MD5 (/dev/mirror/Data) = d41d8cd98f00b204e9800998ecf8427e
% dd if=/dev/random of=/usr/local/disk1 bs=1M count=250
250+0 records in
250+0 records out
262144000 bytes transferred in 3.644108 secs (71936396 bytes/sec)
% md5 /dev/mirror/Data
MD5 (/dev/mirror/Data) = d41d8cd98f00b204e9800998ecf8427e
% gmirror status && date
       Name    Status  Components
mirror/Data  COMPLETE  md0
                       md1
среда, 16 декабря 2009 г. 17:45:02 (VOLT)
% dd if=/dev/zero of=/usr/local/disk1 bs=1M count=250
250+0 records in
250+0 records out
262144000 bytes transferred in 0.206591 secs (1268903962 bytes/sec)
% md5 /dev/mirror/Data
MD5 (/dev/mirror/Data) = d41d8cd98f00b204e9800998ecf8427e
% gmirror status && date
       Name    Status  Components
mirror/Data  COMPLETE  md0
                       md1
среда, 16 декабря 2009 г. 17:49:23 (VOLT)

— контрольная сумма массива совпадает, несмотря на то, что один носитель запорчен. :-) Очистка:

% gmirror stop Data
% gmirror clear md0
% gmirror clear md1
% gmirror status
% gmirror unload
% mdconfig -l
md0 md1
% mdconfig -d -u /dev/md0
% mdconfig -d -u /dev/md1

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

> По первой ссылке анонизмус сделал очевидную херню - перезаписал кусок файловой системы случайными данными в обход механизма md. RAID1 не проверяет (и не должен проверять) целостность данных, он «помогает» только от ошибок самих дисков, которые они сами могут определять. Иными словами, анонизмус продемонстрировал классический приём с дверью и яйцами.

Херню говорите? Очевидную? Уверены, что ничего подобного не может случиться с диском? Голову на отсечение дадите? Ну или хотя бы палец?

Если вы ничего подобного не видели, то 1) это не значит, что этого не существует 2) вы слишком недолго в ИТ ну или просто далеки от поддержки

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

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

твой миррор данные читает только с одного диска , а в линукс с 2-ух?

К.О. как бы намекает об этом

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

— контрольная сумма массива совпадает, несмотря на то, что один носитель запорчен. :-) Очистка:

Мдаааа... Фиговый из тебя, однако, экспериментатор =). Да будет тебе известно, что d41d8cd98f00b204e9800998ecf8427e - это md5 от текста _нулевой_ длинны. Похоже во FreeBSD утилита md5 не умеет работать с блочными устройствами. Вот так можно это обойти:

cat /dev/mirror/test | md5

А вот и мой результат эксперимента на FreeBSD:

# uname -rsm
FreeBSD 6.3-STABLE i386

# dd if=/dev/zero of=test0 bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.022051 secs (47552104 bytes/sec)

# dd if=/dev/zero of=test1 bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.019049 secs (55046454 bytes/sec)

# mdconfig -a -t vnode -f test0
md5

# mdconfig -a -t vnode -f test1
md6

# gmirror load

# gmirror status

# gmirror label -v test /dev/md5 /dev/md6
Metadata value stored on /dev/md5.
Metadata value stored on /dev/md6.
Done.

# gmirror status
       Name    Status  Components
mirror/test  COMPLETE  md5
                       md6

# for ((i = 1; i < 100; i++)); do cat /dev/mirror/test | md5; done | sort -u
ed356b009be474fef10efc60939de511

# dd if=/dev/urandom of=test0 bs=1 seek=1024 count=10240
10240+0 records in
10240+0 records out
10240 bytes transferred in 0.022859 secs (447962 bytes/sec)

# for ((i = 1; i < 100; i++)); do cat /dev/mirror/test | md5; done | sort -u
ed356b009be474fef10efc60939de511

# dd if=/dev/urandom of=test1 bs=1 seek=1024 count=10240
10240+0 records in
10240+0 records out
10240 bytes transferred in 0.023473 secs (436245 bytes/sec)

# gmirror status
       Name    Status  Components
mirror/test  COMPLETE  md5
                       md6

# for ((i = 1; i < 100; i++)); do cat /dev/mirror/test | md5; done | sort -u
2ba65e08650b35ef16cb210c97999731

# gmirror rebuild -v test /dev/md5
Done.

# gmirror status
       Name    Status  Components
mirror/test  COMPLETE  md6
                       md5

# for ((i = 1; i < 100; i++)); do cat /dev/mirror/test | md5; done | sort -u
2d7955e29e1c598593a0a45e65780c5e
Данные портятся точно так же, но судя по всему, они (данные) всегда читаются с одного устройства и распределение нагрузки не происходит. Причём
gmirror configure -b round-robin test
не помогает. Думаю на больших массивах оно будет себя вести так же как и в линуксе с md - благодаря распределению нагрузки читать то одни данные, то другие.

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

Херню говорите? Очевидную? Уверены, что ничего подобного не может случиться с диском? Голову на отсечение дадите? Ну или хотя бы палец?

Я не говорил что это не может случиться, я говорил, что RAID1 от такого не спасает и не должен спасать, т.к. в нём нет проверки целостности данных. Повторяю в третий раз: RAID1 полагается на то, что устройства в массиве сами способны находить свои ошибки. Естественно, если вручную записать хлам на один из дисков, то RAID1 этого не заметит, а диск не сообщит об ошибке, так как на него данные записаны абсолютно корректно. Если данные на диске запорятся из-за поломки чего-нибудь или воздействия космических лучей (=)), то диск это обнаружит, сообщит об ошибке системе, и в RAID1 этот диск будет помечен как сбойный.

Если вы ничего подобного не видели, то 1) это не значит, что этого не существует 2) вы слишком недолго в ИТ ну или просто далеки от поддержки

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

И всё таки я себе слабо представляю, как можно _случайно_ записать данные на одно из устрйоств массива. Только если по пьяни или от незнания... но тут никакой RAID не спасёт =).

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

> Если данные на диске запорятся из-за поломки чего-нибудь или воздействия космических лучей (=)), то диск это обнаружит, сообщит об ошибке системе, и в RAID1 этот диск будет помечен как сбойный.

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

И всё таки я себе слабо представляю, как можно _случайно_ записать данные на одно из устрйоств массива. Только если по пьяни или от незнания... но тут никакой RAID не спасёт =).

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

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

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

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

Можете не трудиться, это понятно и без ваших повторений. Просто с ростом емкости дисков и хранимых объемов данных время восстановления после сбоя становится малоприемлемым. Поэтому, когда из-за рассинхронизации содержимого зеркал произойдет сбой, спрашивать будут не с RAID-1 - с него и спросить то нечего, - а с вас, который на него смело понадеялся.

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

>> В Linux md-raid-1 выдаёт непредсказуемый мусор.

Повторяю - это не мусор, это данные с одного из дисков массива.

Если это не те данные, которые вы туда ранее записали - то это таки мусор, вне зависимости от того, с какого диска зеркала он прочитан.

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

Спасибо, что провели эксперимент. Я тоже подозревал, что md5 что-то не то считает в случае с блочным устройством.

Однако, при наличии файловой системы на зеркале и перезаписью одного из носителей зеркала сама ФС даёт очевидный сбой и не позволяет читать мусор пока сбойный носитель не будет удалён из зеркала.

Возможно также, mdconfig не полностью эмулирует блочное устройство и не позволяет точно судить о поведении системы на реальных/физических носителях — у меня был не один случай зависания ОС при деструктивных манипуляциях с подмонтированными «md» виртуальными устройствами. На физических носителях сейчас проверить, к сожалению, нет возможности.

Что касается поведения RAID-1 как такового, то он, вы правы, не может гарантировать отсутствие ошибок, а может лишь диагностировать аппаратный сбой и отключение отказавшего винчестера. Защиту от ошибок носителей могут обеспечить лишь следующие уровни RAID (-3, -5, -6) и/или файловая система с поддержкой сквозного контроля целостности данных — такая как ZFS.

Насчёт возможностей RAID-1 очень много заблуждений. Спасибо, что вы продемонстрировали опасность этого.

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

> Анонимус как всегда работает за Майора Тупенко...

Спасибо за столь лестную оценку, мистер зоркий глаз и короткий...

Продолжать не буду, авось и сами догадаетесь

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

Однако, при наличии файловой системы на зеркале и перезаписью одного из носителей зеркала сама ФС даёт очевидный сбой и не позволяет читать мусор пока сбойный носитель не будет удалён из зеркала.

А это уже как повезёт. Если затрутся структуры ФС, то о сбоях будет сообщать любая ФС, даже FAT какой-нибудь. А если затрутся только данные, то о сбоях будет сообщать только ФС, у которой есть механизмы прозрачной проверки целостности данных. Похоже это есть только в ZFS, btrfs и NILFS.

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

Продолжать не буду, авось и сами догадаетесь

Да я давно уже догадываюсь, что анонимусы читать не умеют =).

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

Ну, прямо америку открыли. Хоть в википедию иногда поглядывайте - там всё уже придумано до вас.

Ещё один...

Я говорю то же самое, что написано в википедии (и в куче других мест). Я знаю, что об этом уже много сказано и написано. Я просто доказываю опытным путём, что RAID1 работает именно так как должен и никак иначе.

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

> А это уже как повезёт. Если затрутся структуры ФС, то о сбоях будет сообщать любая ФС, даже FAT какой-нибудь.

А это уже как повезёт (c) mironov_ivan

Смотря чем и в каком объеме эти структуры затрутся.

Я давно уе догадываюсь, что вы думать не умеете, а анонимусов в неумении читать обвиняете.

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

софтверные рейды с точки зрения логики могут быть ничуть не хуже хардварных. лучше они или хуже - мне сложно судить. Но по личному опыту пользования софтверного рейда 5 могу сказать, что проблем в использовании нету, и отваливание одного винта система пересла как и ожидалось: падение производительности io -> cat /proc/mdstat -> массив деградирован, определяем отвалившийся винт, меняем (т.к. сата - можно было без ребута, ибо хотплаг) -> запускаем перестройку массива и спустя несколько часов получаем рабочую систему.

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

azure ★★
()

Ндаа тема сразу же скатилась в маленький холивар о софт рейде, узнаю лор.

Дело в том что у меня на руках уже есть 2 sas диска и рейд от promise - fastrack, (куплено не мной) так как просто в sata разъемах эти диски работать не будут ===> _нужен_ контроллер.

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

по моему там и разъем другой, т.е. физически такой но в САС ключ, и к сас контроллеру можно сата подключать диски и сас, а к сата контроллеру тока сата. Вроде как то так.

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

> Дело в том что у меня на руках уже есть 2 sas диска и рейд от promise - fastrack, (куплено не мной) так как просто в sata разъемах эти диски работать не будут ===> _нужен_ контроллер.

Ну, купи любой _контроллер_ на базе LSI 1064 или 1068 - будет поддержка SAS за минимальные деньги. При чем тут RAID?

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