ZFS가 디스크의 더프 섹터와 관련이없는 이유는 무엇입니까?


8

ZFS 풀에서 읽는 동안 I / O 오류가 발생하면 두 가지 상황이 발생한다는 인상을 받았습니다.

  1. 실패는 관련 장치의 READ 또는 CKSUM 통계에 기록되어 풀 레벨을 향해 위쪽으로 전파됩니다.
    • 중복 데이터는 요청 된 블록을 재구성하고, 요청 된 블록을 호출자에게 반환하고, 더프 드라이브가 여전히 작동하는 경우 블록을 다시 작성합니다. 또는
    • 읽기 오류를 정정하기 위해 중복 데이터를 사용할 수없는 경우 I / O 오류가 리턴됩니다.

미러 설정의 디스크 중 하나가 불량 섹터를 개발 한 것으로 보입니다. 그 자체만으로는 놀라지 않습니다. 그런 일이 일어나고, 이것이 바로 중복성을 갖는 이유입니다 (양방향 미러). 풀을 문지르거나 특정 디렉토리의 파일을 읽을 때마다 (아직 오류가있는 파일을 정확하게 결정하기 위해 귀찮게하지 않았습니다) 다음은 다양한 타임 스탬프와 함께 dmesg에 나타납니다.

Nov  1 09:54:26 yeono kernel: [302621.236549] ata6.00: exception Emask 0x0 SAct 0x9c10 SErr 0x0 action 0x0
Nov  1 09:54:26 yeono kernel: [302621.236557] ata6.00: irq_stat 0x40000008
Nov  1 09:54:26 yeono kernel: [302621.236566] ata6.00: failed command: READ FPDMA QUEUED
Nov  1 09:54:26 yeono kernel: [302621.236578] ata6.00: cmd 60/a8:78:18:5a:12/00:00:5c:01:00/40 tag 15 ncq 86016 in
Nov  1 09:54:26 yeono kernel: [302621.236580]          res 41/40:a8:18:5a:12/00:00:5c:01:00/00 Emask 0x409 (media error) <F>
Nov  1 09:54:26 yeono kernel: [302621.236585] ata6.00: status: { DRDY ERR }
Nov  1 09:54:26 yeono kernel: [302621.236589] ata6.00: error: { UNC }
Nov  1 09:54:26 yeono kernel: [302621.238214] ata6.00: configured for UDMA/133

이것은 꽤 최신의 데비안 Wheezy, 커널 3.2.0-4-amd64 # 1 SMP 데비안 3.2.63-2 x86_64, ZoL 0.6.3입니다. 패키지 버전은 debian-zfs = 7 ~ wheezy, libzfs2 = 0.6.3-1 ~ wheezy, zfs-dkms = 0.6.3-1 ~ wheezy, zfs-initramfs = 0.6.3-1 ~ wheezy, zfsutils = 0.6입니다. .3-1 ~ wheezy, zfsonlinux = 3 ~ wheezy, linux-image-amd64 = 3.2 + 46, linux-image-3.2.0-4-amd64 = 3.2.63-2. 내가 아는 유일한 패키지 고정은 ZoL을위한 것입니다 (zfsonlinux 패키지에서 제공).

Package: *
Pin: release o=archive.zfsonlinux.org
Pin-Priority: 1001

hdparm -R드라이브에서 실행 하면 Write-Read-Verify가 켜져 있다고보고합니다 (Seagate이므로 해당 기능이 있으며 추가 안전망으로 사용합니다. 대화 형 사용 패턴을 매우 읽기 때문에 추가 쓰기 대기 시간은 문제가되지 않습니다) -무거운):

/dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX:
 write-read-verify =  2

무언가 잘못되었다는 분명한 증거가 있더라도 zpool status수영장에 아무런 문제가 없다고 주장합니다.

  pool: akita
 state: ONLINE
  scan: scrub repaired 0 in 8h16m with 0 errors on Sat Nov  1 10:46:03 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        akita                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c50065e8414a  ONLINE       0     0     0
            wwn-0x5000c500645b0fec  ONLINE       0     0     0

