LINUX.ORG.RU
ФорумAdmin

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


0

1

Все добрый.

Centos 5.7. Сервер под бэкап, soft raid 6 (4 диска); был неожиданный ребут, апосля xfs, крутившийся на разделе потерял часть данных, переформатил раздел в ext4; проработало недели 2, сегодня в логах

EXT4-fs error (device md2): ext4_lookup: deleted inode referenced: 114205457
EXT4-fs error (device md2): ext4_lookup: deleted inode referenced: 113967281
EXT4-fs error (device md2): ext4_lookup: deleted inode referenced: 184009073
EXT4-fs error (device md2): ext4_lookup: deleted inode referenced: 184017329
EXT4-fs error (device md2): ext4_lookup: deleted inode referenced: 182911313
...

smartctl --all /dev/sd[abcd]

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       10
  3 Spin_Up_Time            0x0027   253   253   021    Pre-fail  Always       -       8916
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       15
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   094   094   000    Old_age   Always       -       4960
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       13
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       11
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       3
194 Temperature_Celsius     0x0022   113   102   000    Old_age   Always       -       39
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

для всех дисков Raw_Read_Error_Rate не нуль, максимальное значение 22; диски wd, в интернетах говорят что мол значение несколько единиц/десятков для любого диска это нормально; хз насколько это верно.

Если ошибка на диске - почему raid не просёк их? Если предположить что raid не зафакапил, остаётся что проблема в ext4.

Ваши идеи, что делать. Xfs до сих пор теряет данные (которые уже сто лет лежат на диске) при внезапном отключении эл-ва, да и медленный на миллионах файлах; ext3/jfs/btrfs не в счёт, рейзер...хз что с ним, уже не пилят его особо.

Ответ на: комментарий от loginrl103

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

GotF ★★★★★
()
Ответ на: комментарий от loginrl103

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

GotF ★★★★★
()

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

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

redgremlin ★★★★★
()
Ответ на: комментарий от GotF

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

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

loginrl103
() автор топика

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

blind_oracle ★★★★★
()
Ответ на: комментарий от loginrl103

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

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Ну, давай представим 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 для восстановления блока.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

В 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, кстати) считался целым и детектировался самим пользователей только по «ощущениям», что что-то не так. :))

iZEN ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

хто это? :)

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от iZEN

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

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

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

да, я ошибся.

true_admin ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

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

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

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от true_admin

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

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

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

blind_oracle ★★★★★
()
Ответ на: комментарий от loginrl103

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

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

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

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

loginrl103
() автор топика
Ответ на: комментарий от blind_oracle

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

loginrl103
() автор топика
Ответ на: комментарий от loginrl103

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

blind_oracle ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.