Linux - การซ่อมแซมบล็อกเสียบนอาเรย์ RAID1 ด้วย GPT

The tl; dr: ฉันจะแก้ไขการบล็อกที่ไม่ดีบนดิสก์ 1 ตัวในอาร์เรย์ RAID1 ได้อย่างไร

แต่โปรดอ่านทั้งหมดนี้สำหรับสิ่งที่ฉันได้ลองไปแล้วและข้อผิดพลาดที่เป็นไปได้ในวิธีการของฉัน ฉันพยายามที่จะให้รายละเอียดมากที่สุดเท่าที่จะเป็นไปได้และฉันหวังว่าจะได้รับคำติชม

นี่คือสถานการณ์ของฉัน: ฉันมีสองแผ่น 2TB (รุ่นเดียวกัน) จัดตั้งขึ้นในอาร์เรย์ RAID1 mdadmจัดการโดย ประมาณ 6 เดือนที่ผ่านมาฉันสังเกตเห็นบล็อกที่ไม่ดีครั้งแรกเมื่อสมาร์ทรายงาน วันนี้ฉันสังเกตเห็นมากขึ้นและตอนนี้ฉันพยายามที่จะแก้ไข

หน้า HOWTO นี้ดูเหมือนจะเป็นบทความเดียวที่ทุกคนเชื่อมโยงเพื่อแก้ไขบล็อกเสียที่ SMART กำลังรายงาน มันเป็นหน้าที่ยอดเยี่ยมเต็มไปด้วยข้อมูลอย่างไรก็ตามมันค่อนข้างล้าสมัยและไม่ได้ระบุการตั้งค่าเฉพาะของฉัน นี่คือความแตกต่างของการกำหนดค่าของฉัน:

• แทนที่จะเป็นหนึ่งดิสก์ฉันใช้ดิสก์สองตัวในอาร์เรย์ RAID1 หนึ่งดิสก์กำลังรายงานข้อผิดพลาดในขณะที่อีกแผ่นนั้นใช้ได้ HOWTO เขียนด้วยดิสก์เดียวในใจซึ่งถามคำถามต่าง ๆ เช่น 'ฉันจะใช้คำสั่งนี้กับอุปกรณ์ดิสก์หรืออุปกรณ์ RAID' หรือไม่
• ฉันใช้ GPT ซึ่ง fdisk ไม่รองรับ ฉันใช้ gdisk แทนและฉันหวังว่ามันจะให้ข้อมูลแบบเดียวกับที่ฉันต้องการ

ดังนั้นขอลงไป นี่คือสิ่งที่ฉันได้ทำไปแล้ว แต่ดูเหมือนว่ามันจะไม่ทำงาน โปรดตรวจสอบการคำนวณและวิธีข้อผิดพลาดของฉันอีกครั้ง ข้อผิดพลาดในการรายงานดิสก์คือ / 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

