У меня проблема с файлом в разделе ext3 на сервере CentOS 5 (версия ядра 2.6.18-164.15.1.el5) с помощью HP Raid Controller:
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 КБ, а для плохих блоков по умолчанию используется 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
Тоже думал использовать смартд. Что мне искать?
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. Может это ссылка на сайт будет полезно еще для одного.
ОБНОВИТЬ
В ходе дальнейшего исследования я обнаружил, что действие, связанное с проблемными индексными дескрипторами (например, указанная выше команда cp), запускает следующую строку в журнале ядра:
kernel: cciss: cmd ffff810037e00000 has CHECK CONDITION sense key = 0x3
«сенсорный ключ» - это «статус» и часть стандарта SCSI (список здесь и другое описание Вот).
Это много для обработки ... Но кое-что меня бросает в глаза.
Версия вашего ядра: 2.6.18-164.15.1.el5 - это помещает вашу версию ядра на уровень EL5.4 или около марта 2010 г..
У меня были постоянные проблемы со стабильностью файловой системы ext3 и ее повреждением в EL5. До середины 2012 года все не было полностью исправлено. В худшей ситуации я работал с фирмой, занимающейся облачной инфраструктурой, которая никогда не обновляла ядра по сравнению с их базовой версией. Итак, я начал видеть эти проблемы в масштабе тысяч серверов EL5.
Есть ли шанс обновить вашу ОС / ядро / e2fsprogs, fsck и попробовать еще раз?
Вдобавок, если ядро около 2010 года, BIOS вашей системы и прошивка Smart Array P410, вероятно, сильно устарели. Что это за модель сервера?
Редактировать:
Ваши ошибки cciss CHECK_CONDITION - это подарок. На этом этапе не нужно даже иметь дело со SMART. Запустить Утилита HP Array Diagnostic и он выведет информацию об ошибке в отчет. В любом случае, я действительно надеюсь, это не массив RAID5.
Можете ли вы опубликовать вывод hpacucli ctrl all show config detail ?
Итак, чтобы понять это, я сделал следующее.
Возьмите номер своего блока, умножьте на четыре и прибавьте один
(130856866 * 4) + 1 = 523427465
Это представляет сектор, о котором сообщается, что произошла ошибка ввода-вывода. Размер блока 2k, секторов 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, прочитанный с хорошего диска для первых 32k и плохого диска для следующих 32k.
Современные жесткие диски сохраняют «резервные сектора» для замены таких поврежденных секторов на новое место. Видя, как вы сейчас получаете это, а то Reassign by disk failed сообщение от смарта я бы сказал, что закончился диск.
С точки зрения того, что с этим делать; это немного сложнее. Адресация LBA - это абстракция от реального диска под ним. Вам нужно будет определить, какой именно диск вызывает эту проблему, вывести его из строя в массиве RAID и заменить.
В любом случае, у вас плохой диск, и вам следует заменить его как можно скорее.
Фактически отказавшие блоки можно прочитать из журнала ядра, который вы можете прочитать где-нибудь ниже. /var/log (наверное /var/log/kernel.log), или с выхода dmesg команда.
Будьте осторожны: вам нужен не номер сектора диска, а номер блока, зависящего от раздела и файловой системы. Ядра, начиная с версии 2.4.x, говорят о них обоих в dmesg.
Давая -L флаг для e2fsck может передать этот список блоков в список плохих блоков файловой системы. Таким образом, правильные шаги следующие:
Сначала проверьте список плохих блоков из файла dmesg.
Во-вторых, поместите их в простой текстовый файл, чтобы
cat >badblockfile.txt
34252345
3452345
23452345
(ctrl / d)
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