Данная тема открыта для обсуждения и выбора винчестеров размером от 1.5 ТБ и выше.
Тема для обсуждения и выбора винчестеров размером до 200 гигабайт находится здесь.
Тема для обсуждения и выбора винчестеров размером от 250 до 500 гигабайт включительно находится здесь.
Тема для обсуждения и выбора винчестеров размером от 600-от гигабайт до 1 терабайта находится здесь.

Внимание: Barracuda 7200.12 Firmware Update

Полезная информация по жёстким дискам Seagate: [FAQ] Выбор винчестера от 1.5 ТБ и больше #17062202

Перед тем, как задать вопрос, прочитайте, пожалуйста, FAQ. Это в ваших же интересах.

А как мне понять, какие модели из моего списка не SMR?

Обычно есть даташит. Или например - 1-2 тб диски с большим кэшем 128-256 - smr. 2-4 по сути если имеют 256 кэша, то тоже smr. Большие диски уже лучше искать в даташите, так как там кэш уже не показатель. Можно сказать так - если кэш на дисках до 4 тб = 64 мб, то 100% они не smr.

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

читал я эту муть, тупая реклама. Вы лучше просто исследуйте, как выглядят реально метаданные в массиве ZFS. Только полный дебил такое сотворит. )
В принципе понятно почему, иначе система не будет работать с нормальной скоростью. Её разработчики, понятия не имеют как диски реально работают и умирают.
Я же писал уже. Только до вас не доходит. ну как можно хранить контроль в родительской структуре. т.е. отдельно от самих данных. Любой сбой в "родителе" и "сына" не найдешь и не проверишь.
аналогично, все ваши скрабы лежат далеко от самих данных. упал скраб и ищи свищи данные. А структура, размер блоков переменный, где кончается, где начинается, хрен определишь без исходной структуры.
EXTх системы все имеют возможность создавать резервные блоки, иметь контрольные суммы. Только в реальности, эти возможности практически ни когда не используются, потому что дико тормозят работу.
Вот и получается, описание возможностей в рекламном листке и действительность - две большие разницы. Они уже выпустили штук 40 версий ZFS. Но в каждой чего-то не до делали.
Разбирать все версии при восстановлении данных, ни какая программа не справится. Под каждый случай пиши свою утилиту. Потому я даже и заморачиваться не хочу, глубоко в нее лезть. Попробовал, не справляется программа, иди к черту. Сам выбрал эту дрянь. ))

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

А вот убитую в 0 zfs я тоже в живую видел и могу сказать один способ это реализовать, во всяком случае на линуксе. Собственно другие ФС так тоже превращаются в фарш. А достаточно просто полностью кончить память и оставить систему так висеть какое то время (и это хорошо вписывается в "вечером работало утром не работало").
Правда было то что я видел на достаточно старом ядре, может сейчас ситуация лучше...

Чего человек не понимает, так это того, что есть куча сценариев когда любой массив не выживет. Их много даже в датацентрах (вот, к примеру, интересный случай который относительно хорошо кончился), а уж про "дома" и говорить нет смысла. У нас вот к примеру недавно хороший дождик прошел, инфраструктуру слегка потрепало, я в розетке 300В видел. И это хорошо у меня есть ИБП, он показывает напряжения(вход/выход) и я в этот момент не спал. ИБП перешел на батарею сам, а я сразу пошел рубанул вход в квартиру чтобы холодильники и прочее не погорело. Ну или чего стоит только старая шутка про сервер который упал со стола. И таких возможных ситуаций, даже не задумываясь о возможных сбоях/багах железа и/или софта (кому интересно можно почитать про американские проблемы с налогами в 2018, например), очень много.
Ну не обеспечивает никакая одна система надежного хранения данных. Какой бы дорогой и навороченной она не была. И к слову сам факт что такого рода вещи попадают на восстановление данных тому хорошее подтверждение.

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

Что значит кончить? Забить всё пространство или разговор про ram?

Добавлено спустя 14 минут 29 секунд:


