Десктопные диски в программном RAID

Десктопные в принципе можно, если они не WD Green.

Может не парится и купить несколько WD Green?

WD Green не советую вообще для использования.
Без перепрошивки диска система замирает секунд на 10.

Ты о их фирменной принудительной парковке головок, которая включена по умолчанию? На прошлой работе был NAS 3-х дисках Green в RAID5 - вроде пока ничего не рухнуло.

УМВР. Бери Blue, тем более, что Green мало от них по цене отличаются.

А больший буфер (64 против 32 МБ) погоды не делает?

Думаю, что нет. Особенно с учетом того, что операции чтения / записи все равно кэшируются системой, а там кэш на порядок больше, чем эти жалкие 32-64 Мб. Плюс в одном из массивов, в RAID5, дополнительно еще пара сотен метров выделена под stripe cache.

Использую такие модельки:

root@melissa:/home/rain# hddtemp /dev/sd?
/dev/sda: WDC WD10EZEX-00RKKA0: 35°C
/dev/sdb: WDC WD10EZEX-00RKKA0: 34°C
/dev/sdc: WDC WD10EZEX-60ZF5A0: 36°C
/dev/sdd: WDC WD10EALX-009BA0: 37°C
/dev/sde: WDC WD10EALS-002BA0: 39°C
/dev/sdf: WDC WD10EALS-00Z8A0: 40°C
/dev/sdg: WDC WD10EALS-00Z8A0: 38°C
/dev/sdh: WDC WD10EALS-002BA0: 38°C

EZEX'ы весьма годные, остальные со старых времен остались.

WD Red?

Если шарага не большая, ни какого смысла в серверных дисках нет. У себя на работе использую обычные бюджетные системники, большая часть, вообще старьё PIII - PIV. Под сервера, на которые есть нагрузка, можно бюджетное геймерское железо взять. В общем системники за 10 или 15 штук, в зависимости от нагрузки. Шарага в которой я тружусь, ~100 человек(тех, что сидят за компьютерами).

юзаю в домашнем серваке 2 десктопных самсунговских харда 2Тб 5400, полет нормальный.

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

Здесь написано про wdtler.exe и smartctl утилиты для превращения обычного диска в серверный.

Хочешь сказать, что в программном RAID1 все будет подвисать, пока система не поймет, что на определенном диске там-то и там плохие секторы?

I/O будет замораживаться пока операция не пройдет. И да, серверных это тоже касается. Только у них тайм-аут 7 секунд, у десктопных - до 20-30. В целом - небольшая проблема.

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

у десктопных - до 20-30.

Я правильно понял - 20-30 секунд - это время, когда диск должен попытаться сделать ремап плохого блока? И если не успевает сделать ремап в рамках этого интервала, выдает ошибку и ядро его выкидывает из RAID?

Многое прочитал, потратил кучу времени, но не зря. Если у диска нет TLER/ERC/CCTL, то с некой вероятностью можно облажаться при восстановлении массива. Представим, что у нас зеркало из 2х дисков. Если поползли плохие секторы и диск не успевает их рамапить на запасной участок, ядро после второй неудачной попытки почесть/записать данные выкидывает диск из массива. Таймаут каждой попытки 30 сек (это прописано в ядре, а не в диске). У десктопного диска может даже не быть своего таймаута для самостоятельной коррекции плохого сектора. В итоге в массиве остается один диск. Хорошо, меняем поврежденный диск, начинается восстановление массива. И если вдруг окажется, что на диске, с которого восстанавливается массив, долго и незаметно таился плохой сектор, то это попадалово. Если и этот диск самостоятельно не успеет исправится, его выкинут из массива, который, к сожалению не успел восстановится. Самолечение «правильных» дисков с TLER/ERC/CCTL обычно не длится больше 7 секунд. И пока не закончится место на запасном пространстве для ремапа плохих секторов, их никто не выкинет из массива. Массив из таких дисков будет более живуч, чем десктопный массив. TLER есть в дисках WD серии RED - они дороже десктопных, но заметно дешевле серверных. С другой стороны не известно на сколько это все маркетинг и при каких условиях у десктопных дисков происходит медленное самолечение - может они тупят, когда уже нет места на запасном пространстве, а может они зависают при любом ремапе плохого сектора. Потом еще пошуршу по сайтам, может у других производителей тоже есть доступные и живучие диски для RAID.

Несколько моментов:

1. Драйвер md перезаписывает сбойный сектор если не читается (для авторемапа). Результат не проверяется (если таблица ремапов полная - ой).

2. Ремап практически не занимает времени - оно тратися на попытки спасти инфу со сбойного сектора.

