3TB диски и mdadm

Но ты подумай, сколько времени займёт его ресинк или чек.

ресинк можно ускорять, а чек шедулить на выходные. не надо оффтопить.

Можно ли создать раздел под raid, размером почти 3TB ?

Да

Зависит ли это от размера сектора диска (512 или 4096 байт)?

Насколько я помню, не существует дисков размером больше 2 Тб с размером сектора 512 байт.

(имеется в виду с использованием GPT)

А по другому никак. mbr максимум 2 Тб. Так что либо gpt, либо вообще таблицу разделов не создавать.

либо вообще таблицу разделов не создавать

а куда тогда grub записывать? Я предполагал разбиение: protective MBR + GPT-1 + grub-раздел + raid-раздел + GPT-2

Меня другое волнует - в самих метаданных raid-раздела есть ограничения?

либо вообще таблицу разделов не создавать

а куда тогда grub записывать?

Значит тебе без gpt не обойтись

https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
Current Linux kernels (as of 2.6.28) can only autodetect (based on partition type being set to FD) arrays with superblock version 0.90.

The version-0.90 superblock limits the number of component devices within an array to 28, and limits each component device to a maximum size of 2TB on kernel version <3.1 and 4TB on kernel version >=3.1.

в чём заключается вопрос?

ну, например, почему есть разница в 2 и 4 TB - это signed/unsigned или что?

Если ищешь смысл жизни - читай исходники ядра

Кстати, по приведённой тобой ссылке

As a workaround for the kernel-autodetection issue, several distributions, including Ubuntu and Fedora, circa early 2009, include init scripts that run any arrays that aren't started by auto-detect, which can include arrays using the newer 1.x superblocks.

mbr максимум 2 Тб

Только если с раздела нужно загружаться. Делал софт рейд 0 на венде из 3 1.5ТБ (или 2 ТБ, уже не понмню) дисков.

/dev/md0:
        Version : 1.2
  Creation Time : Tue Oct 15 22:48:44 2013
     Raid Level : raid5
     Array Size : 8790405120 (8383.18 GiB 9001.37 GB)
  Used Dev Size : 2930135040 (2794.39 GiB 3000.46 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Fri Sep  5 15:12:31 2014
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : armserv:0  (local to host armserv)
           UUID : acbd62d2:ca7b4ff8:d0e7b753:5024ed6f
         Events : 502

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       4       8       64        3      active sync   /dev/sde

А в чем проблема вообще?

Гхм. Не рейд до 2 Тб. Один диск при использовании mbr максимум 2 Тб

Сори, туплю.

в чем проблема вообще?

недолюбливаю init-скрипты

Насколько я помню, не существует дисков размером больше 2 Тб с размером сектора 512 байт.

4.2 Seagate Constellation ES.3 у меня такие на 3 Тб, 512 байт сектора там.

6 ТБ и высочайшая скорость

интересно как добились. С 4кб сектором быстрее же позиционируется?

Но зато надо в 8 раз больше прочитать чтобы хоть что-то вернуть, нельзя же вернуть часть сектора.

бред. Там и так читается не один сектор из-за ФС

Ух ты, raid5 на трёхтерабайтниках. Рисковый ты парень!

А в чем проблема? У raid5 есть какие-то особенности о которых я не в курсе?

Видимо, да, не в курсе. При выходе из строя одного диска большого объёма в RAID5 и последующем ребилде при вставке нового есть неиллюзорная возможность выхода из строя второго диска (эта возможность растёт с увеличением объёма каждого диска в RAID5 и на 3Tb дисках составляет где-то 10-15%, адрес pdf-ки не помню) и превращения DEGRADED RAID5 (что является RAID0) в тыкву со всеми данными.

Ну согласись что это верно для любого raid5, и размер тут не принципиален. А вообще по такой логике даже raid1 можно назвать ненадежным, ведь при выходе из строя обоих дисков мы потеряем все данные!

Я бы может и рад зарядить побольше избыточности, но домашних NAS-серверов больше чем на четыре диска я не видел, а raid10 это мне кажется оверкилл.

Ну согласись что это верно для любого raid5, и размер тут не принципиален.

Как раз размер - принципиален. С увеличением объёма дисков увеличивается вероятность выхода из строя второго диска в RAID5 при восстановлении.

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

Я конечно не знаю кто и как и по какой методике мерил эти проценты, но принципиальной разницы я не вижу.

Вот статья, показывающая принципиальную разницу «на пальцах»: http://habrahabr.ru/post/78311/

В ней есть ссылки, но, к сожалению, изначальный pdf я так и не нашёл...

Как раз размер - принципиален. С увеличением объёма дисков увеличивается вероятность выхода из строя второго диска в RAID5 при восстановлении.

Звучит так, как будь-то у нас гарантированно с ростом объемов падает надежность... Если это так, то дискеты самое надежное хранилище

Прочитай ссылку, потом делай выводы, ок?

А поцчему ви таки критикуете за рейд 5 ежели в теге возле топика написан рейд 6?

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

Статья дурацкая. Я конечно плохо знаю что такое BER применительно к дискам, как он считается и что на самом деле означает (сейчас буду на эту тему читать, ибо самому интересно), но одно могу сказать точно: если у автора статьи получается что из-за этого BER связка из двух дисков 1ТБ+1ТБ более надежна чем 1 диск в 2ТБ, то брешет этот автор как сивый мерин, уж не знаю где конкретно.

А в целом суть статьи сводится к одной простой мысли: raid-10 более надежен чем raid-5. Ну блин, кто бы сомневался.

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

А ви таки походите по подветке и посмотрите, кому я отвечал изначально :)