Контролер чего, zfs напрямую с дисками связь имеет и если её (zfs) ставят поверх рейда или на прослойку в виде raid0 волумов, виртульных дисков, и ещё какой мути - она то тут причём (zfs)?

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



То у тебя потоп, то пожар, то жена, то дверь. Ты в Сирии чтоль живёшь? Тебе походу и в глухом бункере массив удасться ушатать.

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

Вы не слышите что вам говорят. У меня клиентов как грязи, прятаться приходится. у которых именно что-то случилось, начиная от обычного хлопка дверью.
Если один диск в массиве не ожиданно сдох, с большой вероятностью он не один и другие скоро накроются, и любят они это делать именно во время ребилда массива.
Вот для плановой замены рейд подходит, а для не ожиданных отказов дисков очень плохо приспособлен.
Датчики ни разу от ударов и вибраций не защищают, когда они выше допустимых. Событие уже началось и дергаться бесполезно. Дернется, в момент воздействия, пол поляны процарапает. Единственная польза от них, прекратить операцию записи и повторить ее, когда сигнала с датчика не будет. Ну и еще для переносных, определить невесомость, чтобы успеть запаковаться. Только чистая невесомость без задевания за все что попало, редко возникает, чтобы ее диск четко определили успел убрать головки с рабочей поверхности. Диск такая парковка часто не спасает, все равно может головки погнуть, но хоть поверхность не царапает.
Без датчика, диск хреново запишет и даже знать не будет. Диск запись сразу не проверяет.
Вас не кто не пугает, просто это надо понимать и предпринимать соответствующие меры. В одном корпусе много дисков, типа для резервного копирования, это всегда плохо. На все диски сразу действуют одинаковые не благоприятные события.
По этому дома, если у тебя не круглосуточная непрерывная работа, ни какой рейд не нужен в принципе. Надежность любого рейда, ниже чем у одного диска. только зеркало приближается по надежности к одному диску.
Можно диски вставлять, использовать переносные, копировать по сети в другую комнату. Но если они все работают в одной коробке, то и сдохнут практически одновременно, от любого неблагоприятного события.

чёчёчё. То есть ты хочешь сказать, что 1 диск (кстати,а что там с хлопками дверей лютой жены и прочими воздействиями???) будет надёжнее 8 дисков в масcсиве с 2/3-ой избыточностью?



Вы пишите бред какой то.



Если их с окна выкинуть может тогда одновременнут сдохнут, ага ... У вас там круглосуточные бомбардировки по квартире/дому чтоли?


Добавлено спустя 1 минуту 42 секунды:


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


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

Во деревня!
http://max.horosh.ru/raid/
https://habr.com/ru/post/78348/

Добавлено спустя 2 минуты 56 секунд:

Диск что каждый блок перечитывает, после записи? скорость упадет 3-4 раза.
Так что пофигу что до этого считали, потом просто наткнешься на сбой.

Ты нормальный, нет? raid5 в 2020? Ты ещё за 2000 года статьи дай.

И да из той же лохматой статьи:

"Возвращаясь к примеру с диском WD Caviar Blue, AFR для него равна 1,3%."

и чуть ниже:

Для примера с WD Caviar Blue вычислим вероятность того, что массив выйдет из строя и все данные будут утеряны:

AFR(RAID0) = 2.7%
AFR(RAID1) = 0.02%
AFR(RAID10) = 0.04%
AFR(RAID5 из 3х дисков) = 0.05%
AFR(RAID5 из 5и дисков) = 0.18%
AFR(RAID5 из 8и дисков) = 0.48%

Ты вообще читаешь, что ты там постишь?

Добавлено спустя 1 минуту 20 секунд:


без коментариев...

Вот тебе про raid6 почитать :

https://www.ibm.com/support/pages/re-ev ... ger-drives

