yigal_s: (Default)
[personal profile] yigal_s
В общем, одну вещь я установил с достоверностью: при обнаружении плохого сектора линуксовский RAID-1 способен считать те же данные с другого диска. Капитан Очевидность подтверждает.

Паника и вырывание волос были преждевременны.

Вопрос же о том, восстанавливает ли RAID после этого битый сектор более проблематичен. Есть две конкурирующие гипотезы:

1) не восстанавливает, гад! Хотя документация линукса утверждает, что восстанавливает и пока нет достоверных свидетельств против этого.

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

Достоверность второй гипотезы подтверждается тем, что мой диск согласно SMART параметрам пока еще не ремаппировал ни один битый сектор (что может свидетельствовать и о верности гипотезы 1), но зато уменьшил счетчик "Current Pending Sector Count" c четырёх до двух (т.е. отказался от ремаппирования, даже предварительно согласившись). До двух, и это при том, что не читаются 200 секторов! ( а как он мог отказаться от ремаппирования? Возможно, снова попытавшись записать на битые сектора данные, но данные он мог взять только если RAID попытался восстановить сектора, что означает, что гипотеза 1 не верна). Т.е., похоже, падло пытается зареюзать битые сектора и всячески вообще притворяется работоспособным. Мои безумные подозрения перемещаются теперь от авторов RAIDa к WD. потёр очередной поток некомпетентного бреда.

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

Ещё немножко поиграюсь с этим диском, потом попробую его (вернее, весь взбесившийся RAID) заскрабить средствами линукса и наконец отформатировать в ноль средствами Windows а потом утилитами WD и вставить обратно в старый рейд. Посмотрим, произойдут ли при этом ремаппирования.

Date: 2017-05-31 03:04 pm (UTC)
shadsky: (Default)
From: [personal profile] shadsky
но у вас по крайней мере не происходит то, что описано в вашей ссылке?
https://raid.wiki.kernel.org/index.php/Timeout_Mismatch
"Unfortunately, with desktop drives, they can take over two minutes to give up, while the linux kernel will give up after 30 seconds. At which point, the RAID code recomputes the block and tries to write it back to the disk. The disk is still trying to read the data and fails to respond, so the raid code assumes the drive is dead and kicks it from the array. This is how a single error with these drives can easily kill an array."
прочитав это, я почти перестал сомневаться, что у меня RAID на WD 1.5G периодически рассыпался и пересобирался именно по такому механизму

Date: 2017-05-31 05:17 pm (UTC)
shadsky: (Default)
From: [personal profile] shadsky
у меня был не софтовый linux-raid, а дешевая sata-карточка, на которой, насколько я понимаю, raid организуется полусофтово-полухардверно, совместно контроллером и драйвером; но алгоритм видимо работал подобным образом. и у нее был еще один (большой) недостаток - в режиме raid она была непрозрачна, не давала доступ к smart дисков.

Date: 2017-05-31 08:39 pm (UTC)
shadsky: (Default)
From: [personal profile] shadsky

у меня вот комментарий к pending sector count говорит, что если он после постановки на учет будет записан или ПРОЧИТАН успешно, то исключается из списка;если верить этому - то не обязательно была попытка записи. ну и что ошибка чтения не приводит к его ремаппингу, только ошибка записи, - что да, как-то очень странно и стремно. с другой стороны, линукс сообщает идентичное записанному в этот регистр значение как число bad sectors - т.е. может на уровне файловой системы они все же помечены как bad и фактически перемещены..

Date: 2017-05-31 09:34 pm (UTC)
shadsky: (Default)
From: [personal profile] shadsky
а в вашей коробочке NAS внутри линукс же небось на флеше? нельзя там установить свою систему?.. я бы даже не удивился - если бы обнаружилось, что у энтузиастов есть готовая прошивка

Date: 2017-05-31 10:10 pm (UTC)
shadsky: (Default)
From: [personal profile] shadsky
вроде бы извлеченный из зеркала диск функционален сам по себе и не имеет специфических системных областей, так что наверное да, системные записи тоже попросту зеркалятся на оба диска, и соответственно содержимое дисков обязано совпадать с точностью до сектора. тогда бад-сектора можно только или ремапить через контроллер, или помечать одновременно на обоих дисках.
вообще-то отсюда по-моему следует, что для домашнего применения простому периодическому бэкапированию нет альтернативы.

Date: 2017-06-01 09:02 am (UTC)
shadsky: (Default)
From: [personal profile] shadsky
у меня схематические представления о raid примерно так сложились : )
- в основе идеи RAID да, stripe RAID 0, возникший из необходимости записывать realtime на диск потоки, с корорыми они тогда не справлялись (видео, телеметрия). решение тривиально - распараллелить поток на n дисков, и все, что нужно от контроллера - расщеплять номер логического сектора Nl на номер физического Nf= div(Nl,n) и номер диска i=mod(Nl,n) - естественно, при условии, что диски идентичны по своей организации.
- RAIR 1 еще проще - вообще не нужно никаких операций, кроме дублирования потока на два диска.
- RAID 5 тогда - абсолютно тот же srtipe RAID 0, только дополненный слоем-диском (одним или m) для записи xor потоков на идентичные сектора собственно информационных дисков.
Такая структура максимально проста для реализации и имеет минимум накладных расходов, при том что абсолютно прозрачна и органично совместима с любой файловой системой - при условии, что с проблемой нарушения идентичности организации дисков при появлении сбойных секторов борются сами диски; и действительно, такой механизм - remapping - в них уже встроен. (правда, вот почему бы не сигнализировать в систему и не помечать в системной области как цепочки из n BAD при появлении на одном диске сбойного блока все его подобия соответствующие остальным дискам - я придумать не могу.. ну разве что кроме ригористической скупости)
если же мы решим отобрать ремаппинг у диска и взять его в свои руки - мы будем вынуждены создать преизрядный дополнительный слой, осуществляющий трансляцию логических секторов в физические заведомо нетривиальным, накладным по времени и памяти образом типа просмотра индивидуальных для каждого диска таблиц сбойных секторов при каждом обращении. Фактически, это эквивалентно внедрению между собственно файловой системой операционки и контроллером еще одной виртуальной файловой системы, полностью дублирующей уже имеющиеся в контроллере функции; я могу понять разработчиков, которые всячески избегают такой накладной во всех отношениях мороки, предпочитая тем или иным образом пинать имеющиеся в дисках механизмы ремаппинга, надеясь заставить их работать. Увы, эти механизмы по-видимому изменчивы и непрозрачны, и трюки, срабатывавшие ранее, иногда на новых моделях вдруг перестают работать. но все же в таких ситуациях справедливее желать бить по голове разработчиков дисков, чем кого-то еще. Альтернатива - видимо да, создание файловой системы, в которую эти механизмы встроены изначально и которая может работать без прослойки; наверное это и реализовано в RAID-Z на ZFS
я понимаю, что я одновременно дилетант и капитан очевидность ; ) - ну так уж, просто воспользовался местом-поводом, чтобы для себя что-то уложить, пардон..
Edited Date: 2017-06-01 09:06 am (UTC)