Ошибка ввода / вывода при чистом разделе ext3 - как проверить, что не так с блоком данных
У меня проблема с файлом в разделе ext3 на сервере CentOS 5 (версия ядра 2.6.18-164.15.1.el5) с контроллером HP Raid:
hpacucli ctrl all show detail
Smart Array P410 in Slot 1
Bus Interface: PCI
...
Инструмент HP не сообщает о каких-либо проблемах.
Это обычный раздел ext3 с размером блока, равным 2k, и это нормально - вывод fsck:
fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Файловый индекс также в порядке:
File: `name.xxx'
Size: 3126962 Blocks: 6124 IO Block: 4096 regular file
Device: 6851h/26705d Inode: 64579729 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-07-28 09:02:59.000000000 -0400
Modify: 2014-07-28 09:02:59.000000000 -0400
Change: 2014-07-28 09:02:59.000000000 -0400
Одной из операций, которые я не могу выполнить, является копирование файла:
> cp /long_path/name.xxx .
cp: reading `/long_path.name.xxx': Input/output error
Чтобы определить, в чем проблема, я запускаю dd для копирования файла:
> dd if=/long_path/name.xxx bs=2048 of=test
dd: reading `/long_path/name.xxx': Input/output error
222+0 records in
222+0 records out
454656 bytes (455 kB) copied, 0.042867 seconds, 10.6 MB/s
Итак, я думаю, что проблема в блоке 223 файла.
Debugfs должен помочь найти этот блок на диске
debugfs -R "stat name.xxx" /dev/sdf
debugfs 1.39 (29-May-2006)
Inode: 64579729 Type: regular Mode: 0644 Flags: 0x0 Generation: 2900468317
User: 0 Group: 0 Size: 3126962
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 6124
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014
atime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014
mtime: 0x53d64a03 -- Mon Jul 28 09:02:59 2014
BLOCKS:
(0):130402311, (1-4):130402844-130402847, (5-6):130484033-130484034, (7):130484036,
(8-10):130484049-130484051, (11):130484055, (IND):130761221, (12-13):130761222-130761223,
(14):130763791, (15):130763942, (16):130765268, (17-23):130838937-130838943,
(24-46):130853946-130853968, (47-48):130855126-130855127, (49):130855215,
(50-53):130856428-130856431, (54-104):130856533-130856583, (105-341):130856748-130856984,
...
[MORE BLOCKS]
....
TOTAL: 1531
Поэтому я предполагаю, что проблемные данные находятся в блоке 130856866.
Как я могу получить больше информации об этом блоке? Я запускал плохие блоки, и у меня есть список плохих блоков. Я предполагаю, что мне нужно умножить указанный выше номер блока на 2 (размер блока файловой системы равен 2 КБ, а badblocks использует 1 КБ по умолчанию). Также badblocks проверяет диск, а не раздел, поэтому, возможно, мне следует добавить некоторое смещение (на этом диске есть один раздел, поэтому, вероятно, нет).
> fdisk -l /dev/sdf
Disk /dev/sdf: 2000.3 GB, 2000365379584 bytes
255 heads, 63 sectors/track, 243197 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/cciss/c0d5p1 * 1 243197 1953479871 83 Linux
Я также думал об использовании SmartD. Что я должен искать?
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 1457 0 2887405961 0 65948.712 18
write: 0 0 0 0 0 15056.493 0
verify: 0 1 0 361901613 0 3591.720 0
Non-medium error count: 226
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background long Failed in segment --> - 34479 16845361 [0x3 0x11 0x0]
# 2 Background short Completed - 44 - [- - -]
# 3 Background short Completed - 39 - [- - -]
# 4 Background long Completed - 6 - [- - -]
Long (extended) Self Test duration: 18500 seconds [308.3 minutes]
Background scan results log
Status: scan is active
Accumulated power on time, hours:minutes 34541:56 [2072516 minutes]
Number of background scans performed: 1139, scan progress: 38.18%
Number of background medium scans performed: 1139
# when lba(hex) [sk,asc,ascq] reassign_status
1 19215:06 0000000000014c61 [3,11,0] Recovered via rewrite in-place
2 19215:07 0000000000014c66 [3,11,0] Recovered via rewrite in-place
3 19413:28 0000000001010a31 [3,11,0] Require Write or Reassign Blocks command
4 19943:24 000000000001ea99 [3,11,0] Recovered via rewrite in-place
5 20152:23 00000000000232b8 [3,11,0] Recovered via rewrite in-place
6 31229:34 810000004087f984 [3,11,0] Require Write or Reassign Blocks command
7 33021:51 810000004087ba85 [3,11,0] Require Write or Reassign Blocks command
8 33021:51 000000004087ba9f [3,11,0] Require Write or Reassign Blocks command
9 33021:52 000000004087bad6 [3,11,0] Require Write or Reassign Blocks command
10 33029:43 000000004087baa5 [3,11,0] Require Write or Reassign Blocks command
11 33055:27 000000004087bac3 [3,11,0] Require Write or Reassign Blocks command
12 33244:40 810000004087f9d6 [3,11,0] Require Write or Reassign Blocks command
13 33431:58 990000004087f105 [0,0,0] Reassignment by disk failed
14 33480:17 00000000463d7713 [3,11,0] Require Write or Reassign Blocks command
15 33480:19 00000000463d7723 [3,11,0] Require Write or Reassign Blocks command
16 33480:20 00000000463d7725 [3,11,0] Require Write or Reassign Blocks command
17 33480:28 81000000463d774e [3,11,0] Require Write or Reassign Blocks command
18 33686:17 8100000044e50edc [3,11,0] Require Write or Reassign Blocks command
19 34154:17 81000000432bef27 [3,11,0] Require Write or Reassign Blocks command
20 34463:43 810000001f32decd [3,11,0] Require Write or Reassign Blocks command
21 34463:43 0000000030080000 [3,11,0] Require Write or Reassign Blocks command
Как мне выйти замуж за выход Smartctl (или любой другой вывод из SmartD Run) с моей первоначальной проблемой.
Также не должна ли эта проблема решаться программным обеспечением HDD?
КСТАТИ. Я нашел следующую ссылку полезной для понимания вывода 'debugs -R'. Может быть, эта ссылка будет полезна для другого.
ОБНОВИТЬ
Проведя дальнейшие исследования, я обнаружил, что действие, связанное с проблемными inode (например, приведенная выше команда cp), запускает следующую строку в журнале ядра:
kernel: cciss: cmd ffff810037e00000 has CHECK CONDITION sense key = 0x3
"Смысловой ключ" является "статусом" и частью стандарта SCSI ( список здесь и подробное описание здесь).
3 ответа
Итак, чтобы понять это, я сделал следующее.
Возьмите свой номер блока, умножьте на четыре и добавьте один
(130856866 * 4) + 1 = 523427465
Это представляет сектор, о котором сообщают, что он производит ошибку ввода / вывода. Размер блока 2 КБ, секторов 512 байт. Дополнительный дополнительный счет учитывает смещение начального сектора для раздела.
Чтобы соответствовать SMART, нам нужно преобразовать имеющееся у нас значение в шестнадцатеричное.
$ printf "0x%x\n" 523427465
0x1f32de89
Теперь, когда вы соотносите это с тем, что показывает SMART, линия подозрительно приближается.
20 34463:43 810000001f32decd [3,11,0] Require Write or Reassign Blocks command
Как далеко?
$ bc -l
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=16
ibase=16
1F32DECD-1F32DE89
44
Это получается только между 34816 и 32768 байтами, но мы не можем сказать, какой сектор поврежден из четырех, составляющих блок.
Если бы мне пришлось рисковать предположением, я бы сказал, что, вероятно, существует целый ряд блоков вокруг одного и того же адреса, который будет сообщать об ошибках ввода / вывода (при условии, что полоса рейда имеет размер, скажем, 32 КБ или какой-либо другой).
Кроме того, чтение может не решить проблему, если RAID извлекает блок-блок с другого диска. Запись должна распространяться на все диски в настройке RAID1, так что это может привести к сбою записи, но успешному чтению. Кроме того, если мы предположим, что размер фрагмента карты RAID равен 32 КБ, мы также можем предположить, что поврежденный блок плюс тот, о котором сообщил SMART, оба повреждены тем, что произошло на этом блюде. Это просто тест SMART, считанный с хорошего диска для первых 32 КБ и с плохого диска для следующих 32 КБ.
Современные жесткие диски сохраняют "резервные сектора" для замены поврежденных секторов, таких как этот, на новое расположение секторов. Видя, как вы сейчас получаете это, и что это Reassign by disk failed сообщение от умного я бы сказал, что диск закончился.
С точки зрения того, чтобы что-то делать с этим; это немного сложнее. Адресация LBA - это абстракция против реального диска под ним. Вам нужно будет определить, какой именно диск вызывает эту проблему, выполнить сбой в массиве RAID и заменить его.
В любом случае, у вас плохой диск, и вы должны заменить его как можно скорее.
Это много для обработки... Но кое-что выпрыгивает из меня.
Версия вашего ядра: 2.6.18-164.15.1.el5 - это устанавливает вашу версию ядра на уровень EL5.4 или около марта 2010 года.
У меня были постоянные проблемы с файловой системой ext3 и проблемы с повреждениями в EL5. Вещи не были полностью исправлены до середины 2012 года. В худшем случае я работал с фирмой облачной инфраструктуры, которая никогда не обновляла ядра с их базового выпуска. Поэтому я начал видеть эти проблемы в масштабе тысяч серверов EL5.
Есть ли шанс, что вы сможете обновить вашу OS/kernel/e2fsprogs, fsck и попробовать еще раз?
Кроме того, если ядро установлено примерно в 2010 году, BIOS вашей системы и прошивка Smart Array P410, вероятно, сильно устарели. Что это за модель сервера?
Редактировать:
Ваши ошибки cciss CHECK_CONDITION - это раздача. Не нужно даже иметь дело с SMART на этом этапе. Запустите утилиту HP Array Diagnostic, и она отправит информацию об ошибке в отчет. В любом случае, я действительно надеюсь, что это не массив RAID5.
Можете ли вы опубликовать вывод hpacucli ctrl all show config detail?
Фактически вышедшие из строя блоки читаются из журнала ядра, который вы можете прочитать где-то ниже. /var/log (наверное /var/log/kernel.log) или из вывода dmesg команда.
Осторожно: вам нужен не номер сектора диска, а номер блока, специфичного для раздела и файловой системы. Ядра начиная с версии 2.4.x говорят о них обоих в dmesg.
Давая -L Флаг e2fsck может передать этот список блоков в список плохих блоков файловой системы. Таким образом, правильными шагами являются следующие:
Во-первых, проверьте список плохих блоков из dmesg.
Во-вторых, поместите их в простой текстовый файл, так
cat >badblockfile.txt
34252345
3452345
23452345
(Ctrl / д)
e2fsck -f -y -C0 /dev/diskname -L badblockfile.txt
Если вы не можете интерпретировать dmesg, поместите соответствующие части здесь как комментарии или как продолжение вашего вопроса.
РАСПРОСТРАНЕНИЕ
Ваша файловая система имеет 2k-блока и запускается на первом секторе вашего жесткого диска (который имеет 512 байт-секторов). Таким образом, формула между блоками файловой системы (которая может быть передана e2fsck) и дисковым блоком (который находится в выводе dmesg), если очень проста:
filesystem_block=(serctor_no-1)/4
Если в ваших сообщениях нет блоков на уровне файловой системы, вы также можете использовать эту формулу.
АЛЬТЕРНАТИЧЕСКИЙ СОВЕТ
Также есть дополнительный совет: у e2fsck есть флаг -c, Это вызывает инструмент badblocks перед проверкой и помечает обнаруженные плохие блоки как плохие. Как я понял, это не совсем хорошо, в большинстве случаев он не может найти все плохие блоки. На вашем месте я запустил это на выходные (или, по крайней мере, на ночь) в бесконечном цикле:
while true; do e2fsck -f -y -C0 -c /dev/sdf;done