ATA가 응답을 중지하면 md RAID의 장치에 오류가 발생합니다.

ATA가 응답을 중지하면 md RAID의 장치에 오류가 발생합니다.

나는 창조했다1TB HDD 파티션 5개( /dev/sda1, /dev/sdb1, /dev/sdc1, /dev/sde1, 및 /dev/sdf1)RAID 6Ubuntu 14.04 LTS Trusty Tahr에서 /dev/md0사용되는 배열입니다 .mdadm

mdadm --detail /dev/md0모든 드라이브를 표시하는 데 사용되는 sudo 명령활성 동기화.

그런 다음 테스트를 위해 어레이에서 활성 상태인 /dev/sdb동안 다음 명령을 실행하여 긴 I/O 차단을 시뮬레이션했습니다 ./dev/sdb1

hdparm --user-master u --security-set-pass deltik /dev/sdb
hdparm --user-master u --security-erase-enhanced deltik /dev/sdb

경고

관심 있는 데이터에 대해 이 작업을 시도하지 마세요!
이 ATA 작업의 결과로 455681개의 inode가 손상되었습니다. 나는 나의 과실을 인정합니다.

보안 삭제를 위한 ATA 명령은 188분 동안 실행되어 최소한 그 시간 동안 다른 모든 명령을 차단할 것으로 예상되었습니다.

적절한 RAID 컨트롤러처럼 응답하지 않는 드라이브를 삭제할 것으로 예상했지만 md놀랍게도 /dev/md0차단도 되었습니다.

mdadm --detail /dev/md0차단된 장치를 쿼리하여 정지되어 출력되지 않습니다.

/proc/mdstat사용할 수 없는 동안 의 레이아웃은 다음과 같습니다 mdadm --detail /dev/md0.

root@node51 [~]# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md0 : active raid6 sdf1[5] sda1[0] sdb1[4] sdc1[2] sde1[1]
      2929887744 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]

unused devices: <none>

mdadm /dev/md0 -f /dev/sdb1강제로 실패하려고 시도했지만 /dev/sdb1차단되었습니다.

root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}' 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3334  1.2  0.0  42564  1800 ?        D    03:21   3:37 parted -l
root      4957  0.0  0.0  13272   900 ?        D    06:19   0:00 mdadm /dev/md0 -f /dev/sdb1
root      5706  0.0  0.0  13388  1028 ?        D    06:19   0:00 mdadm --detail /dev/md0
root      7541  0.5  0.0      0     0 ?        D    Jul19   6:12 [kworker/u16:2]
root     22420  0.0  0.0  11480   808 ?        D    07:48   0:00 lsblk
root     22796  0.0  0.0   4424   360 pts/13   D+   05:51   0:00 hdparm --user-master u --security-erase-enhanced deltik /dev/sdb
root     23312  0.0  0.0   4292   360 ?        D    05:51   0:00 hdparm -I /dev/sdb
root     23594  0.1  0.0      0     0 ?        D    06:11   0:07 [kworker/u16:1]
root     25205  0.0  0.0  17980   556 ?        D    05:52   0:00 ls --color=auto
root     26008  0.0  0.0  13388  1032 pts/23   D+   06:32   0:00 mdadm --detail /dev/md0
dtkms    29271  0.0  0.2  58336 10412 ?        DN   05:55   0:00 python /usr/share/backintime/common/backintime.py --backup-job
root     32303  0.0  0.0      0     0 ?        D    06:16   0:00 [kworker/u16:0]

업데이트(2015년 7월 21일):mdI/O 블록이 지워질 때까지 188분을 기다린 후, 완전히 비어 있는 블록을 /dev/sdb완전히 그대로 있는 것처럼 처리하는 것을 보고 놀라움은 공포로 바뀌었습니다 .

나는 md적어도 패리티가 일치하지 않는다는 것을 알았을 것이고 그 다음에는 떨어졌을 것이라고 생각했습니다 /dev/sdb1.

당황해서 다시 달렸 mdadm /dev/md0 -f /dev/sdb1는데 I/O 블록이 해제되었기 때문에 명령이 빠르게 완료되었습니다.

입출력 오류가 발생하면서 파일 시스템 손상이 이미 발생하고 있었습니다. 여전히 당황한 상태에서 RAID 배열의 데이터 파티션을 천천히 마운트 해제했고 상황 reboot -nf이 더 이상 악화될 수 없다고 생각했습니다.

