Сыпется ext4/soft raid/hard

Ваши идеи, что делать

Юзать всё же аппаратные рейды с батарейкой...

давайте без холиваров, давайте по существу

Проверь массив на консистентность. Если контроллер по-тихому испортил данные, драйвер MD об этом не узнает до следующей попытки чтения/записи. И для «по существу» ты не предоставил почти никаких данных.

что для «по существу» надо предоставить, какие данные, говорите, покажу.

Как появились ошибки? После очередного перебоя питания?
Состояние массива не менялось?
dmesg, если машина не перезагружалась.
Проверку массива уже сделал?

для всех дисков Raw_Read_Error_Rate не нуль

Уж сколько раз твердили миру, что RAW_VALUE для Raw_Read_Error_Rate смысла несет примерно 0. VALUE же равно 200, так что проблем с диском по приведенным данным смарта не вижу, диск нулевый, как из магазина.

ошибки проявились когда rsync выкатил «error input/output»; перебой питания был только один раз когда заглючил xfs dmesg приводил, акромя ничего нету, dmesg -c чтобы не мешало, ничего криминального не было. массив щас принудительно проверяю, пока всё ок.

RAW_VALUE для

забыл если честно)

с учётом переинтерпретации данных со smart диски впоряде, ожидаю окончание проверки рейда.

Винты живые. /proc/mdstat что показывает? Вполне возможно проблема с памятью, проверь и ее тоже. Часто бывало, что при ошибках с оперативкой на винты записывается не то, что нужно.

Write-intent bitmap юзается?

ЗЫ: У меня XFS на RAID6 из 11 винтов переживал уже десятки внеплановых выключений, и ничего ему не становится. Проблемы ИМХО у тебя с железом или руками :)

а как мне поможет Write-intent bitmap, если оно для более быстрой проверки рейда? мне что 4 часа проверяться будет, что 8.

память нормальная, серверная ecc/reg, мемтест нормально всё сказал.

насчёт рук возможно, но то, что xfs теряет часто данные, которые были записаны уже 100500 лет назад - не я один наблюдал, либо вы счастливчик, либо у n числа админов руки кривущие. даже и не знаю :)

Если ошибка на диске - почему raid не просёк их?

Он просекает только ошибки с доступом а не корректность данных. Без контрольных сумм всё бессмысленно т.к. даже если verify найдёт отличия рейд не поймёт какие данные более правильные. Если только у тебя в рейде не три винта а сбоит только один.

Контрольные суммы есть 1) у raid5,6, etc 2) продвинутых файлух, но в линухе таких нету (бтрфс не готов) 3) наверняка есть модуль для какого-нить device mapper для этого

У RAID5/6 есть только ксор, который не поможет выявить ошибок. Тут нужны контрольные суммы поблочно, как у ZFS. И уже после выяснения того, что контрольная сумма блока не совпадает с оной в метаданных, уже использовать ксор для восстановления.

Может я его как-то не так использую? :) Я чесслово сомневаюсь, что у ФС, которую пилят уже 20 лет остались такие детские болезны.

По ошибкам уже объяснили. Рейд видит ошибку, только если нижележащий слой сообщает ему об I/O error. Иначе - в багдаде всё спокойно.

Если хочется полной безопасности, юзай ZFS в режиме RAID-Z2 (аналог RAID6), он для линукса уже вполне стабилен (http://zfsonlinux.org/). Я его юзаю в качестве резервной копии с дедупликацией - проблем не имею пока. Скорость конечно местами заставляет желать лучшего, но если памяти дофига, то в общем терпимо.

У RAID5/6 есть только ксор, который не поможет выявить ошибок.

почему не поможет? Сравниваем актуальную информацию с восстановленной, вот и всё.

И вообще у них есть parity bit, вот.

Ну, давай представим R5 из трех дисков: P = A ^ B Допустим, блок А у нас побился. Как это выяснить? Сделаем B ^ P , получим != A. Но с тем же успехом это может означать, что побился блок B, а не A. Кого будем восстанавливать? :)

В RAID6 аналогично. Только там помимо XOR считается еще и код Рида-Соломона, почитать можно тут: http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf

Но оно опять таки не может выяснить битый ли конкретный блок.

В ZFS же на каждый 128Кб блок (по умолчанию) при записи считается SHA1. И при чтении блока с диска опять высчитывается SHA1 и сравнивается с той, что в метаданных. Если не совпадает, то уже используется механизм, аналогичный RAID5/6 для восстановления блока.

0_o хто это? :)

В ZFS же на каждый 128Кб блок (по умолчанию) при записи считается SHA1.

Там у ZFS есть свойства на конкретную ФС, какой алгоритм использовать или не использовать вообще:

zfs set checksum=on | off | fletcher2 | fletcher4 poolname/fsname

(currently, fletcher4, but this may change in future releases).