Статья дурацкая. Я конечно плохо знаю что такое BER применительно к дискам, как он считается и что на самом деле означает

«Не читал, но осуждаю», ну-ну...

если у автора статьи получается что из-за этого BER связка из двух дисков 1ТБ+1ТБ более надежна чем 1 диск в 2ТБ

Что это вообще за бред??

А в целом суть статьи сводится к одной простой мысли: raid-10 более надежен чем raid-5. Ну блин, кто бы сомневался.

Почитай не только эту статью, а вообще по теме восстановления raid5 на больших дисках. Суть их одна - уход с raid5 на raid6 (или, что ещё лучше - на raidz2)

Ваистену зря он своим пятым рейдом хвалится, тем более без битмапа, на сервере, в имени которого присутствуют буквы «arm».

Статья дурацкая. Я конечно плохо знаю что такое BER применительно к дискам, как он считается и что на самом деле означает

«Не читал, но осуждаю», ну-ну...

Не передергивай. Лучше расскажи нам что же такое BER раз сам такой умный.

если у автора статьи получается что из-за этого BER связка из двух дисков 1ТБ+1ТБ более надежна чем 1 диск в 2ТБ

Что это вообще за бред??

А вот именно такой бред получится если как следует разобрать логические выкладки автора статьи. Ты почитай внимательно что он пишет. У него выходит что если у диска BER=10^-15, то это означает что диск ломается со 100% вероятностью через 110ТБ прочтенных данных. Даже если откинуть то, что человек абсолютно не понимает что такое вероятностное распределение, и что такого рода вещи не могут иметь линейной зависимости, такое бытовое использование параметра BER (а я еще раз повторю что сам я не знаю что он означает применительно к дискам) будет означать что если допустить что у всех современных дисков BER примерно одинаковый, то с двух дисков по 1ТБ мы успеем прочесть вдвое больше информации до момента поломки чем с одного диска в 2ТБ. Из чего я делаю вывод что не только я не понимаю что же такое BER, но и автор статьи. С той только разницей что я в своем незнании имею смелость честно признаться.

Что же касается «почитай вообще», я знаю ограничения raid5 и проблемы что с ними связаны. Я понимаю что чем больше избыточность тем больше надежность, но это не означает что я готов себе на домашнее хранилище ставить NASы профессионального уровня. Или жертвовать 50% дискового пространства.