파티션에서 손톱을 물어뜯은 후 e2fsck455681개의 inode가 lost+found.

그 후 배열을 다시 조립했는데 이제 배열 자체가 괜찮아 보입니다.

root@node51 [~]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Mon Feb 16 14:34:26 2015
     Raid Level : raid6
     Array Size : 2929887744 (2794.16 GiB 3000.21 GB)
  Used Dev Size : 976629248 (931.39 GiB 1000.07 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Tue Jul 21 00:00:30 2015
          State : active 
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : box51:0
           UUID : 6b8a654d:59deede9:c66bd472:0ceffc61
         Events : 643541

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       97        1      active sync   /dev/sdg1
       2       8       33        2      active sync   /dev/sdc1
       6       8       17        3      active sync   /dev/sdb1
       5       8      113        4      active sync   /dev/sdh1

md제가 기대했던 두 가지 보호 수단이 없다는 사실은 여전히 ​​제게는 꽤 충격적입니다 .

  • 장치가 잠겼을 때 장치 실패
  • 반환된 데이터가 가비지일 때 장치에 오류가 발생함

질문

  1. md응답하지 않는 드라이브/파티션이 실패 하지 않는 이유는 무엇입니까 ?
  2. 드라이브가 차단된 동안 어레이에서 드라이브/파티션을 삭제할 수 있습니까?
  3. mdATA 명령에 응답하지 않는 드라이브에 자동으로 오류가 발생 하도록 시간 초과를 구성할 수 있습니까 ?
  4. md데이터가 잘못된 기기를 계속 사용하는 이유는 무엇인가요 ?

답변1

델틱, 당신은 Linux 소프트웨어 RAID( md)가 어떻게 작동하는지 오해했습니다.

md여러 장치나 파티션으로 가상 블록 장치를 만들고 가상 장치에서 어떤 데이터를 전송하고 있는지 인식하지 못합니다.
당신은 그것이 하도록 설계되지 않은 일을 할 수 있기를 바랐습니다.


답변

1. md응답하지 않는 드라이브/파티션이 실패하지 않는 이유는 무엇입니까?

그 이유 md

  • 드라이브가 md자체적으로 요청한 I/O로 인해 사용 중이거나
  • 드라이브 자체 오류 복구 또는 귀하의 경우 ATA Secure Erase와 같은 일부 외부 상황으로 인해 드라이브가 차단되었습니다.

그래서 md드라이브가 무엇을 반환하는지 기다릴 것입니다. 드라이브는 결국 읽기 또는 쓰기 오류를 반환하지 않았습니다. 읽기 오류가 있으면 md패리티에서 자동으로 수정하고, 쓰기 오류가 있으면 md장치에 오류가 발생합니다(설명서의 "복구" 섹션 참조).md매뉴얼 페이지).

읽기 오류나 쓰기 오류가 없었으므로 md커널이 응답을 기다린 후 장치를 계속 사용했습니다.

2. 드라이브가 차단된 동안 어레이에서 드라이브/파티션을 삭제할 수 있습니까?

아니요. /dev/md0RAID 장치는 차단되어 있으며 블록이 지워질 때까지 수정할 수 없습니다.

-f또는 --fail플래그를 "관리" 모드에 전달했습니다 mdadm.
실제로 수행되는 작업에 대한 연습은 다음과 같습니다.

이것은 해당 플래그가 작동하는 방식에 대한 소스 코드입니다.:

case 'f': /* set faulty */
    /* FIXME check current member */
    if ((sysfd >= 0 && write(sysfd, "faulty", 6) != 6) ||
        (sysfd < 0 && ioctl(fd, SET_DISK_FAULTY,
                rdev))) {
        if (errno == EBUSY)
            busy = 1;
        pr_err("set device faulty failed for %s:  %s\n",
            dv->devname, strerror(errno));
        if (sysfd >= 0)
            close(sysfd);
        goto abort;
    }
    if (sysfd >= 0)
        close(sysfd);
    sysfd = -1;
    count++;
    if (verbose >= 0)
        pr_err("set %s faulty in %s\n",
            dv->devname, devname);
    break;

