Tl; dr: jak miałbym zająć się naprawieniem złego bloku na 1 dysku w macierzy RAID1?
Ale proszę przeczytaj całą tę rzecz, aby dowiedzieć się, co już próbowałem i możliwych błędów w moich metodach. Starałem się być jak najbardziej szczegółowy i naprawdę liczę na opinie
Oto moja sytuacja: mam dwa dyski 2 TB (ten sam model) ustawione w zarządzanej macierzy RAID1 mdadm
. Około 6 miesięcy temu zauważyłem pierwszy zły blok, gdy SMART to zgłosił. Dzisiaj zauważyłem więcej i teraz próbuję to naprawić.
Ta strona HOWTO wydaje się być jedynym artykułem, do którego prowadzą linki, aby naprawić złe bloki raportowane przez SMART. To świetna strona, pełna informacji, jednak jest dość przestarzała i nie dotyczy mojej konkretnej konfiguracji. Oto jak różni się moja konfiguracja:
- Zamiast jednego dysku używam dwóch dysków w macierzy RAID1. Jeden dysk zgłasza błędy, a drugi jest w porządku. HOWTO jest napisany z myślą tylko o jednym dysku, co rodzi różne pytania, takie jak „czy używam tego polecenia na urządzeniu dyskowym czy urządzeniu RAID”?
- Używam GPT, którego fdisk nie obsługuje. Zamiast tego używam gdisk i mam nadzieję, że daje mi te same informacje, których potrzebuję
Przejdźmy do tego. Tak właśnie zrobiłem, jednak wydaje się, że nie działa. Prosimy o dokładne sprawdzenie moich obliczeń i metody pod kątem błędów. Błędy raportowania dysku to / dev / sda:
# smartctl -l selftest /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.4.4-2-ARCH] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 12169 3212761936
Dzięki temu możemy wywnioskować, że błąd dotyczy LBA 3212761936. Zgodnie z HOWTO używam gdisk, aby znaleźć sektor początkowy, który będzie później używany przy określaniu numeru bloku (ponieważ nie mogę użyć fdisk, ponieważ nie obsługuje GPT):
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): CFB87C67-1993-4517-8301-76E16BBEA901
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 3907029134 1.8 TiB FD00 Linux RAID
Za pomocą tunefs
znajduję rozmiar bloku 4096
. Korzystając z tych informacji i obliczeń z HOWTO, dochodzę do wniosku, że omawiany blok jest ((3212761936 - 2048) * 512) / 4096 = 401594986
.
HOWTO następnie każe mi debugfs
sprawdzić, czy blok jest w użyciu (używam urządzenia RAID, ponieważ wymaga ono systemu plików EXT, było to jedno z poleceń, które mnie pomyliły, ponieważ początkowo nie wiedziałem, czy powinienem użyć / dev / sda lub / dev / md0):
# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs: open /dev/md0
debugfs: testb 401594986
Block 401594986 not in use
Zatem blok 401594986 jest pustą przestrzenią, powinienem móc nad nim pisać bez problemów. Przed napisaniem do niego staram się jednak upewnić, że nie można go odczytać:
# dd if=/dev/sda1 of=/dev/null bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000198887 s, 20.6 MB/s
Gdyby blok nie mógł zostać odczytany, nie spodziewałbym się, że to zadziała. Jednak tak jest. Powtarzam za pomocą /dev/sda
, /dev/sda1
, /dev/sdb
, /dev/sdb1
, /dev/md0
, i + -5 do numeru bloku szukać wokół zły blok. To wszystko działa. Wzruszam ramionami i kontynuuję zapis i synchronizację (używam / dev / md0, ponieważ pomyślałem, że modyfikowanie jednego dysku, a nie drugiego, może powodować problemy, w ten sposób oba dyski zastępują zły blok):
# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000142366 s, 28.8 MB/s
# sync
Spodziewałbym się, że zapis w złym bloku spowoduje, że dyski ponownie przypiszą blok do dobrego, jednak uruchomienie kolejnego testu SMART pokazuje inaczej:
# 1 Short offline Completed: read failure 90% 12170 3212761936
Wróć do kwadratu 1. Więc w zasadzie, jak naprawić zły blok na 1 dysku w macierzy RAID1? Jestem pewien, że nie zrobiłem czegoś poprawnie ...
Dziękuję za poświęcony czas i cierpliwość.
EDYCJA 1:
Próbowałem przeprowadzić długi test SMART, przy czym ten sam LBA powraca jako zły (jedyna różnica polega na tym, że pozostało 30% zamiast 90%):
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 30% 12180 3212761936
# 2 Short offline Completed: read failure 90% 12170 3212761936
Użyłem również badblocks z następującymi danymi wyjściowymi. Dane wyjściowe są dziwne i wydają się być źle sformatowane, ale próbowałem przetestować liczby wyprowadzane jako bloki, ale debugowanie powoduje błąd
# badblocks -sv /dev/sda
Checking blocks 0 to 1953514583
Checking for bad blocks (read-only test): 1606380968ne, 3:57:08 elapsed. (0/0/0 errors)
1606380969ne, 3:57:39 elapsed. (1/0/0 errors)
1606380970ne, 3:58:11 elapsed. (2/0/0 errors)
1606380971ne, 3:58:43 elapsed. (3/0/0 errors)
done
Pass completed, 4 bad blocks found. (4/0/0 errors)
# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs: open /dev/md0
debugfs: testb 1606380968
Illegal block number passed to ext2fs_test_block_bitmap #1606380968 for block bitmap for /dev/md0
Block 1606380968 not in use
Nie jestem pewien, dokąd się udać. badblocks
zdecydowanie coś znalazłem, ale nie jestem pewien, co zrobić z prezentowanymi informacjami ...
EDYCJA 2
Więcej poleceń i informacji.
Czuję się jak idiota, który oryginalnie zapomniał o tym. To są wartości SMART dla /dev/sda
. Mam 1 Current_Pending_Sector i 0 Offline_Uncorrectable.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 166
2 Throughput_Performance 0x0026 055 055 000 Old_age Always - 18345
3 Spin_Up_Time 0x0023 084 068 025 Pre-fail Always - 5078
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 75
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 12224
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 75
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 1646911
191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 12
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
194 Temperature_Celsius 0x0002 064 059 000 Old_age Always - 36 (Min/Max 22/41)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 1
198 Offline_Uncorrectable 0x0030 252 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 30
223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 77
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Thu May 5 06:30:21 2011
Raid Level : raid1
Array Size : 1953512383 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953512383 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue Jul 3 22:15:51 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : server:0 (local to host server)
UUID : e7ebaefd:e05c9d6e:3b558391:9b131afb
Events : 67889
Number Major Minor RaidDevice State
2 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
Zgodnie z jedną z odpowiedzi: wydaje się, że zmieniłem seek
i skip
na dd
. Korzystałem z wyszukiwania, ponieważ jest to używane w HOWTO. Użycie tego polecenia powoduje dd
zawieszenie: # dd if = / dev / sda1 of = / dev / null bs = 4096 count = 1 skip = 401594986
Korzystanie z bloków wokół tego (..84, ..85, ..87, ..88) wydaje się działać dobrze, a używanie / dev / sdb1 z blokami 401594986
również dobrze się sprawdza (zgodnie z oczekiwaniami, gdy dysk przeszedł testy SMART ). Teraz mam pytanie: czy pisząc po tym obszarze, aby ponownie przypisać bloki, czy używam /dev/sda1
lub /dev/md0
? Nie chcę powodować żadnych problemów z macierzą RAID, pisząc bezpośrednio na jednym dysku i nie mając aktualizacji drugiego dysku.
EDYCJA 3
Zapis do bloku spowodował bezpośrednio błędy systemu plików. Wybrałem odpowiedź, która szybko rozwiązała problem:
# 1 Short offline Completed without error 00% 14211 -
# 2 Extended offline Completed: read failure 30% 12244 3212761936
Dziękujemy wszystkim, którzy pomogli. =)
/sbin/badblocks -sv /dev/sda
sprawdzić dysk.
sudo mdadm -D /dev/md0
smartctl -t long /dev/sda
i sprawdzić, czy zmieni się LBA pierwszego błędu.