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를 저장하십시오.
답변
최근 에이 문제가 발생하여 재부팅하여 문제를 해결했지만 추가 조사 후 다음 명령을 실행하면 문제가 해결 될 수 있습니다.
echo running > /sys/block/device-name/device/state
이 문서 에서 섹션 25.14.4 : 온라인 논리 장치의 읽기 / 쓰기 상태 변경 을 살펴보고 싶을 수도 있지만 재부팅하는 것이 좋습니다.
답변
다음을 사용하십시오.
mount -o remount,rw /mnt/fo
답변
나는 처음부터 문제를 예방하는 팬입니다. 대부분의 엔터프라이즈 UNIX 상자는 영원히 같은 파일 시스템 작업을 재 시도합니다. 관리자는 MPIO 구성을 조정하기 전에 약간의 숙제를해야합니다. 장치가 사용 가능한 상태로 돌아올 때까지 응용 프로그램이 대기해야하는 경우 여기 해결책이 있습니다. /etc/multipath.conf에서 관심있는 장치 유형에 “no_path_retry”설정이 “queue”로 설정되어 있는지 확인하십시오. 이를 설정하면 유효한 경로가 될 때까지 실패한 I / O가 대기열에있게됩니다. EMC Symmtrix / DMX 박스가 드라이브 / 컨트롤러 / srdf 경로 장애 / 복구 특정 조건에서 딸꾹질에 대해 작동하도록하기 위해이 작업을 수행했습니다.
이 접근 방식은 베이컨을 엄청나게 절약했으며 재해 복구를위한 복제 기능을 갖춘 멀티 캐비닛 / 멀티 벤더 SAN의 수백 상자에 대한 표준입니다.
내가 당신과 모두 공유 할 수 있다고 생각했습니다. 조심해
답변
논리적 인 다중 경로 장치의 서브 드라이브 에서 옵션 과 함께 hdparm 을 사용하여 해결 한 몇 가지 문제가있었습니다 -r.
-r 장치의 읽기 전용 플래그를 가져 오거나 설정합니다. 설정하면 Linux는 장치에서 쓰기 작업을 허용하지 않습니다.
답변
이 문서에서 SAN (Storage Area Network)의 ext3 파일 시스템이 반복적으로 읽기 전용이되는 이유 섹션 과 관련이 있다고 생각하십니까 ?
꽤 오래된 기사이며 파이버 채널에 대해 이야기하고 있지만 문제와 관련이있을 수 있습니다.
답변
파일 시스템 손상? 시험:
dumpe2fs /dev/c/c | grep Filesystem\
오류가있는 경우에는 스캔하고 청소해야합니다.
답변
Linux는 단순히 중간 규모의 SAN에 적합하지 않습니다. IO 시간 초과 및 다중 경로 시간 초과 처리를주의 깊게 조정하고 미세 조정해야합니다. 모두 데스크톱 준비 기본값입니다.
( “죽은 장치에 IO 거부”를 기억하십니까?)