errors: No known data errors

이 오류는 최근 며칠 동안 (10 월 27 일 이후) 정기적으로 로그에 표시되어 있으므로 단지 우연히 그저 쓸 줄 모르는 경향이 없습니다. 매우 짧은 SCTERC 시간 초과로 디스크를 실행합니다. 1.5 초 읽기 (읽기 오류에서 빠르게 복구하기 위해), 10 초 쓰기. 이 값이 해당 드라이브에서 활성화되어 있음을 확인했습니다.

smartd는 ATA 오류 수가 증가하고 있다는 사실에 대해 저를 계속 괴롭 히고 있습니다.

The following warning/error was logged by the smartd daemon:

Device: /dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX [SAT], ATA error count increased from 4 to 5

For details see host's SYSLOG.

smartctl --attributes해당 드라이브에서 실행 하면 다음이 생성됩니다.

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   076   063   044    Pre-fail  Always       -       48910012
  3 Spin_Up_Time            0x0003   091   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       97
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   030    Pre-fail  Always       -       1698336160
  9 Power_On_Hours          0x0032   089   089   000    Old_age   Always       -       9887
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       98
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   095   095   000    Old_age   Always       -       5
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       10
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   058   052   045    Old_age   Always       -       42 (Min/Max 20/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       61
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       492
194 Temperature_Celsius     0x0022   042   048   000    Old_age   Always       -       42 (0 11 0 0)
195 Hardware_ECC_Recovered  0x001a   052   008   000    Old_age   Always       -       48910012
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

아무것도 눈부시게 일반의 거기. 이 드라이브는 엔터프라이즈 드라이브이므로 5 년 보증 24x7 작동 등급 (지금까지는 벨트 아래 10,000 시간 미만에 비해 40,000 시간 이상 작동 할 수 있음)을 의미합니다. 187 Reported_Uncorrect 속성의 숫자 5를 확인하십시오. 그것이 문제가있는 곳입니다. 또한 각각 100 미만의 Start_Stop_Count 및 Power_Cycle_Count 값이 상당히 낮습니다.

이 경우에는 관련이 있다고 생각하지 않지만 시스템에는 ECC RAM이 있습니다.

풀 에서 루트 파일 시스템 의 비 기본 속성은 다음 과 같습니다.

NAME   PROPERTY              VALUE                  SOURCE
akita  type                  filesystem             -
akita  creation              Thu Sep 12 18:03 2013  -
akita  used                  3,14T                  -
akita  available             434G                   -
akita  referenced            136K                   -
akita  compressratio         1.04x                  -
akita  mounted               no                     -
akita  mountpoint            none                   local
akita  version               5                      -
akita  utf8only              off                    -
akita  normalization         none                   -
akita  casesensitivity       sensitive              -
akita  usedbysnapshots       0                      -
akita  usedbydataset         136K                   -
akita  usedbychildren        3,14T                  -
akita  usedbyrefreservation  0                      -
akita  sync                  standard               local
akita  refcompressratio      1.00x                  -
akita  written               0                      -
akita  logicalused           2,32T                  -
akita  logicalreferenced     15K                    -

풀 자체에 해당 합니다 .

NAME   PROPERTY               VALUE                  SOURCE
akita  size                   3,62T                  -
akita  capacity               62%                    -
akita  health                 ONLINE                 -
akita  dedupratio             1.00x                  -
akita  free                   1,36T                  -
akita  allocated              2,27T                  -
akita  readonly               off                    -
akita  ashift                 12                     local
akita  expandsize             0                      -
akita  feature@async_destroy  enabled                local
akita  feature@empty_bpobj    active                 local
akita  feature@lz4_compress   active                 local

이 목록은를 실행하여 얻었습니다 {zfs,zpool} get all akita | grep -v default.

이제 질문이 있습니다.

  1. ZFS 가 읽기 문제에 대해보고 하지 않는 이유는 무엇입니까? 분명히 회복되고 있습니다.

  2. 읽기 요청 경로에서 자동 복구를 위해 충분한 중복성이 존재하는 경우 ZFS가 드라이브에서 명확하게 읽기 문제가있는 더프 섹터를 자동으로 다시 쓰지 않는 이유는 무엇입니까?


난 몰라 영향을받는 파일을 누르지 않았을 수 있습니다. 또는이 시점에서 아무 파일도 영향을받지 않습니다.
ewwhite

동안 @ewwhite , 스크럽 시킨 실행 반복적으로 시스템 로그에 표시 오류를 유발? (파일 세트를 DVD로 구울 때도 오류가 나타났습니다. 원래이 파일을 살펴 보았습니다.) 풀에는 꽤 많은 스냅 샷이 있습니다.
CVn

왜 ZFS에서이 문제가 발생하는지 잘 모르겠 기 때문에 불쾌감을주었습니다. 이것이 버그인지 확인하는 것이 흥미로울 수 있습니다 ... 그러나 sysadmin의 관점에서 회전 디스크는 소모품입니다. 나는 DOA 디스크를 가지고 있으며 몇 주 안에 죽고 1 년 후에 죽습니다. 심각한 문제가 의심되면 드라이브를 교체하십시오.
ewwhite

1
권리. ZFS 그룹에도 게시 했습니까?
ewwhite

1
나는 당신에게 답이 없지만 FreeBSD에서 비슷한 행동을 보았습니다. 실패한 드라이브로 인해 성능이 저하되고 많은 오류가 콘솔에 인쇄되었지만 zpool 수준 오류 카운터를 증가시키지 못했습니다. 아직 설명을 찾지 못했지만 이것이 리눅스 고유의 현상이 아니라는 점을 고려할 가치가 있습니다.
Charley

답변:


1

오류가 파일 시스템 드라이버로 다시 전달되기 전에 오류가 발생하면 ATA 드라이버가 읽기 작업을 여러 번 다시 시도하는 것 같습니다.

이것이 의미하는 것은 ZFS 파일 시스템 드라이버가 데이터를 읽은 결과를 얻을 때까지는 정확하지만, 평소보다 조금 더 오래 걸렸을 가능성이 있습니다. 물론 평균 이상의 대기 시간에 대한 오류 카운터가 없으므로 기록 된 것이 없습니다.

Reported_Uncorrect의 SMART 값이 0이 아니라는 사실은 SATA 케이블 또는 SATA 컨트롤러의 결함과 달리 고장 원인이 디스크 자체라고 생각합니다.

이 경우, 블록 장치 드라이버가 많은 재시도 후에도 디스크가 결국 더 많이 죽고 읽기에 실패 할 가능성이 높습니다. 따라서 내 충고는 디스크를 교체하는 것입니다.

오류를 없애고 싶을 때 (예를 들어 dd로) 디스크를 해당 섹터로 스왑 아웃 해야하는 경우 긴 SMART 테스트를 수행하면 영향을받는 블록에서 실패 할 수 있지만 내 경험상 드라이브가 시작되면 그냥 바꾸고 끝내는 것이 좋습니다.


0

Solaris에서 ZFS RAID가있는 잘못된 SCSI 디스크가 있습니다. 디스크가 잘못되었다는 증거를 수집하고 Oracle이 하드웨어 유지 관리에서 디스크를 커버하도록 오류 메시지에 대한 정보를 로그 파일에서 스캔했습니다. 오류 로그에서 특정 문자열에 대해 grep을 실행했으며 디스크 오류를 표시하는이 줄은 콘솔 화면에 있습니다. "Explorer"(Solaris 용 시스템 로그 및보고 도구)가 실행되어 Oracle로 전송되면 디스크에 오류가 없다고 말했습니다. 그러나 나는 나의 스크린 역사에 그것들을 가지고 있었다. 나는 확인했고 실제로 디스크의 로그에서 사라졌습니다.

ZFS는 데이터 오류가 아닌 파일 시스템 오류가 없음을 약속합니다. 심각한 손상이 발생하면 트랜잭션을 롤백하여 파일 시스템 무결성을 양호하게하는 데 필요한 모든 작업을 수행합니다. 결과적으로 손상 전에 파일의 이전 버전으로 롤백하면 파일 업데이트가 손실되므로 데이터가 손실 될 수 있습니다. 그러나 파일 시스템에 오류가 없습니다.

간단한 오류의 경우 ZFS는 다른 시도에서 데이터를 롤백하고 다시 쓸 수 있지만 심각한 디스크 동작의 경우 데이터가 복구 및 기록되지 않는 catch-22에 도달 할 수 있습니다. 디스크 오류에 대한 증거를 수집해야하는 경우 화면에 나타나도록하고 ZFS 트랜잭션 롤백에 의해 데이터가 재설정 될 가능성이있는 디스크에있는 증거에 의존하지 마십시오.


두가지. 하나, 나는 이것이 어떻게 질문에 대답하는지 알지 못한다. 아마도 당신은 명확히 할 수 있습니까? 둘째,이 답변은 사실 틀린 것 같습니다. ZFS 팀원 중 한 사람의 에 따르면 " ZFS 종단 간 데이터 무결성 에는 특별한 하드웨어가 필요하지 않습니다"(내 강조). 시스템 충돌이 발생하면 현재 눈에 띄는 txg를 잃을 수 있으며 최근 txgs를 사용할 수없는 경우 사용할 수 있지만 자동 txg 롤백에 대한 클레임은 IMO에 인용이 필요합니다. zpool import -F
CVn

OP는 "ZFS가 읽기 문제에 대해 아무 것도보고하지 않는 이유"라고 물었습니다. 나는 대답하고 있습니다. ZFS는 디스크에 쓸 수 없을 때 디스크의 파일에보고 할 수 없습니다. 하드웨어 성능이 완벽하지 않으면 ZFS를 완벽하게 사용할 수 없습니다. 파일 시스템 손상으로부터 보호하기 만하면됩니다. "종단 간 데이터 무결성"은 "데이터"및 "무결성"의 의미에 따라 다릅니다. "모든 데이터가 어떤 조건에서도 완벽하게 쓰여지거나 읽히지는 않습니다"가 아니라 "부패 없음"을 의미한다고 생각합니다. / var에서 손실을 테스트하는 방법이 있습니다. / var / log 파일에서 누락 된 시간 / 일을 확인하십시오. 나는 것을보고.
labradort

(1) 나는 OP입니다. (2) 질문에 표시된 것처럼 vdev는 미러 구성입니다. (3) 일단 ZFS의 데이터가 영구 저장소에 데이터를 저장하면 데이터는 그대로 유지되며 읽을 수 있거나 I / O 작업이 읽기 오류를 반환합니다. (4) OS가 I / O 문제를 명확하게 감지했으며 커널 자체 또는 ZFS가 그로부터 복구되었지만 (읽기 작업이 성공했기 때문에) I / O 오류는 풀 통계에 기록되지 않았습니다.
CVn

저의 ZFS도 거울이었습니다. 그러나 펌웨어 오류로 인해 정크가 분출되어 디스크가 제대로 작동하지 않을 수 있습니다. 오류 및 풀 통계는 어디에 기록됩니까? 나쁜 미디어에. / var / log 영역의 파일을 확인하십시오. 서버가하는 모든 일에 지속적으로 쓰여지는 파일을보십시오. 메일 인 경우 maillog를보십시오. 웹인 경우 액세스 로그를보십시오. 그렇지 않으면 메시지를 시도하십시오. 내가 옳다면, 로그 파일에서 시간 간격 (제 경우에는 누락 된 날짜)이있을 것입니다. 그것이 데이터가 손실되었다는 증거입니다. 날 믿지마 인용문을 찾지 마십시오. 파일을 보면 무슨 일이 일어나고 있는지 확인할 수 있습니다.
labradort
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.