Cool'D
Надо все читать вдумчиво, а не только то, что вам нравится.
Частота ошибок Unreadable Read Errors (URE) ни какого отношения не имеет к отказам из-за различных событий эксплуатации.
гугль вам посчитал эту статистику, до 10%. и у гугля условия работы дисков, куда лучше чем у людей дома.
в рейде диски работают в одинаковых условиях, выход из строя сразу нескольких дисков, также стремится к 10%
Во время ребилда, вероятность отказа больше 10%. Каждый последующий год AFR проседает в три раза.
Вы раз в год сталкиваетесь с мертвыми дисками, я около 500 в год вижу. крупные DR фирмы до нескольких тысяч в месяц.
Основная причина отказов любых дисков это царапины пластин различной степени тяжести. Все остальные причины вместе взятые и 5% процентов от всех отказов не наберут.

Ни чего не поменялось.
в то время диски были в разы надежнее, если сейчас посчитают на современных, в осадок выпадут. )
Что не диск принесут больше 4 терабайт, сразу запилен в хлам. Только если повезло, диск сразу заблокировался и клиент сам его не смог поковырять всякими R-студиями и MHDD.

А ну понятно, опять бомбить будете по харнилищу? Ну ок, чем тогда 1 диск будет лучше, если он точно так же отъедет от любого чиха, или у него какая то уличная магия в защите?

Добавлено спустя 10 минут 2 секунды:


Пруфы можнно? реальные, а не ваша филькина грамота с потолка взятая.

С сайте ibm другие цифры :

Putting all the results in a table, we have the following:

Да что ж вы понять ни как не можете, зачем городить рейд, когда не нужен постоянный круглосуточный доступ. удорожать систему в разы, когда надежность практически одинаковая.
Гугль же точно не стучит по своим дискам, но отказывает до 10% вместо 1%, если бы не было внешних воздействий.
А таких внешних воздействий много, всех и не перечислишь, которые могут убить диск. я уж 15 лет только данными занимаюсь и не перестаю удивляться очередным нежданчикам у людей когда они все диски сразу грохают.
Я бы нахрен все уже забросил, так задолбали, но пристают и пристают со своими данными. Вообще ничего делать не дают. Круглые сутки, только восстановление данных. Пожрать не отойдешь.
С рейда по любому нужно делать резервную копию. ну так какая разница, с одного диска ее делать или с массива.
Ну бывает большой объем сразу нужен, для весьма редких дел. Ну так собери составной том, не расходуя диски на ненужную избыточность.

надёжность raidz2/3 в десятки раз выше raid1, про соло диски я вообще молчу.



даже если каждый 10 диск будет дохнуть в первые 5 лет, в raid 6 шанс потерять что то будет меньше 1%.

Добавлено спустя 1 минуту 6 секунд:


Ненужную избыточность? А если какой то диск отъедет или даже 2 или 3?

Под памятью я всё же понимаю память оперативную, озу, ram как угодно.
И речь о том, что во всяком случае некоторое время назад линукс доведенный до того состояния, когда память кончилась совсем и защитные механизмы вроде убийства процессов уже ничего не способны сделать при опеределенных условиях делал плохие вещи с фс. Сильно плохие.
Но опять же это не суть, не повод раскапывать старые проблемы (которые, предположу, уже починили), а всего лишь пример.