Ваистену зря он своим пятым рейдом хвалится, тем более без битмапа, на сервере, в имени которого присутствуют буквы «arm».

Во-первых я не хвалюсь, а показываю техническую возможность такового (именно об этом стоял изначальный вопрос в ОПе), а во-вторых, ты что-то имеешь против армов? Может я что-то не знаю не только про raid5 но и про армы? Давай же, расскажи, почему raid5 на x86 будет надежнее чем на arm?

Я понимаю что чем больше избыточность тем больше надежность

Это если без учёта объёма дисков. Есть выкладки в т.ч. netapp про зависимость вероятности ошибки при восстановлении raid5 от объёма дисков.

http://unix.stackexchange.com/a/5168

Да не, понятно что вероятность того что диск сломается на протяжении чтения 3ТБ в несколько раз (хотя и не ровно в три, а поменьше) больше чем при чтении 1ТБ. Просто я считаю что и та и другая вероятность достаточно малы. Мой сервер на одних только торрентах раздает до 0,5ТБ за сутки. Если я начну бояться за количество прочтенных данных, я лучше его сразу выключу нафиг.

хвалишься тем что собрал пятый рейд на громадных дисках на арме, никто в здравом уме не будет отрицать, что рейд можно собрать на любом железе, куда вкорячится линукс и несколько дисков. Когда тебе придётся заменять один из дисков на дрищеарме без битмапа в течение нескольких дней, и поплохеет второму диску, массиву придёт кирдык. Давай прооппонируй мне, что твой арм, с полутора инструкциями и усб вместо sata, под нагрузкой перелопатит массив быстрее чем х86 со всякими sse4 и человеческом sata.

Давай прооппонируй мне

Ну я даже не знаю с чего начать, твой пост настолько полон глупости...

что твой арм, с полутора инструкциями

У моего «дрищеарма» есть XOR/DMA offloading engine предназначенный специально для ускорения raid-операций. А чем в этом плане может похвастаться «х86 со всякими sse4» хотелось бы знать?

без битмапа

Читаем linux raid wiki: «If one spindle fails and has to be replaced, a bitmap makes no difference.» Хм, у меня такое чувство что кто-то строит из себя спеца не зная матчасти.

усб вместо sata

Это где это ты видел NASы с USB вместо SATA?

под нагрузкой

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

и поплохеет второму диску, массиву придёт кирдык.

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

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

Мне это напомнило анекдот «виндузятник отвечает: это технически невозможно, линуксойд - можно, но вы об этом еще пожалеете»

:)

есть XOR/DMA offloading engine

и он работает, или ты знаешь, что он там есть?

If one spindle fails and has to be replaced, a bitmap makes no difference

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

Это где это ты видел NASы с USB вместо SATA?

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

Если во время восстановления raid1

только он синхронизируется в разы быстрее

и он работает, или ты знаешь, что он там есть?

https://github.com/torvalds/linux/blob/master/drivers/dma/mv_xor.c

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

Лучше бы ты понял что иногда ты ошибаешься, и научился в этом признаваться.

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

И много ты видишь вокруг себя специализированных NAS-серверов? А я ничего про это не написал потому что это не имело отношения к вопросу ОПа. Чтоб ты там ни думал, задачи хвастаться своим сервером передо мной не стоит.

только он синхронизируется в разы быстрее

Обоснуй? Я бы еще понял если бы ты сказал что в востановлении raid1 участвует только 1 диск, в то время как в востановлении raid5 — 3, и следовательно вероятность факапа утраивается. Это был бы действительно валидный аргумент, но ты сказал какую-то туфту. Впрочем, как обычно.

обосновать тебе, что терабайтный рейд1 ребилбится быстрее чем трёхтерабайтный рейд5 после замены диска? считай что это туфта и хвастайся дальше специализированным nas на arm

чем в этом плане может похвастаться «х86 со всякими sse4

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

Возможно. Но тогда и там и там все упрется в производительность дисков. Что толку если твой проц может поксорить гиг в секунду, если диск читает только 160МБ.