В последней версии md для софтверного RAID Linux, кажется, написали приблуду, сравнивающую идентичность блоков данных (с двух зеркал RAID-1, например) на лету. Раньше это можно было определить только прямым сравнением блоков двух зеркальных носителей, запуская отдельную утилиту (в фоне). То есть в обычном режиме использования сбойный RAID в Linux (и GEOM Mirror FreeBSD, кстати) считался целым и детектировался самим пользователей только по «ощущениям», что что-то не так. :))

Ну, давай представим R5

да, и получим что у нас в одном из трёх случаев сумма будет отличиваться, верно? Вот это случай и единственно верный т.к. остальные две будут получены с использованием неисправного винта.

хто это? :)

контрольный бит для контрольных сумм.

Нуу, товарищ, включаем голову.

Вот есть три равенства, в том случае когда все блоки целы:
P = A ^ B
A = P ^ B
B = P ^ A

Если у нас побьётся A, то все три равенства неожиданно станут неравенствами, так же как и если побьётся P или B.

контрольный бит для контрольных сумм

Нет там никакого контрольного бита на уровне RAIDа в классических RAID5/6.
Есть только Parity-блок P. Почитай.

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

Так же может менятся на лету и размер блока, что вообще сродни магии)

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

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

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

Нет там никакого контрольного бита

да, я ошибся.

B Допустим, блок А у нас побился. Как это выяснить? Сделаем B ^ P , получим != A. Но с тем же успехом это может означать, что побился блок B, а не A. Кого будем восстанавливать

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

софт рейд оперирует чанками, для них интересно рассчитывается ли какой нить md5, ну чтобы убедиться что чанк нормальный?

Я как раз и говорю о том случае, когда диск или контроллер не рапортуют ошибок, но блок пишется криво.

От таких ошибок пока что может спасти только ZFS.

Даже если ему прямо на лету сделать dd if=/dev/urandom of=/dev/sda1 count=123467 seek=8910 и после этого запустить scrub, или просто попробовать прочитать файл с этого места, он всё восстановит.

софт рейд оперирует чанками, для них интересно рассчитывается ли какой нить md5, ну чтобы убедиться что чанк нормальный?

Чанк или страйп это одно и то же. Никакого md5 там не считается, какой смысл, куда его писать-то? Там считается только XOR.

Я тебе и показал с тремя винтами. Вычисляй :)

На первый винт пишется блок P, на второй - A, на третий - B. Классически минимальный RAID5.

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

ты прав, не получается.

Никакого md5 там не считается, какой смысл, куда его писать-то

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

Нет там никакой мета-информации. Поэтому и нет смысла.

ZFS это гибрид файловой системы и RAID5/6/7(?), поэтому там это всё есть где разместить. А в классическом рейде - негде.

на линухе есть ли что-то подобное (fuse не в счёт) ?

Нативный - http://zfsonlinux.org/

ZFS-FUSE тоже вполне себе функционален.

не внушает доверия для прода

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

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

итак, в поисках другой более надёжной и шустрой фс. кто что скажет о nilfs2 ?

EXT4 стабилен как танк. У тебя какие-то проблемы с железом судя по всему. У меня он на корневых фс на множестве серверов, как на железных рейдах, так и на софтовых, проблем никаких нет.

сейчас запустил smart тест на несколько часов, после него запущу тест на бедблоки, там будет видно. думаю сильно ли поможет пересоздание рейда на разделе.

Погоняй дд из /dev/zero на диск и обратно в /dev/null, может что и покажет. Контроллер какой, на котором винты висят? Может он косячит. Скрытую порчу данных сложно выявить, можно попробовать тот же зфс, либо просто погонять файлы на диски и обратно, а потом сравнить их хеши. У знакомого был такой прикол с контроллерами sil31xx кажись, просто втихую портили данные.

итак, долгий смарт тест завершился с успехом, без ошибок.

винты: [code] Device Model: WDC WD2002FAEX-007BA0 Serial Number: WD-WMAY01081841 Firmware Version: 05.01D05 [/code]

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

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

да, был ещё такой глюк - бэкапы делаются rsync, загонял один из таких бэкапов в tar/gzip/bz2 и скачивал на свою машину через ssh, при распакове - «crc error», распаковка на самом сервер без ошибок, повторная перекачка ту же ошибку выдала; тот же процесс,но для бэкапа за другую дату прошёл с успехом. не к добру всё это.

Явно какие-то проблемы с железом. Может с материнкой: чипсет там дурит или еще что... Так просто такие глюки не появляются. Надо пробовать менять компоненты по одному. Вынуть все планки памяти, кроме одной, попробовать. И т.п. Больше ничего тут посоветовать не могу.

так, если память ECC есть ли смысл её проверять вообще? по идее если ошибка в памяти - она бы отслеживалась?

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