[closed]soft-raid1: одинаковые или или разные харды брать?
А не пох ли. Я если бы не было каких-нибудь религиозных предубеждений перед имеющимися в наличии дисками, взял бы 2 разных. Доказательство такое:
Если надёжность дисков A и B (разных производителей то "общая надёжность" двух разных равна max(A, B).
Т.е. если ты берёшь только A или только B, то можешь попасть на менее надёжную партию.
Но с другой стороны если берёшь разные, то один из них будет заведомо менее надёжный.
Примерно такие доводы.
Если надёжность дисков A и B (разных производителей то "общая надёжность" двух разных равна max(A, B).
Т.е. если ты берёшь только A или только B, то можешь попасть на менее надёжную партию.
Но с другой стороны если берёшь разные, то один из них будет заведомо менее надёжный.
Примерно такие доводы.
Как я понимаю, основной довод за одинаковые диски - это различия в других характеристиках, кроме объёмов.
Например, если брать разные, то я возьму вот эти два:
http://market.yandex.ru/compare.xml?CAT_ID=686672&CMD=-CMP=6842727,6396923
У Сигейта "Внешняя скорость передачи данных" в два раза больше, хотя у самсунга быстрее "Среднее время доступа". Я не очень понял как такое может быть, может вследствие разницы между последовательным и случайным доступом... но, как я понял, в рейде они фактически будут работать на нахудших показателях, то есть первая характеристика от Самсунга, а вторая - от Сигейта.
Таким образом, оба диска будут работать хуже, чем по-отдельности или в паре с собратом.
Например, если брать разные, то я возьму вот эти два:
http://market.yandex.ru/compare.xml?CAT_ID=686672&CMD=-CMP=6842727,6396923
У Сигейта "Внешняя скорость передачи данных" в два раза больше, хотя у самсунга быстрее "Среднее время доступа". Я не очень понял как такое может быть, может вследствие разницы между последовательным и случайным доступом... но, как я понял, в рейде они фактически будут работать на нахудших показателях, то есть первая характеристика от Самсунга, а вторая - от Сигейта.
Таким образом, оба диска будут работать хуже, чем по-отдельности или в паре с собратом.
Различие во "внешней скорости передачи данных" это ерунда. Это просто скорость интферфейса.
У сигейта SATA3(6Gbps у самсунга SATA2(3Gbps). Реальная скорость передачи все равно сильно ниже чем 3Gbps, поэтому в этот параметр даже смотреть не стоит.
Я б наверное для зеркала взял 2 разных - самсунг и еще что-то, скорее всего вд. У сигейта со случайным доступом действительно все плохо.
У сигейта SATA3(6Gbps у самсунга SATA2(3Gbps). Реальная скорость передачи все равно сильно ниже чем 3Gbps, поэтому в этот параметр даже смотреть не стоит.
Я б наверное для зеркала взял 2 разных - самсунг и еще что-то, скорее всего вд. У сигейта со случайным доступом действительно все плохо.
Насчёт WD у меня как раз теперь религиозное предубеждение. Как раз покупаю этот рейд после сдохшего вдшника, который проработал всего полгода и внезапно сдох. Хоть у меня по сети большая часть нужной инфы бекапилась, но немного оказалось из-за него безвозвратно утеряно.
При этом на сайтах контор, которые занимаются восстановлением данных, пишут, что самые сложные и поэтому дорогие для восстановления диски для них - это WD.
Плюс фееричная технология парковки головок по бездействию у Green-серии, которая вкупе с дефолным кешированием приводит к сдыханию. Пруф (у меня сдох Black, так что не из-за этого)
Так что я вряд ли в обозримом будущем куплю WD
При этом на сайтах контор, которые занимаются восстановлением данных, пишут, что самые сложные и поэтому дорогие для восстановления диски для них - это WD.
Плюс фееричная технология парковки головок по бездействию у Green-серии, которая вкупе с дефолным кешированием приводит к сдыханию. Пруф (у меня сдох Black, так что не из-за этого)
Так что я вряд ли в обозримом будущем куплю WD
я бы не волновался из-за дисков — в твоём случае первой издохнет ФС 
Ты имеешь в виду, что btrfs всё ещё недостаточно надёжна?
Думаешь, надёжнее сделать классический mdadm с ext4?
Вообще, ФС наверное тоже не на обоих сразу должна умереть, не?
Думаешь, надёжнее сделать классический mdadm с ext4?
Вообще, ФС наверное тоже не на обоих сразу должна умереть, не?
Вообще, ФС наверное тоже не на обоих сразу должна умереть, не?
Поставь себе лучше NTFS.
Увидел, что в моей теме ответи Глебиус, обрадовался, думая, что сейчас получу авторитетный ответ... открыл тему и 
В чём сарказм-то? btrfs позволяет примонтировать каждый диск из raid1 по-отдельности (аварийный режим вроде как считается). Логично предположить, что данные на них более-менее независимы.
Вообще, у меня никогда не было никаких проблем с ФС, не вызванных проблемами с питанием. Так что я себе слабо представляю как ФС может умереть.
В чём сарказм-то? btrfs позволяет примонтировать каждый диск из raid1 по-отдельности (аварийный режим вроде как считается). Логично предположить, что данные на них более-менее независимы.
Вообще, у меня никогда не было никаких проблем с ФС, не вызванных проблемами с питанием. Так что я себе слабо представляю как ФС может умереть.
> btrfs позволяет примонтировать каждый диск из raid1 по-отдельности (аварийный режим вроде как считается)
Само собой, после краша RAID1, ты можешь подмонтировать любой из его обломков по отдельности. Но после краша файловой системы из-за логической ошибки в ней неконсистентная файловая система будет на обоих.
Само собой, после краша RAID1, ты можешь подмонтировать любой из его обломков по отдельности. Но после краша файловой системы из-за логической ошибки в ней неконсистентная файловая система будет на обоих.
Ясно, буду знать, спасибо.
Значит btrfs не катит...
А что-нибудь скажешь по поводу одинаковости/разности дисков?
Значит btrfs не катит...
А что-нибудь скажешь по поводу одинаковости/разности дисков?
Выше уже высказали все разумные соображения.
Ясно. Все единогласны. Тогда сомнений не осталось: беру разные!
Всем спасибо
Всем спасибо
И, видимо, буду использовать mdadm + ext4
Я за ZFS.
А линукс умеет?
У меня как раз возникла такая мысль... где-то читал про портирование zfs в linux (именно ядро, а не fuse). Лицензионно это несовместимо, но технически работает. Но решил, что вряд ли этот код будет стабильнее btrfs
О, а может откопать древниее железо, вставить в него sata-контроллер в pci и туда freebsd поставить. И монтировать по сети.
Лучше FreeNAS сразу тогда.
Через fuse уже давно. Только я не знаю какая последняя версия пула была туда "портирована".
С нативно вроде тоже есть что-то, но о статусе тоже без понятия - у меня FreeBSD. :-D
С нативно вроде тоже есть что-то, но о статусе тоже без понятия - у меня FreeBSD. :-D
и OpenSolaris?
Лучше FreeNAS сразу тогда.А зачем? IMHO, лучше ванила FreeBSD - по крайней мере мне проще с ней работать.
и OpenSolaris?Да ладно. FreeBSD нашё фсё! :-P
Лучше FreeNAS сразу тогда.Судя по педивикии, это просто freebsd, увешаная всякой хренью, из которой реально нужно полторы софтины, чтобы самому настраивать не пришлось. Всякие веб-админки с блекджеком - явно не мой выбор.
Ну 5 минут назад ты думал, что RAID1 спасает от глючной fs, так что вполне может быть это твой выбор. Опять же, ты сейчас сидишь в линуксе обвешанном всякой хренью, из которой реально нужно полторы софтины, а не в ядре + /bin/bash.
Кстати, ты CUPS конфигуришь через веб-интерфейс или редактируешь конфиги вручную?
Кстати, ты CUPS конфигуришь через веб-интерфейс или редактируешь конфиги вручную?
Ага, наше.
У меня тут есть одна инсталляция, которая с 100% вероятностью (ну ладно, 99%) роняет ZIL в deadlock от запуска daily_status_security: недели 2 думал, почему оно такое пунктуальное
Пришлось мигрировать обратно на UFS, а он по кешу прожерливее ZFS раза в 4
У меня тут есть одна инсталляция, которая с 100% вероятностью (ну ладно, 99%) роняет ZIL в deadlock от запуска daily_status_security: недели 2 думал, почему оно такое пунктуальное
find -sx / /usr /var /opt /rrd /base /backup-base /cacti-graph-cache /tmp /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
Пришлось мигрировать обратно на UFS, а он по кешу прожерливее ZFS раза в 4
Через fuse уже давно. Только я не знаю какая последняя версия пула была туда "портирована".Причём вполне сносно работает. В смысле стабильно. Пул там вроде вполне новый, дедупликация точно есть.
С нативно вроде тоже есть что-то, но о статусе тоже без понятияНативно развивается в последнее время, но ещё не продакшн. Всё же затупляет и подвисает иногда. По крайней мере когда последний раз трогал.
Пробовал: http://wiki.freebsd.org/ZFSTuningGuide#NFS_tuning?
vfs.zfs.zil_disable="1"
In latest ZFS (version 28) the vfs.zfs.zil_disable loader tunable was replaced with the "sync" dataset property. You can now enable/disable ZIL on a per-dataset basis.
zfs set sync=disabled tank/dataset
У меня там не просто файлопомойка, мне консистентность данных как бы важна. Надо будет попытаться выловить этот баг.
Если надёжность дисков A и B (разных производителей то "общая надёжность" двух разных равна max(A, B).в любом случае. какова вероятность вылета одновременно обоих дисков?
Т.е. если ты берёшь только A или только B, то можешь попасть на менее надёжную партию.
какой бы из дисков не вылетел - менять в любом случает придётся.
даже при выборе пары из менее надёжных вылетит один, а не оба сразу.
Опять же, ты сейчас сидишь в линуксе обвешанном всякой хренью, из которой реально нужно полторы софтины, а не в ядре + /bin/bash.Да ладно? 0_o
Конфиг для линукса я делаю сам, выбрасывая все замеченные лишние драйвера и подсистемы. А моя система не знает что такое: hal, dbus, acpi (кроме ноута acl, nls, lvm и ещё много всего, чего сходу и не упомнишь.
В общем, у меня установлено только то, что мне действительно нужно и чем я хоть иногда пользуюсь.
даже при выборе пары из менее надёжных вылетит один, а не оба сразуПод "сразу" нужно понимать время, необходимое мне на осознание, что проблема имеет место и на покупку нового харда. С учётом того, что я слоупок и харды ещё с августа собираюсь купить, это "сразу" становится крайне растяжимым понятием.
А моя система не знает что такое: hal, dbus, acpi (кроме ноута acl, nls, lvm и ещё много всего, чего сходу и не упомнишь.Линукс 90-х?
С учётом того, что я слоупок и харды ещё с августа собираюсь купить, это "сразу" становится крайне растяжимым понятием.Вообще-то резервный покупается вместе с основными, сразу.
ага, 3.0.6
Просто я не вижу никакой пользы от этого для себя. А некоторые вещи даже не знаю зачем нужны в принципе. Например, nls. Если я не знаю что это, то мне это не нужно. Задача порождает инструмент для её решния, а не наоборот.
Просто я не вижу никакой пользы от этого для себя. А некоторые вещи даже не знаю зачем нужны в принципе. Например, nls. Если я не знаю что это, то мне это не нужно. Задача порождает инструмент для её решния, а не наоборот.
Вообще-то резервный покупается вместе с основными, сразу.Предлагаешь купить третий? И чтобы он просто валялся без дела? То есть не в 2 раза сокращать объёмы, а в три?
Кстати, ты CUPS конфигуришь через веб-интерфейс или редактируешь конфиги вручную?Да, через веб... но вообще когда я это делал в первый раз, очень сильно плевался, что везде конфиги, а тут вдруг веб-интерфейс.
Но, благо, его можно один раз настроить и забыть про него.
Предлагаешь купить третий? И чтобы он просто валялся без дела? То есть не в 2 раза сокращать объёмы, а в три?Ну а что делать? Впрочем, для как раз таких случаев делают raid5 с одним диском в горячем резерве. Потери в объеме такие же, но вроде как, кажется, получается надежность выше.
Впрочем, для как раз таких случаев делают raid5 с одним диском в горячем резерве.Для этого минимум 4 диска уже надо.
в любом случае. какова вероятность вылета одновременно обоих дисков?Ну это сложный вопрос. Она может быть небольшая, а может быть и большая.
Он ещё должен будет проработать какое-то время до покупки нового и так же для создания его зеркала на новый.
И всё же вероятность того, что одинаковые диски сломаются в близком интервале выше, чем это будет с разными.
raid5 противоречит принципу KISS
И он становится крайне подвержен полному сбою, если вышел из строя один из дисков. Если брать 4 диска, то я бы сделал raid10. А ещё лучше просто сделаю два raid1 в двух компах в разных местах с синхронизацией по сети. Прочем, для этого четырёх дисков и не надо - хватит как раз трёх (в одном месте рейд, в другом один диск)
И он становится крайне подвержен полному сбою, если вышел из строя один из дисков. Если брать 4 диска, то я бы сделал raid10. А ещё лучше просто сделаю два raid1 в двух компах в разных местах с синхронизацией по сети. Прочем, для этого четырёх дисков и не надо - хватит как раз трёх (в одном месте рейд, в другом один диск)
Да, через веб... но вообще когда я это делал в первый раз, очень сильно плевался, что везде конфиги, а тут вдруг веб-интерфейс.Ну с FreeNAS примерно также, я полагаю.
Но, благо, его можно один раз настроить и забыть про него.
И он становится крайне подвержен полному сбою, если вышел из строя один из дисков.А зеркало разве не становится? Очевидно, что зеркало ломается с меньшей вероятностью, но тут баланс между полезным местом и отказоустойчивостью
Ну с FreeNAS примерно также, я полагаю.Как минимум, его надо обновлять наверное?
Сходу же захочется настроить синхронизацию с удалённым сервером по rsync по крону. Это тоже через веб-интерфейс делать?
Даже если и делать, то как я например подключу проверку на достаточное количество предоплаченного траффика у провайдера перед синхронизацией? (да, у меня лимитированный интернет, 50 Гигов в месяц на максимальной скорости мне больше нравится, чем медленный анлим и полностью хватает для моих нужд, особенно если учесть накопление).
Ну и вообще, кто знает что ещё мне потом взбредёт в голову сделать
Так что чёрные ящики - зло.А зеркало разве не становится? Очевидно, что зеркало ломается с меньшей вероятностью, но тут баланс между полезным местом и отказоустойчивостьюНа зеркало не возрастает нагрузка при чтении. А на рейд-5 сильно возрастает. В нормальном режиме каждый квант информации будет читаться только с одного из четырёх дисков, а в критическом - сразу со всех трёх оставшихся.
Ещё raid5 тормознутее при записи.
А вообще, лучше погуглить про BAARF - Battle against any raid 5
Вообще-то резервный покупается вместе с основными, сразу
Это актуально, когда в начале покупаются одинаковые винты.
А если
беру разные!- тогда смысл-то какой?
С большим успехом можно потом купить 3-й разный винт.
Имеет смысл сразу покупать только если предполагается, что они перестанут продаваться, ну или подорожают.
Впрочем, для как раз таких случаев делают raid5 с одним диском в горячем резерве.
Сколько всего перечитал на эту тему - рэйд5 никто не рекомендует - уж тогда рэйд6, но без горячего резерва (по дискам столько же, сколько и рэйд5 с горячим, а надёжность выше).
Если брать 4 диска, то я бы сделал raid10.
У нас образовались компы с 4-мя терабайтниками - после некоторых экспериментов сделал на них 2 раздела: в начале терабайт в рэйд0 под систему/проги/темпы, а остальное в рэйд10.
Только вот надо будет бакап настроить...
Ещё raid5 тормознутее при записи.За счет чего это? Мне кажется это старая инфа с тех времен когда контроллеры не успевали ксорить за записью.
Теоретически рейд-5 должен быть всегда быстрее.
Надо ж не просто записать блок в два места, как в raid10. Надо сначала прочитать с двух других дисков в массиве соответствующие ему блоки, вычислить блок чётности и записать исходный блок и его.
Это ещё и износ, имхо, должно увеличить.
Это ещё и износ, имхо, должно увеличить.
За счет чего это? Мне кажется это старая инфа с тех времен когда контроллеры не успевали ксорить за записью.
Теоретически рейд-5 должен быть всегда быстрее.
Ну думаю ряд ли он будет быстрее без аппаратного рэйд-контроллера.
А это явно вне темы.
А это явно вне темы.Тема уже закрыта. Так что неважно.
Как минимум, его надо обновлять наверное?Что значит "надо"? Ровно также как надо обновлять FreeBSD или какой-то Linux. Хочешь - обновляешь, не хочешь - не обновляешь.
Сходу же захочется настроить синхронизацию с удалённым сервером по rsync по крону. Это тоже через веб-интерфейс делать?Синхронизация через rsync это отстой. Правильный способ таков примерно: zfs snapshot на оригинале, потом zfs send этого снапшота на копию, потом zfs promote на копиии. И если всё прошло хорошо, то перекидываем ключевой симлинк на новый снапшот. Старые после этого можно удалить.
Даже если и делать, то как я например подключу проверку на достаточное количество предоплаченного траффика у провайдера перед синхронизацией? (да, у меня лимитированный интернет, 50 Гигов в месяц на максимальной скорости мне больше нравится, чем медленный анлим и полностью хватает для моих нужд, особенно если учесть накопление).
Не знаю, реализована ли эта технология в FreeNAS в веб-интерфейсе. Если нет, то никто не мешает её реализовать через обычный шелл.
Ну и вообще, кто знает что ещё мне потом взбредёт в голову сделатьА это не чёрный ящик, это дополнительный функционал с открытыми исходниками к открытой операционной системе.
Правильный способ таков примерно: zfs snapshot на оригинале, потом zfs send этого снапшота на копию, потом zfs promote на копиииВо-первых, это значит, что и в удалённой локации должна быть zfs, а это уже точно не так.
Во-вторых, судя по последовательности, пересылается не diff, а весь снапшот? Если так, то это вообще не вариант.
Что значит "надо"? Ровно также как надо обновлять FreeBSD или какой-то Linux. Хочешь - обновляешь, не хочешь - не обновляешь.Конечно, я хочу обновлять. И не очень понимаю как в веб-интерфейсе делать make buildworld
А это не чёрный ящик, это дополнительный функционал с открытыми исходниками к открытой операционной системе.Ну так этот фукционал и так можно легко добавить чрезе порты
Во-первых, это значит, что и в удалённой локации должна быть zfs, а это уже точно не так.Пересылается diff, и rsync и близко не приближается к той скорости, с которой этот метод работает. Не говоря уж о том, что апдейт происходит атомарно, на что rsync тоже не способен.
Во-вторых, судя по последовательности, пересылается не diff, а весь снапшот? Если так, то это вообще не вариант.
Конечно, я хочу обновлять. И не очень понимаю как в веб-интерфейсе делать make buildworldЯ не очень понимаю зачем делать buildworld на ящичке, выполняющем функции NAS, если ты не разработчик или бета-тестер софта, который работает в этом ящичке. Поэтому, если хочется обновлять FreeNAS, нужно просто запустить bla-bla-bla-upgrade.sh
Ну так этот фукционал и так можно легко добавить чрезе портыНасколько мне известно, портов, полностью реализующих весь функционал FreeNAS, нет. Насколько я понимаю, у них есть свои патчи к CAM, к NFS, AFS и CIFS, за которыми стабильные версии FreeBSD не поспевают. И возможно какие-то расширения API. Поэтому им удобнее делать цельный релиз, а не порт. Ну и у них просто не хватит manpower чтобы сделать FreeNAS в виде пакета, который поддерживает не конкретные релизы FreeBSD, а может быть установлен и одинаково хорошо заработает на любом снапшоте между 7.0-RELEASE и недавним CURRENT.
Пересылается diff, и rsync и близко не приближается к той скорости, с которой этот метод работает. Не говоря уж о том, что апдейт происходит атомарно, на что rsync тоже не способен.Да, я уже почитал немного по теме, шикарная вещь, да.
Я вот только не смог нагуглить: переименование директории этот механизм понимает при пересылке diff-а или считает это удалением и созданием новой? У rsync эта фееричная бага (она by design) заставляет меня сортировать данные сразу в двух местах.
Я не очень понимаю зачем делать buildworld на ящичке, выполняющем функции NAS, если ты не разработчик или бета-тестер софта, который работает в этом ящичке. Поэтому, если хочется обновлять FreeNAS, нужно просто запустить bla-bla-bla-upgrade.shНу да, так, наверное, разумнее. Правда менее прозрачно. Впрочем механизмы make buildworld и портов тоже не совсем прозрачны.
у них есть свои патчи к CAM, к NFS, AFS и CIFSНаверное, это хорошо... Но я оцениваю вероятность, что мне реально понадобится функционал, который есть во FreeNAS, но нет в обычном порте нужной софтины, как маловероятную. А выборочно принять или отказаться от этого функционала я получается не могу. Ну то есть могу, исходники открыты, но уже далеко не малой кровью
На зеркало не возрастает нагрузка при чтении. А на рейд-5 сильно возрастает. В нормальном режиме каждый квант информации будет читаться только с одного из четырёх дисков, а в критическом - сразу со всех трёх оставшихся.Ну, во-первых, на зеркале нагрузка при чтении возрастает ровно в 2 раза. А в случае RAID-5 я вижу смысл читать все блоки, только в случае, когда нужный попадает на сбойнувший винт. В остальных случаях они так же лежат в неизменном виде.
Ещё raid5 тормознутее при записи.Я мог неправильно запомнить, но кажется в случае с ZFS это не так.
Я мог неправильно запомнить, но кажется в случае с ZFS это не так.Недавно тестил на запись raidz1 из 4xSamsung 500Gb (на SATA RAID 3Ware "9550-чего-то там" в режиме пассфру) примерно следующим скриптом:
n=0;while dd if=/dev/mem of=/zmain/${n} bs=1M count=1024; do n=$${n}+1; done Скорость записи блока в 1Gb варьировалась от 70Mb/s в самом конце диска (когда уже и места свободного оставалось не много до 230Mb/s в начале.
При чём значения менее 150Mb/s начали появлятся только после заполнения половины объёма.
А скорость чтения, как ни странно, несравнимо ниже - 110-140Mb/s даже при пустом пуле.
Сами диски дают при линейном чтении 80Mb/s в начале и где-то 40 в конце диска. Аппаратный RAID5 не выдаёт на чтение и 90Mb/s. RAID10 - 150Mb/s.
Если с убогостью аппаратного RAID5 я уже смирился, то какого фига raidz выдаёт на чтение в 2 раза меньше, чем на запись?!
Оставить комментарий
dangerr
Хочу организовать в домашнем компе raid1, используя встроенные механизмы btrfs.В сети советы диаметрально разнятся: кто-то соверует брать диски одной и той же модели, а кто-то, наоборот, предупреждает, что такое черевато тем, что вслед за первым может сдохнуть и второй, так как одинаковые диски эксплуатируются в одинаковых условиях.
Кому верить?