호출을 확인합니다 write(sysfd, "faulty", 6). sysfd파일의 앞부분에 설정된 변수입니다.
sysfd = sysfs_open(fd2devnm(fd), dname, "block/dev");

sysfs_open()의 함수입니다이 파일:

int sysfs_open(char *devnm, char *devname, char *attr)
{
    char fname[50];
    int fd;

    sprintf(fname, "/sys/block/%s/md/", devnm);
    if (devname) {
        strcat(fname, devname);
        strcat(fname, "/");
    }
    strcat(fname, attr);
    fd = open(fname, O_RDWR);
    if (fd < 0 && errno == EACCES)
        fd = open(fname, O_RDONLY);
    return fd;
}

함수를 따라가면 mdadm /dev/md0 -f /dev/sdb1기본적으로 다음과 같은 작업을 수행한다는 것을 알 수 있습니다.

echo "faulty" > /sys/block/md0/md/dev-sdb1/block/dev

이 요청은 대기 중이며 차단되었으므로 즉시 처리되지 않습니다 /dev/md0.

md3. ATA 명령에 응답하지 않는 드라이브가 자동으로 실패 하도록 시간 초과를 구성할 수 있습니까 ?

예. 사실은,기본적으로 제한 시간은 30초입니다.:

root@node51 [~]# cat /sys/block/sdb/device/timeout
30

가정의 문제는 드라이브가 실제로 ATA 명령을 실행 중이어서(188분 동안) 시간 초과가 발생하지 않았다는 것입니다.

이에 대한 자세한 내용은 다음을 참조하세요.Linux 커널 SCSI 오류 처리 문서.

4. md데이터가 유효하지 않은 기기를 계속 사용하는 이유는 무엇입니까?

ATA Secure Erase가 완료되었을 때 드라이브는 명령 중단과 같은 문제를 보고하지 않았으므로 md문제가 있다고 의심할 이유가 없었습니다.

또한 전체 디스크 대신 파티션을 RAID 장치로 사용하는 경우 커널의 메모리 내 파티션 테이블은 지워진 드라이브의 파티션이 사라졌다는 사실을 알리지 않았으므로 아무 문제가 없는 것처럼 md계속 액세스하게 됩니다 ./dev/sdb1

이것은md매뉴얼 페이지:

스크러빙 및 불일치

저장 장치는 언제든지 불량 블록을 개발할 수 있으므로 이러한 불량 블록을 조기에 발견할 수 있도록 어레이에 있는 모든 장치의 모든 블록을 정기적으로 읽는 것이 중요합니다. 이 과정을닦고.

md 배열은 다음 중 하나를 작성하여 스크러빙할 수 있습니다.확인하다또는수리하다파일에md/sync_action에서sysfs장치의 디렉터리입니다.

스크럽을 요청하면 md가 어레이에 있는 모든 장치의 모든 블록을 읽고 데이터가 일관성이 있는지 확인하게 됩니다. RAID1 및 RAID10의 경우 이는 복사본이 동일한지 확인하는 것을 의미합니다. RAID4, RAID5, RAID6의 경우 이는 패리티 블록이 올바른지 확인하는 것을 의미합니다.

이를 통해 일반적으로 모든 디스크 읽기에서 패리티가 검사되지 않는다는 것을 추론할 수 있습니다. (게다가 모든 읽기에서 패리티를 확인하는 것은 단지 읽기를 완료하는 데 필요한 트랜잭션을 늘리고 읽은 데이터에 대한 패리티 비교를 실행하므로 성능에 큰 부담이 됩니다.)

정상적인 작동에서는 md읽고 있는 데이터가 유효하다고 가정하므로 다음과 같은 공격에 취약합니다.조용한 데이터 손상. 귀하의 경우 드라이브를 삭제했기 때문에 드라이브 전체가 조용히 손상된 데이터를 갖게 되었습니다.

파일 시스템이 손상을 인식하지 못했습니다. 파일 시스템이 잘못된 데이터가 있는 이유를 이해할 수 없기 때문에 파일 시스템 수준에서 입출력 오류가 발생했습니다.

자동 데이터 손상을 방지하려면 먼저,다시는 당신이 했던 일을 하지 마세요. 둘째, 사용을 고려하십시오.ZFS, 데이터 무결성에 중점을 두고 자동 데이터 손상을 감지하고 수정하는 파일 시스템입니다.

관련 정보