ด้วยสิ่งนี้เรารวบรวมว่าข้อผิดพลาดอยู่ใน LBA 3212761936 หลังจาก HOWTO ฉันใช้ gdisk เพื่อค้นหาเซกเตอร์เริ่มต้นที่จะใช้ในภายหลังในการกำหนดหมายเลขบล็อก (เนื่องจากฉันไม่สามารถใช้ fdisk ได้เนื่องจากไม่รองรับ 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

ใช้ฉันพบบล็อคที่จะtunefs 4096การใช้ข้อมูลนี้และ calculuation จาก HOWTO ((3212761936 - 2048) * 512) / 4096 = 401594986ที่ผมสรุปได้ว่ากระชากคำถามคือ

HOWTO นั้นสั่งให้ฉันdebugfsดูว่าบล็อกนั้นมีการใช้งานหรือไม่ (ฉันใช้อุปกรณ์ RAID เพราะมันต้องการระบบไฟล์ EXT นี่เป็นหนึ่งในคำสั่งที่ทำให้ฉันสับสนเพราะฉันไม่ได้รู้ว่าตอนแรกฉันควรใช้ / dev / sda หรือ / dev / md0):

# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs:  open /dev/md0
debugfs:  testb 401594986
Block 401594986 not in use

ดังนั้นบล็อก 401594986 คือพื้นที่ว่างฉันควรเขียนทับได้โดยไม่มีปัญหา ก่อนที่จะเขียนถึงมันฉันพยายามที่จะทำให้แน่ใจว่ามันไม่สามารถอ่านได้:

# 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

หากไม่สามารถอ่านบล็อกฉันจะไม่คาดหวังว่ามันจะทำงาน อย่างไรก็ตามมันทำ ฉันทำซ้ำโดยใช้/dev/sda, /dev/sda1, /dev/sdb, /dev/sdb1, /dev/md0และ + -5 ถึงจำนวนบล็อกค้นหารอบบล็อกเสีย มันทำงานได้ทั้งหมด ฉันยักไหล่และไปข้างหน้าและเขียนและซิงค์ (ฉันใช้ / dev / md0 เพราะฉันคิดว่าการแก้ไขดิสก์หนึ่ง แต่ไม่ใช่ดิสก์อื่นที่อาจทำให้เกิดปัญหาวิธีนี้ดิสก์ทั้งสองเขียนทับบล็อกที่ไม่ดี):

# 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 

ฉันคาดหวังว่าการเขียนไปยังบล็อกที่ไม่ดีจะมีดิสก์กำหนดบล็อกใหม่ให้เป็นบล็อกที่ดีอย่างไรก็ตามการรันการทดสอบ SMART อีกรายการจะแสดงต่างกัน:

# 1  Short offline       Completed: read failure       90%     12170         3212761936

กลับไปที่ตาราง 1 ดังนั้นโดยพื้นฐานแล้วฉันจะแก้ไขบล็อกที่ไม่ดีบนดิสก์ 1 ตัวในอาร์เรย์ RAID1 ได้อย่างไร ฉันแน่ใจว่าฉันทำบางสิ่งไม่ถูกต้อง ...

ขอบคุณสำหรับเวลาและความอดทนของคุณ

แก้ไข 1:

ฉันพยายามทำการทดสอบ SMART ที่ยาวนานโดย LBA ตัวเดียวกันนั้นกลับมาแย่ (ความแตกต่างเพียงอย่างเดียวคือรายงานเหลือ 30% มากกว่า 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

ฉันยังใช้ badblocks ด้วยผลลัพธ์ต่อไปนี้ ผลลัพธ์แปลกและดูเหมือนว่าจะพลาดรูปแบบ แต่ฉันพยายามทดสอบตัวเลขที่ส่งออกเป็นบล็อก แต่ debugfs ให้ข้อผิดพลาด

# 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

ไม่แน่ใจว่าจะไปจากที่นี่ badblocksพบสิ่งที่แน่นอน แต่ฉันไม่แน่ใจว่าจะทำอย่างไรกับข้อมูลที่นำเสนอ ...

แก้ไข 2

คำสั่งและข้อมูลเพิ่มเติม

ฉันรู้สึกเหมือนคนโง่ที่ลืมที่จะรวมสิ่งนี้ไว้ในตอนแรก /dev/sdaนี่คือค่าสมาร์ท ฉันมี 1 ปัจจุบัน_Pending_Sectorและ 0 ออฟไลน์ _ แก้ไขได้

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

เป็นต่อหนึ่งในคำตอบ: มันจะดูเหมือนผมทำสวิทช์seekและสำหรับskip ddฉันใช้การค้นหาตามที่ใช้กับ HOWTO การใช้คำสั่งนี้ทำให้หยุดทำงานdd: # dd if = / dev / sda1 ของ = / dev / null bs = 4096 count = 1 skip = 401594986

การใช้บล็อกรอบ ๆ อันนั้น (..84, ..85, ..87, ..88) ดูเหมือนว่าจะใช้ได้ดีและการใช้ / dev / sdb1 กับการ401594986อ่านบล็อกก็ใช้ได้เช่นกัน (อย่างที่คาดไว้เมื่อดิสก์นั้นผ่านการทดสอบ SMART ) ตอนนี้คำถามที่ฉันมีคือ: เมื่อเขียนบนพื้นที่นี้เพื่อมอบหมายบล็อกฉันจะใช้/dev/sda1หรือ/dev/md0ไม่ ฉันไม่ต้องการที่จะทำให้เกิดปัญหาใด ๆ กับอาร์เรย์ RAID โดยการเขียนโดยตรงไปยังดิสก์หนึ่งและไม่ได้มีการปรับปรุงดิสก์อื่น ๆ

แก้ไข 3

การเขียนไปยังบล็อกสร้างข้อผิดพลาดของระบบไฟล์โดยตรง ฉันเลือกคำตอบที่แก้ไขปัญหาได้อย่างรวดเร็ว:

# 1  Short offline       Completed without error       00%     14211         -
# 2  Extended offline    Completed: read failure       30%     12244         3212761936

ขอบคุณทุกคนที่ช่วย =)

คำตอบ "กระตุ้นภาค" ทั้งหมดเหล่านี้ค่อนข้างตรงไปตรงมาบ้า พวกเขาเสี่ยงต่อความเสียหายของระบบไฟล์ หากข้อมูลหายไปแล้วเนื่องจากดิสก์นั้นเก็บสำเนาไว้เพียงอย่างเดียวนั่นก็สมเหตุสมผล แต่มีสำเนาที่ดีอย่างสมบูรณ์บนกระจก

คุณแค่ต้องขัดกระจก มันจะสังเกตเห็นเซกเตอร์ที่ไม่ดีและเขียนใหม่โดยอัตโนมัติ

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

คุณต้องใส่อุปกรณ์ที่เหมาะสมในนั้น (เช่น md0 แทน mdX) การดำเนินการนี้จะใช้เวลาสักครู่เนื่องจากจะทำให้อาร์เรย์ทั้งหมดเป็นค่าเริ่มต้น บนเคอร์เนลใหม่ที่เพียงพอคุณสามารถเขียนหมายเลขเซกเตอร์ไปยัง sync_min / sync_max ก่อนเพื่อ จำกัด ให้เหลือเพียงส่วนหนึ่งของอาร์เรย์

นี่เป็นการดำเนินการที่ปลอดภัย คุณสามารถทำได้บนอุปกรณ์ mdraid ทั้งหมดของคุณ ในความเป็นจริงคุณควรทำกับอุปกรณ์ md กลัวของคุณเป็นประจำ distro ของคุณมีโอกาสจัดส่งพร้อม cronjob เพื่อจัดการกับสิ่งนี้คุณอาจต้องทำอะไรบางอย่างเพื่อเปิดใช้

สคริปต์สำหรับอุปกรณ์ RAID ทั้งหมดในระบบ

เมื่อไม่นานมานี้ฉันได้เขียนสคริปต์นี้เพื่อ "ซ่อมแซม" อุปกรณ์ RAID ทั้งหมดในระบบ สิ่งนี้ถูกเขียนขึ้นสำหรับเคอร์เนลเวอร์ชันเก่าที่ 'ซ่อมแซม' เท่านั้นที่จะแก้ไขเซกเตอร์เสีย ตอนนี้แค่ตรวจสอบก็เพียงพอแล้ว (การซ่อมยังใช้งานได้ดีกับเมล็ดข้าวรุ่นใหม่ แต่ก็ยังคัดลอก / สร้างความเท่าเทียมกันใหม่ซึ่งไม่ใช่สิ่งที่คุณต้องการเสมอโดยเฉพาะในแฟลชไดรฟ์)

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

หากคุณต้องการทำcheckแทนrepairบล็อกแรก (ยังไม่ทดลอง) นี้ควรใช้งานได้:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

ฉันเพิ่งมีปัญหาเดียวกันมากกับอาร์เรย์ RAID1 เซกเตอร์เสียนั้นอยู่ที่จุดเริ่มต้นของหนึ่งในพาร์ติชัน - ส่วนที่ 16 ของ / dev / sdb2 ฉันทำตามคำแนะนำด้านบน: หลังจากตรวจสอบว่าลอจิคัลบล็อก 2 ไม่ได้ถูกใช้งานโดยระบบไฟล์และระวังที่จะรับ dd ค้นหาและข้ามวิธีที่ถูกต้องและ zeroed out 1 บล็อกระบบไฟล์:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

สิ่งนี้ทำอะไร มันไม่ได้แก้ไขเซกเตอร์เสีย ตอนนี้ฉันรู้แล้วว่าเป็นเพราะ / dev / md0 ไม่ได้จับคู่โดยตรงกับ / dev / sdb2 คุณต้องคำนึงถึง RAID DATA OFFSET! เพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง สิ่งที่มันทำคือเล็ก ๆ น้อย ๆ แต่อาจทำลายล้างระบบไฟล์ของฉัน ปรากฎว่าบล็อกลอจิคัลที่ 2 ของ / dev / md0 มีเมตาดาต้าระบบไฟล์ที่มีประโยชน์และใช้ได้กับดิสก์ทั้งสองจนกว่าฉันจะอ่านทั้งสองสำเนาโดยเขียนถึง / dev / md0 โชคดีที่ e2fsck -y / dev / md0 แก้ไขปัญหา (หลังจากพ่นเอาต์พุตที่น่าตกใจ) โดยไม่มีการสูญหายของข้อมูล เรียนรู้บทเรียน: ถ้า debugfs icheck บอกว่า 'block not found' ไม่จำเป็นต้องหมายความว่าไม่ได้ใช้เซกเตอร์ที่เกี่ยวข้อง

กลับไปที่ข้อมูลออฟเซ็ต: ใช้ mdadm เพื่อค้นหาออฟเซ็ตดังนี้:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

ในกรณีนี้ข้อมูลออฟเซ็ตคือ 262144 เซ็กเตอร์ที่ 512 ไบต์ หากคุณ dd จาก / dev / md0 และเปรียบเทียบกับข้อมูลจากพาร์ทิชันดิบด้วย offset ของ 131072K คุณจะพบว่าพวกมันตรงกัน ดังนั้นในกรณีของฉันบล็อกเชิงตรรกะ 2 (ส่วนที่ 16 - 23) ของ / dev / sdb2 ไม่ได้อยู่ในระบบไฟล์ พวกมันอยู่ใน RAID superblock ซึ่งคุณสามารถอ่านได้ที่นี่: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats - สำหรับเวอร์ชั่น 1.2 ประกอบด้วย 256 ไบต์ + 2 ไบต์ต่ออุปกรณ์ในอาร์เรย์ ทั้งหมดเริ่มต้นที่ 4096 ไบต์ดังนั้นในกรณีของฉันไม่ได้ใช้เซกเตอร์เสีย ส่วนที่เกี่ยวข้องของ / dev / sdc2 (อีกครึ่งหนึ่งของอาร์เรย์ RAID1) เป็นศูนย์ดังนั้นฉันจึงคิดว่ามันปลอดภัยที่จะทำสิ่งนี้:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

มันได้ผล!

หากเรียกใช้เดเบียนคุณมักจะมีงานใน /etc/cron.d/mdadm การดำเนินการนี้จะ/usr/share/mdadm/checkarray --cron --all --idle --quiet เริ่มในวันอาทิตย์แรกของทุกเดือน เรียกใช้ด้วยตนเองเมื่อคุณได้รับข้อผิดพลาดฮาร์ดแวร์ไม่สามารถแก้ไขได้เพื่อเร่งการเขียนใหม่

คุณผสมddอาร์กิวเมนต์ ของคุณ seekทำให้มันพยายามที่จะชดเชยที่ระบุในการส่งออก คุณต้องการที่จะskipบล็อกในการป้อนข้อมูล

หากคุณมี sw-raid1 และคุณเขียนข้อมูลไปยังสมาชิกคนใดคนหนึ่งโดยตรงคุณจะมีการโจมตีที่เสียหายทันที อย่าเขียนข้อมูลไปยัง sdaX หรือ sdbX หากเป็นส่วนหนึ่งของ mdX หากคุณเขียนไปที่ mdX คุณจะมีข้อมูลที่คัดลอกไปยังไดรฟ์ทั้งสองถ้าคุณอ่านจาก mdX คุณจะได้รับข้อมูลที่อ่านจากหนึ่งในไดรฟ์ ..