Tomset,
ИМХО восприятие того, какова надежность рэйдов и причины их отказа сильно искажено взаимодействием в основном с отказавшими экземплярами которые принесли на восстановление.
Любой избыточный рэйд надежнее одного диска. Потому, что вероятность отказа у 1 диска 100% (рано или поздно он неизбежно выйдет из строя), а рэйда же, даже в максимально неблагоприятных условиях, она ниже.
Подавляющее число отказов рэйдов не связано напрямую с дисками. Обычно это или разгильдяйство (отсутствие своевременной замены неисправных/частично неисправных дисков) или ошибки софта/сбои контроллера/отказ контроллера или внешние воздействия вроде сбоев питания, температур, итд. Это в условиях серверной, дома ситуация другая. Большинство отказов во время ребилда происходят либо по причине того, что рэйд пол года проработал без 1 диска и его решили заменить только когда возникли проблемы или по причине наличия в составе массива полуживых дисков которые "он же еще поработать может" и менять не стали.
Нормально организованный массив, с горячим резервом, своевременныой заменой и без внешних воздействий может жить десятилетиями и пережить замену всех дисков по несколько раз. Без всякой плановой замены.
Однако это никак не отменяет того факта что вероятность отказа есть всегда, независимо от того какой это массив, как он реализован итд. Поэтому бэкапы конечно же обязательно, иначе рано или подно появится новый клиент сервиса по восстановлению данных. И это же делает рэйды бессмысленными дома - зачем платить за ненужную отказоустойчивость/доступность при том что бэкапы нужны в любом случае и они же полностью решают проблему сохранности.... в общем всё сводится к тому, что для каждой задачи нужно использовать соответствующий инструмент, а не пытаться забивать гвозди микроскопом

Да ничегоподобного. Пактически стандартый сценарий. Начали ребилд и все разволилось.
Ну не выходят они из строя по одному, если один резко сдох, то и остальные не лучше, на грани. Трудно все это считать, да мне и не нужно. Редко кто догадается проверить все диски, после сбоя одного.
Начинаешь проверять остальные, якобы живые, а они в сбоях. И приходится сколько дисков, столько и задач создавать, из которых потом собираешь рейд задачу, чтобы учесть сбои на каждом.
Логические сбои, ошибки администраторов, в целом редко восстановимы полностью, только часть. Всяким базам обычно трындец. Обычно или диски перепутали, ребилдили масив с диском, который аж несколько лет назад отвалился от массива или система не дописала чего. Самое распространенное, один админ собрал рейд, уволился, другой полез, когда проблемы возникли, не разобрался и накосячил.
Буквально последний случай, ни кто не знает что за рейд, 4 диска Тошиба MK2001TRKB SAS все стучат, поддержки ни какими утилитами этих дисков нет и вряд ли будет. Их вообще ни кто из знакомых ни когда не видел. Слезная история, разругались, что-то бывший админ сделал в обиде. Заказал из китая доноры, переставил головки из пациентов в них, работают. А пациенты также стучат с донорскими головками. И ни чего не сделаешь. Так и пришлось отказаться.

Инфа из 2000х? Что не ребилд - то разваливается. Да я принудительно с 10 попыток не смог рейд софтовый развалить даже когда достал больше дисков чем парити было, рубанул питание, и потом попробовал собрать, а тут прям развал на развале.

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

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


И у меня лично тут сразу 2 вопроса: Через сколько после отказа диска начат ребилд? И были ли в массиве другие диски со сбоями до отказа диска который ребилдят?


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


Контроллер либо софт догадывается. Регулярно. А если отключили опять ошибка пользователя.


Да-да, вот именно это. И диски тут не виноваты совсем.


Такие опыты малополезны. Они проводятся с заведомо исправным железом и представляют из себя наиболее предсказуемые и простые сбои.
Гораздо хуже когда все диски старые, некоторые уже имеющие проблемы с чтением итд.

Я откуда знаю, Мне уже диски с мертвого рейда приносят, без контролера, а потом уже по датам файлов или структур метаданных видишь. Что тут часть свежая, а тут древняя. хотя должны быть очень близкой даты. Рейд контроллер (или программный рейд) только за адресами LBA следит, синхронизированы или нет. Содержимое секторов его ни как не касается.

Опять ерунда, диски ему сообщают о своем состоянии и проверяют себя периодически. Контролер только за базой синхронизации следит. не помню точно как называется, LDM вроде. И хранится база на диске, в конце обычно.
Вообще я рейдами не увлекаюсь, желания их глубоко ковырять ни когда не было. Приносят, комплекс может сделать, делаю, не может, да ну его нафиг.
Не таскали бы, я с огромным удовольствием не делал их ни когда. ))

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


Нет, не ерунда.
Приведу как пример mdraid.
Там по умолчанию так:

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