디스크 오류로 인해 읽기 전용으로 마운트 된 후 ext3 fs 읽기 / 쓰기를 어떻게 다시 마운트합니까?


18

ext3의 SAN에서 문제가 발생하여 디스크 쓰기 오류를 감지하고 파일 시스템을 읽기 전용으로 다시 마운트하는 경우 비교적 일반적인 문제입니다. SAN이 고정되어있을 때만 재부팅이되지 않고 파일 시스템 읽기 / 쓰기를 다시 마운트하는 방법을 알 수 없습니다.

보다:

[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16  [active][ready]
\_ 2:0:0:1 sdc 8:32  [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah

이제는 LUN 아래에서 LUN을 꺼냅니다.

[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur checker reports path is down
Mar 18 13:17:35 localhost kernel: Aborting journal on device dm-2.
Mar 18 13:17:35 localhost kernel: Buffer I/O error on device dm-2, logical block 1545
Mar 18 13:17:35 localhost kernel: lost page write due to I/O error on dm-2
Mar 18 13:17:36 localhost kernel: ext3_abort called.
Mar 18 13:17:36 localhost kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb:   Detected aborted journal                      
Mar 18 13:17:36 localhost kernel: Remounting filesystem read-only

그것은 읽기 전용, 실제로는 거기조차 없다고 생각합니다.

[root@localhost ~]# multipath -ll
sdb: checker msg is "tur checker reports path is down"
sdc: checker msg is "tur checker reports path is down"
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:1 sdb 8:16  [failed][faulty]
 \_ 2:0:0:1 sdc 8:32  [failed][faulty]
[root@localhost ~]# ll /mnt/foo/
ls: reading directory /mnt/foo/: Input/output error
total 20
-rw-r--r-- 1 root root     0 Mar 18 13:11 bar

'bar'파일이 거기에 있다는 것을 아직도 기억하는 방법은 ... 수수께끼이지만 지금은 중요하지 않습니다. 이제 LUN을 다시 나타냅니다.

[root@localhost ~]# tail /var/log/messages
Mar 18 13:23:58 localhost multipathd: sdb: tur checker reports path is up
Mar 18 13:23:58 localhost multipathd: 8:16: reinstated
Mar 18 13:23:58 localhost multipathd: mpath0: queue_if_no_path enabled
Mar 18 13:23:58 localhost multipathd: mpath0: Recovered to normal mode
Mar 18 13:23:58 localhost multipathd: mpath0: remaining active paths: 1
Mar 18 13:23:58 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:58 localhost multipathd: dm-2: devmap already registered
Mar 18 13:23:59 localhost multipathd: sdc: tur checker reports path is up
Mar 18 13:23:59 localhost multipathd: 8:32: reinstated
Mar 18 13:23:59 localhost multipathd: mpath0: remaining active paths: 2
Mar 18 13:23:59 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:59 localhost multipathd: dm-2: devmap already registered
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][enabled]
 \_ 1:0:0:1 sdb 8:16  [active][ready]
 \_ 2:0:0:1 sdc 8:32  [active][ready]

좋아? 바로 거기에 [rw]라고 쓰여 있습니다. 그렇게 빠르지 않은

[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system

좋아, 자동으로하지 않는, 나는 약간의 푸시를 줄 것이다 :

[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

도대체 당신은 :

[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

안돼

모든 종류의 다른 mount / tune2fs / dmsetup 명령을 시도했지만 블록 장치를 쓰기 방지 된 플래그로 표시 해제하는 방법을 알 수 없습니다. 재부팅하면 문제가 해결되지만 온라인에서는 훨씬 낫습니다. 한 시간의 인터넷 검색도 어디에서도 얻지 못했습니다. ServerFault를 저장하십시오.


3
흠, 몇 가지 질문 'SAN에서 문제가 발생했을 때 비교적 일반적인 문제입니다' 왜 SAN이 그렇게 신뢰할 수 없는지, 먼저 확인해야합니까? umount로 마운트 해제 한 다음 다시 마운트 해 보셨습니까? 다시 마운트해야하는 좋은 이유가 있습니까? 일반적으로 유지 관리 후에 루트 파일 시스템 만 다시 마운트하면됩니다.
유닉스 청소부

열려있는 파일 핸들에서 umount는 튀어 오릅니다.이 핸들은 종종 당신이 오히려 끝내기 힘든 프로세스에서 비롯됩니다.
cagenut

SAN 문제 후에 VM 디스크가 읽기 전용이고 다시 마운트하려고하면 OP에서 동일한 오류가 발생하는 비슷한 문제가 있습니다. VM은 파이버 채널 스토리지가있는 esxi 4.1에 있습니다. VM을 재부팅하면 문제가 해결됩니다. 나는 이것이 다중 경로와 관련이 있다고 개인적으로 생각하지 않습니다. 특히 일부 서비스 (apache)가 읽기 전용 FS에서 계속 실행되는 경향이 있기 때문에 재부팅하지 않고 해결할 수있는 방법이 있어야합니다.

나는 내 자신의 문제 (다른, 손상된 디스크)에 대한 해결책을 찾기 위해 여기에 왔습니다. 나는 대신 웃었다. "지옥"에 +1
user1207217

나는 이것과 똑같은 문제가 있지만 LVM을 사용하고 있습니다. 동일한 lvdisplay는 "multipath -r"을 수행 할 때까지 "449197309952에서 0의 4096 이후 읽기 실패 : 입력 / 출력 오류"를 표시 한 다음 LVM이 오류없이 모든 것을 올바르게 표시하기 시작했습니다. 그래도 파티션을 다시 마운트 할 수는 없습니다. 장치가 사용 중이라고 마운트를 해제 할 수 없습니다. 장치를 사용하여 모든 프로세스를 종료하면 마운트를 해제했다가 다시 마운트 할 수 있지만 가능한 경우 장치를 읽기 / 쓰기로 다시 마운트하는 것이 좋습니다.
mpontes

답변:


6

최근 에이 문제가 발생하여 재부팅하여 문제를 해결했지만 추가 조사 후 다음 명령을 실행하면 문제가 해결 될 수 있습니다.

echo running > /sys/block/device-name/device/state

이 문서 에서 섹션 25.14.4 : 온라인 논리 장치의 읽기 / 쓰기 상태 변경 을 살펴보고 싶을 수도 있지만 재부팅하는 것이 좋습니다.


고마워 Kevin. (Un) 불행히도 문제는 오랫동안 사라져서 테스트 할 수 없지만 가장 유망한 옵션처럼 보입니다.
cagenut

3
비슷한 문제로 / sys / block / device-name / device / state가 이미 'running'으로 설정되어 있고 위의 명령으로 문제가 해결되지 않았습니다.

3

다음을 사용하십시오.

mount -o remount,rw /mnt/fo

나는 리눅스가 아니라 FreeBSD를 알고있다. 그러나 fBSD의 경우 이므로이 것이 mount -rw /mnt/foo가장 잘 보입니다.
Chris S

1
질문에 요약 된 시나리오 에서이 작업을 한 적이 없습니다. 오류로 인해 디스크가 읽기 전용으로 표시되면 항상 재부팅됩니다.
Alex

1
이것을 OP로 편집 하겠지만 Alex는 바로 여기에 문제가 파일 시스템 아래에있는 것 같습니다 : [root @ localhost ~] # mount -o remount, rw / mnt / foo mount : block device / dev / mapper / mpath0는 쓰기 방지, 장착 읽기 전용입니다
cagenut

1
파티션을 마운트 해제했다가 다시 마운트 해 보셨습니까? 드라이브와 함께 이전에 데이터 오류가 있었으므로 마운트 해제 (또는 마운트 해제, rw)로 인해 문제가 해결되었습니다. 이것은 SATA 드라이브 (및 이전 EIDE / SCSI)와 관련이 있지만 귀하의 상황에서 드라이브 채널을 재설정 해야하는 문제인지 궁금합니다. 어떻게 든 HDIO_DRIVE_RESET이 ioctl을 통해 전송되었는지 궁금합니다. blockdev를 사용하면 파티션 테이블을 강제로 다시 읽을 수 있습니다. IDE는 이것을 hdparm -w, 아마도 FC 드라이브와 함께 노출하여 ioctl을 채널로 보낼 수 있습니다.

2

나는 처음부터 문제를 예방하는 팬입니다. 대부분의 엔터프라이즈 UNIX 상자는 영원히 같은 파일 시스템 작업을 재 시도합니다. 관리자는 MPIO 구성을 조정하기 전에 약간의 숙제를해야합니다. 장치가 사용 가능한 상태로 돌아올 때까지 응용 프로그램이 대기해야하는 경우 여기 해결책이 있습니다. /etc/multipath.conf에서 관심있는 장치 유형에 "no_path_retry"설정이 "queue"로 설정되어 있는지 확인하십시오. 이를 설정하면 유효한 경로가 될 때까지 실패한 I / O가 대기열에있게됩니다. EMC Symmtrix / DMX 박스가 드라이브 / 컨트롤러 / srdf 경로 장애 / 복구 특정 조건에서 딸꾹질에 대해 작동하도록하기 위해이 작업을 수행했습니다.

이 접근 방식은 베이컨을 엄청나게 절약했으며 재해 복구를위한 복제 기능을 갖춘 멀티 캐비닛 / 멀티 벤더 SAN의 수백 상자에 대한 표준입니다.

내가 당신과 모두 공유 할 수 있다고 생각했습니다. 조심해


2

논리적 인 다중 경로 장치의 서브 드라이브 에서 옵션 과 함께 hdparm 을 사용하여 해결 한 몇 가지 문제가있었습니다 -r.

-r 장치의 읽기 전용 플래그를 가져 오거나 설정합니다. 설정하면 Linux는 장치에서 쓰기 작업을 허용하지 않습니다.


1

이 문서에서 SAN (Storage Area Network)의 ext3 파일 시스템이 반복적으로 읽기 전용이되는 이유 섹션 과 관련이 있다고 생각하십니까 ?

꽤 오래된 기사이며 파이버 채널에 대해 이야기하고 있지만 문제와 관련이있을 수 있습니다.


그러나 내가 참조하는 것보다 훨씬 새로운 버전을 실행하고 있기 때문에 정확한 특정 버그는 아니지만 모든 종류의 유사한 상황으로 인해 버그가 발생할 수 있습니다. 파이버 채널, hbas / hba- 펌웨어 / hba 드라이버, 어레이 펌웨어, 스위치 펌웨어, 패브릭 디자인, 장치 매퍼 / 다중 경로 구성, lvm 및 ext3의 세계는 많은 이동 부품입니다. 충분한 환경에서 작업하면 유사하지만 동일하지 않은 문제로 인해이 시나리오가 나타납니다. 문제는 재부팅하지 않고 복구 / 재 장착하는 방법입니다.
cagenut

0

파일 시스템 손상? 시험:

dumpe2fs /dev/c/c | grep Filesystem\

오류가있는 경우에는 스캔하고 청소해야합니다.


-4

Linux는 단순히 중간 규모의 SAN에 적합하지 않습니다. IO 시간 초과 및 다중 경로 시간 초과 처리를주의 깊게 조정하고 미세 조정해야합니다. 모두 데스크톱 준비 기본값입니다.

( "죽은 장치에 IO 거부"를 기억하십니까?)


1
"Linux는 SAN에 대응하지 않습니다"및 "데스크탑 준비 기본값"과 같은 명령문을 참조 및 어려운 사실로 백업해야합니다.
Chris S

1
30 초의 기본 디스크 IO 시간 초과? 위의 실? RedHat의 메모 (그대로 구식)는 의도 한대로 "상태 변경 알림"을 ​​정상적으로 처리 할 수 ​​없다는 내용의 메모입니다. Redhat은 기본적으로 다중 경로 바인딩을 다중 경로 드라이버의로드시 액세스 할 수없는 위치 (/ var / lib)에 넣었습니까? PCI 핫 플러그 ​​hba를 재귀 적으로 핫 비활성화 할 수 없으며 교체 될 때까지 모든 종속 LUN을 일시적으로 자동으로 오프라인 상태로 만듭니다. 멀티 스레드 HW init가없고> 1k luns가 나오기까지 "시간이 걸린다". Udev, 쉘 스크립트 ...
darkfader
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.