mdadm RAID5 случайные ошибки чтения. Умирающий диск?

Сначала длинная история:
У меня RAID5 с mdadm на Debian 9. Raid имеет 5 дисков, каждый размером 4 ТБ. 4 из них - это HGST Deskstar NAS, а один из них - Toshiba N300 NAS.

В последние дни я заметил некоторые ошибки чтения с этого рейда. Например, у меня был архив RAR 10 Гб в нескольких частях. Когда я пытаюсь извлечь, я получаю ошибки CRC в некоторых частях. Если я попробую это второй раз, я получу ошибки в этих частях. Это также происходит с торрентами и повторной проверкой после загрузки.

После перезагрузки мой BIOS заметил, что состояние SMART накопителя HGST на порте SATA 3 плохое. smartctl сказал мне, что есть ошибки DMA CRC, но утверждает, что с Drive все в порядке.

Еще одна перезагрузка позже, я больше не вижу ошибок crc в смарте. Но теперь я получаю этот вывод

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-4-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always   FAILING_NOW 1989

Поскольку HGST больше не доступны по нормальным ценам, я купил другую Toshiba N300, чтобы заменить HGST. Оба помечены как 4 ТБ. Я попытался создать раздел точно такого же размера, но это не сработало. Программа разбиения утверждала, что мое число слишком велико (я пробовал с байтами и секторами). Поэтому я просто сделал раздел настолько большим, насколько это возможно. Но теперь, похоже, он того же размера, я немного растерялся.

SD C старый, а SDH новый

Disk /dev/sdc: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4CAD956D-E627-42D4-B6BB-53F48DF8AABC

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 7814028976 7814026929  3,7T Linux RAID


Disk /dev/sdh: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3A173902-47DE-4C96-8360-BE5DBED1EAD3

Device     Start        End    Sectors  Size Type
/dev/sdh1   2048 7814037134 7814035087  3,7T Linux filesystem

В настоящее время я добавил новый как запасной диск. RAID все еще работает со старым диском. У меня все еще есть некоторые ошибки чтения, особенно на больших файлах.

Вот как выглядит мой RAID на данный момент:

/dev/md/0:
        Version : 1.2
  Creation Time : Sun Dec 17 22:03:20 2017
     Raid Level : raid5
     Array Size : 15627528192 (14903.57 GiB 16002.59 GB)
  Used Dev Size : 3906882048 (3725.89 GiB 4000.65 GB)
   Raid Devices : 5
  Total Devices : 6
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sat Jan  5 09:48:49 2019
          State : clean
 Active Devices : 5
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

           Name : SERVER:0  (local to host SERVER)
           UUID : 16ee60d0:f055dedf:7bd40adc:f3415deb
         Events : 25839

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       1       8       33        1      active sync   /dev/sdc1
       3       8        1        2      active sync   /dev/sda1
       4       8       17        3      active sync   /dev/sdb1
       5       8       80        4      active sync   /dev/sdf

       6       8      113        -      spare   /dev/sdh1

И структура диска это

NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                          8:0    0   3,7T  0 disk
└─sda1                       8:1    0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdb                          8:16   0   3,7T  0 disk
└─sdb1                       8:17   0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdc                          8:32   0   3,7T  0 disk
└─sdc1                       8:33   0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdd                          8:48   0   3,7T  0 disk
└─sdd1                       8:49   0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdf                          8:80   1   3,7T  0 disk
└─md0                        9:0    0  14,6T  0 raid5
  └─storageRaid            253:4    0  14,6T  0 crypt
    └─vg_raid-raidVolume   253:5    0  14,6T  0 lvm   /media/raidVolume
sdh                          8:112  1   3,7T  0 disk
└─sdh1                       8:113  1   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume

Я немного запутался, что запасной диск (sdh) уже находится в томе склепа.

Вопросы:
По каким критериям mdadm скажет, что диск неисправен?
Могут ли случайные ошибки чтения возникнуть с одного сломанного диска?
Не обнаружить рейд, когда диск отправляет неправильные данные?
Опасно ли помечать диск вручную как сбойный, если запасной диск имеет не тот же размер?

Источник

2 ответа

Решение

По моему мнению, MD raid слишком консервативен с выбиванием дисков. Я всегда наблюдаю за исключениями ATA в syslog/dmesg (я устанавливаю rsyslog, чтобы уведомлять меня об этом).

Должен сказать, я удивлен, что вы получаете ошибки на уровне приложения. RAID5 должен использовать информацию о четности для обнаружения ошибок (по-видимому, редактировать ее нет; только во время проверки). Сказав это, является ли диск причиной или нет, это плохо. Почти 2000 перераспределенных секторов действительно плохо.

Разделы могут быть больше, в противном случае вы также не можете добавить их как запасные, но чтобы убедиться, что все в порядке, вы можете клонировать таблицы разделов, используя fdisk, sfdisk и gdisk. У вас есть GPT, поэтому давайте использовать его функцию резервного копирования. Если вы делаете gdisk /dev/sdX, ты можешь использовать b создать резервную копию таблицы разделов на диске. Затем на новом диске gdisk /dev/sdY, ты можешь использовать r для вариантов восстановления, то l загрузить резервную копию. Тогда у вас должен быть идентичный раздел и все mdadm --manage --add Команды должны работать. (вам нужно будет вынуть новый диск из массива перед изменением таблицы разделов)

Я на самом деле склонен хранить эти резервные таблицы разделов на серверах. Это делает для быстрой замены диска.

И последний совет: не используйте RAID5. RAID5 с такими огромными дисками облупился. Вы должны иметь возможность добавить диск и динамически перейти на RAID6. Не уверен, как из головы, но вы можете Google, что.

Источник

Довольно распространено иметь задачу cron, инициирующую проверки несоответствия четности. Я уверен, что Debian 9 делает это по умолчанию, когда устанавливается пакет mdadm, и, следовательно, в журналах вашей системы будут отчеты по этому вопросу.

Кроме того, если ОЗУ вашей системы выходит из строя, это может быть основной причиной

Источник
Другие вопросы по тегам