3. Если с рейд1 идет чтение, то сбой никак не влияет на скорость.

4. Диски самостоятельно ничего не делают (только заполняют смарт).

Речь о дестопных дисках.

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

Если один из винтов вывалился из массива - при наличии на 2-м винте бэда ребилд не пройдет независимо от того, насколько кошерные винты; массив в процессе ребилда развалится и все.

Смарт проверка и периодическая проверка рэйд-массива в помощь, чтобы спалось спокойно.

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

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

Если с рейд1 идет чтение, то сбой никак не влияет на скорость.

Неотремапенный бэдблок очень сильно влияет на целостность данных и, вследствие этого, когда ОС обнаруживает несоответствие CRC прочитанного файла, начинает перечитывать этот файл заново — пока не считает все его блоки данных правильно.

Не так давно md в Linux научился считывать и сравнивать блоки данных с обоих дисков, но делает ли он при несоответствии какой-то фикс и в чём это выражается?

Десктопные в принципе можно, если они не WD Green.

Как сейчас говорят, слоупок детектед

Без перепрошивки диска система замирает секунд на 10.

Что за перепрошивка, почему не знаю? Ты хотел сказать - без настройки времени парковки утилитой wdidle?

Недостающее тупо считывается с зеркала, а bad перезаписывается. До vfs дело не доходит (какой такой CRC?). Да, это относится к raid1 и raid10, как оно там в других не в курсе.

md, как виртуальное блочное устройство, имеет определённый размер блока (страйпа), разве нет?

Да.

Недостающее тупо считывается с зеркала, а bad перезаписывается. До vfs дело не доходит (какой такой CRC?). Да, это относится к raid1 и raid10, как оно там в других не в курсе.

Я правильно понял? При наличии TLER и RAID1: 1) Чтение. Блок на диске непрочитывается в течении 7 секунд, диск кидает ошибку. Данные считываются с зеркала и все продолжает работать. Ремап делается или нет? 2) Запись. Блок не записывается в течении 7 секунд. Диск кидает ошибку. Ремап на поврежденном диске и все продолжает работать?

Речь о десктопных винтах: 1. Ядру наплевать чего и сколько там делает винт - по приходу UNC, считывается зеркало и блок перезаписывается (т.к. это единственный способ авторемапа для современных винтов, т.е. когда пользователь явно указывает что данные потеряли актуальность.). 2. По моим наблюдениям блок перезаписывается всегда (если нет - у винта или головка отвалилась или еще какой фатальный дефект), но не всегда после этого может прочитаться (если, например, таблица ремапа переполнена). Т.е. никаких задержек на этом этапе не будет и работать будет (мне лично наоборот не нравится - легко набрать неотремапленых бедов на разных дисках и на ресинке попасть в жопу).

У меня еще есть глупые вопросы. 1) А когда во время работы ядро выкидывает диск из массива RAID1? Когда некуда ремап делать или как? 2) Если говоришь, что бэды на одном диске сильно не влияют на скорость чтения целого массива, значит, пока десктопный диск пытается прочесть данные из убитых секторов и ядро ему делает софт-ресеты после таймаутов, система просто тупло продолжает читать данные со второго диска и параллельно ремапит убитые блоки первого? Просто в 7 или 30 секундах до «признания» ошибки на таком-то секторе есть разница. ИМХО есть вероятность, что до истекания 30 секунд и второй диск тоже может встретить убитый сектор. Интересно, что тогда ядро будет делать? Будет дожидаться софт-ресета на втором диске и ремапить первый диск данными из второго, а потом наоборот?

Не утерпел - глянул исходники (raid10):

1. Выкидывание идет после 20 ошибок (невозможности) чтения, причем текущее количество ошибок уменьшается в 2 раза каждый час (если нет новых).

2. Если ошибка записи в UNC сектор (для ремапа) или после записи прочитать не удается - выкидывает сразу.

3. На момент попытки исправления массив останавливается + некоторое время которое тратит винт на первоначальную попытку чтения.

Вывод: нужно иметь несколько массивов на одном винте - тогда балансировка нагрузки сама обойдет винт который в данный момент в занятом состоянии.

На мой взляд особой разницы 30 или 7 секунд нет - или сектор ремапится и без проблем (жалкая тысчонка другая секторов на 10-20тыс часов работы), или нет - тогда винт все равно под замену.

Ничего не будет. Это я первоначально пробежался впереди паровоза - массив всетаки замораживается. Если же массива, например, два на двух винтах, то один винт выкинет из одного другой из другого (предельный случай) и работа продолжится. Вот если беды полезут на обоих винтах на территории одного массива, то придется помучиться.