일부 하드 드라이브에서 이상한 오류가 발생하여 문제 범위를 좁히는 데 어려움을 겪고 있습니다. 이는 RAID 어레이(Linux 소프트웨어 RAID, 저예산 하드웨어)의 일부이므로 어레이에서 제외되었을 때 나의 첫 번째 반응은 간단히 예비 부품으로 교체하는 것이었습니다. 하지만 재건축은 계속 실패했다.
드라이브는 5드라이브 외부 SATA 인클로저(인클로저 4개, 각각 드라이브 5개)에 있으며 이 인클로저에도 이상한 증상이 나타나는 것을 발견했습니다. 일반적으로 드라이브가 추가되면 인클로저의 SATA 포트 복제기가 새 드라이브를 감지함에 따라 표시등이 특정 방식으로 깜박입니다. 그리고 재구축 중에도 이런 일이 계속 발생했는데, 이는 아마도 포트 복제기의 하드웨어가 실제 범인일 수도 있다는 것을 암시했습니다.
이러한 문제를 해결하기 위해 여분의 인클로저가 있으므로 이를 교체하고 드라이브를 새 인클로저에 넣었습니다. 그러나 이 시점에서는 mdadm드라이브를 전혀 재구축할 수 없습니다. 늘 실패했지즉시시작한 후. 다른 예비 드라이브를 두 개 사용해 보았으나 동일한 증상이 발생했습니다. 확실히 여러 드라이브가 고장난 적이 없습니다똑같은 방법으로~에정확히 같은 시간?
인클로저는 호스트에 설치된 SATA 컨트롤러 카드 2개(각 포트 2개)에 연결됩니다. 어쩌면 카드 중 하나였을까요? 그래서 "문제가 있는" 엔클로저가 다른 카드에 있도록 SATA 케이블을 옮겼습니다. 그러나 동일한 인클로저의 동일한 드라이브 베이에서 동일한 문제가 지속되었습니다.
이 시점에서는 테스트할 항목이 부족합니다. 호스트에 드라이브 2개, 인클로저 2개, 컨트롤러 카드 2개가 있습니다. 이들을 조합하면 동일한 문제가 발생합니다.
이 시점에서 mdadm현재 드라이브에 다시 구축하려고 시도하고 있지만(이번에는 왜 실패하지 않았는지 확실하지 않음)상당히속도 감소. 정상 속도의 1/2에서 1/4 사이에서 변동합니다. 교체 인클로저도 이전 인클로저와 마찬가지로 드라이브를 다시 감지합니다.
이제 저는 하드웨어 진단에 대해 잘 모릅니다. 상용 하드웨어의 경우 일반적으로 교체 주기입니다. 하지만 이 경우 모든 교체 부품이 동일한 방식으로 작동하므로 확실하지 않습니다.무엇문제는. 나는 내가 보고 있는 몇 가지 내용을 인터넷 검색해 보았지만 /var/log/syslog지금까지 그 내용을 많이 이해하지 못했습니다. 나는 당신에게 그것을 말할 수 있습니다 ...
인클로저가 드라이브를 "다시 감지"하면 다음 위치에 표시됩니다 syslog.
Oct 3 17:43:52 gibson kernel: [ 1478.755088] ata5: controller in dubious state, performing PORT_RST
Oct 3 17:43:54 gibson kernel: [ 1480.909415] ata5.05: limiting SATA link speed to 1.5 Gbps
기타 문제가 되고 자주 반복되는 메시지는 다음과 syslog같습니다.
Oct 3 17:46:05 gibson kernel: [ 1612.163891] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x400000 action 0x6
Oct 3 17:46:05 gibson kernel: [ 1612.163894] ata5.00: irq_stat 0x00060002, device error via D2H FIS
Oct 3 17:46:05 gibson kernel: [ 1612.163897] ata5.00: SError: { Handshk }
Oct 3 17:46:05 gibson kernel: [ 1612.163899] ata5.00: failed command: WRITE DMA
Oct 3 17:46:05 gibson kernel: [ 1612.163904] ata5.00: cmd ca/00:00:00:29:87/00:00:00:00:00/e0 tag 0 dma 131072 out
Oct 3 17:46:05 gibson kernel: [ 1612.163905] res 51/84:90:70:29:87/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
Oct 3 17:46:05 gibson kernel: [ 1612.163907] ata5.00: status: { DRDY ERR }
Oct 3 17:46:05 gibson kernel: [ 1612.163909] ata5.00: error: { ICRC ABRT }
때로는 다음과 같은 경우도 있습니다.
Oct 3 18:07:10 gibson kernel: [ 2877.073010] ata5.00: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073015] ata5.00: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073017] ata5.01: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073020] ata5.01: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073022] ata5.02: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073024] ata5.02: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073026] ata5.03: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073028] ata5.03: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073030] ata5.04: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073032] ata5.04: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073034] ata5.05: failed to read SCR 1 (Emask=0x40)
실행할 수 있는 다른 테스트가 있나요? 다른 방법을 시도해 볼 수 있나요? 무엇~할 수 있었다사용 중인 하드웨어에 관계없이 증상이 나타나는 것은 잘못된 것입니까?
어레이는 가끔씩 드라이브를 교체하면서 몇 년 동안 잘 작동했습니다. 호스트에서는 소프트웨어 변경이 이루어지지 않았습니다(손상되어 이를 알지 못하는 경우는 제외됩니다. 이는 확실히 가능합니다). 하지만 몇 달 전 드라이브 오류로 인해 계속해서 재구축이 이루어졌고 결국 현재 상태가 되었습니다.
편집하다:방금 깨달은 또 다른 패턴이지만 그것이 의미하는 바가 있는지 확실하지 않습니다. 어레이의 드라이브는 을 sdb1통해 이루어집니다 sdu1. 부팅 OS에서 항상 동일한 순서로 표시되는 것은 아니므로 특정 드라이브는 재부팅 시 문자가 변경될 수 있습니다. 드라이브가 지속적으로 실패하는 경우즉시mdadm재구축 시에는 /dev/sdq1. 그러나 현재 증상 전체(느린 재구축, 엔클로저를 계속해서 "다시 감지"하고 기본적으로 위에 기록된 오류)는 입니다 /dev/sdu1.
편집하다:어레이를 시작하고 거기에 드라이브를 추가할 수 있는지 확인하기 위해 Knoppix 7.2를 다운로드했습니다. 소프트웨어 문제인지 확인하기 위해. 정확한 증상은 동일합니다. 그래서... 하드웨어도 교체하고, 소프트웨어도 교체했지만 문제는 지속됩니다. 이로 인해 현재로서는 막다른 골목에 놓이게 되었습니다.
편집하다:나는 또한 다음과 같이 드라이브를 제로화하려고 시도했습니다.
dd if=/dev/zero of=/dev/sdu bs=1M
하지만 같은 증상이 지속됩니다. 이 시점에서 나는 컨트롤러에 문제가 있는 것이 아닐까 의심하지만 어떤 의미에서는 이해가 되지 않습니다. 2개의 카드는 각각 작동하지만 어떤 이유로든 둘 다 함께 이 많은 드라이브를 관리할 수 없습니까? 말이 안 될 수도 있습니다. 저는 단지 여기서 패턴을 식별하려고 노력하고 있습니다.
편집하다:출력 smartctl -a -d ata /dev/sdu:
smartctl 5.40 2010-10-16 r3189 [x86_64-slackware-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green family
Device Model: WDC WD20EADS-00S2B0
Serial Number: WD-WCAVY0536607
Firmware Version: 01.00A01
User Capacity: 2,000,398,934,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sat Oct 5 07:04:21 2013 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (42900) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
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 179 179 051 Pre-fail Always - 90370
3 Spin_Up_Time 0x0027 149 149 021 Pre-fail Always - 9525
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6170
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 18
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 9
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 610025
194 Temperature_Celsius 0x0022 117 073 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 125
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 62927
200 Multi_Zone_Error_Rate 0x0008 090 090 000 Old_age Offline - 22176
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
업데이트:나는 이 케이퍼에서 처음으로 유망한 휴식을 취할 수도 있습니다. 지난 6시간 정도(켜고 끄고) 드라이브/인클로저/케이블/카드를 교체하고 체계적으로 패턴을 찾으려고 노력한 끝에 마침내 패턴을 찾았습니다. 그리고 하나는 제가 지속적으로 재현할 수 있는 것입니다.
핫스왑을 좋아하지 않습니다.
그렇다고 합니다. 이라고 합니다. 그리고 이 약속을 지키기 위해 최선을 다합니다. 그러나 그것은 거짓말이다. 여기서 역할을 하는 하위 수준 하드웨어 아키텍처 및/또는 커널 아키텍처에 대해 아는 척은 하지 않겠지만, 적어도 재현 가능한 패턴을 논리적으로 결정할 수는 있습니다.
그리고 나는 이번 여름에 자신도 모르게 핫스왑 대란을 시작했을 것이라고 확신합니다.원인결과적으로 이 모든 혼란이 발생했습니다. syslog내가 본 오류는 6월에 시작되었는데, 그 때는 큰 실패가 발생하기 직전이자 여름방학 동안 SF에 가서 작업을 할 수 없게 되기 직전이었습니다.
그러나 디스크를 이동해야 할 때마다 재부팅하면 지금까지는 오류가 표시되지 않습니다. 20번째 디스크가 다시 추가되어 올바른 속도로 다시 빌드되고 있으며(2TB 디스크의 경우 여전히 약 36시간 소요) 지금까지 조용했던 ( tail -f)을 지켜보고 있습니다.syslog
이에 대해 자신있게 보고하려면 며칠이 걸릴 것입니다. 그러나 지금까지는 유망해 보입니다. 이에 대한 대답5월결국 "Linux에서 Rosewill RSV-S5로 핫스왑하지 마세요"라는 말을 듣게 됩니다.
답변1
하드웨어나 이를 제어하는 커널 드라이버 주변의 저수준 아키텍처에 대해서는 아직 잘 모르지만, 이 경우 "해결책"은 드라이브를 핫스왑하지 않는 것 같습니다.
따라서 Linux에서 Rosewill RSV-S5(또는 이와 유사한 것)를 사용할 때(다른 시스템에서도 가능할지 모르겠습니다) 절대로 핫스왑하지 마십시오. 그리고 sysloga가 수행되었다는 메시지가 나타나면 PORT_RST안전을 위해 재부팅하세요.
핫스왑은 처음에는 작동하는 것처럼 보일 수 있습니다. 드라이브에 FS가 마운트되어 있지 않고 그냥 파티션일 뿐이며 하드웨어는 드라이브 레일 등으로 설정되어 있습니다. 새 드라이브를 넣으면 시스템이 이를 인식하고 상호 작용할 수 있는 장치를 할당합니다. 하지만 syslog안전을 위해 계속 지켜봐주세요 .