Linux, 일시적인 충돌 후 하드 드라이브 상태를 읽기 전용에서 읽기 전용으로 변경하는 방법은 무엇입니까?

현재 이 질문에 대한 답변이 없습니다.

일반적으로 블록 장치를 읽거나 쓰는 데 문제가 발생한 후 커널은 전체 장치의 플래그를 읽기 전용으로 전환하기로 결정합니다. 그 후에는 장치의 파티션/파일 시스템에 쓰기를 수행하면 쓰기가 불가능하므로 장치 상태와 함께 읽기 전용으로 전환됩니다.

게스트 장치 이미지를 얻기 위해 조각 모음을 수행할 때 VirtualBox를 사용하여 Windows 8에서 게스트 Linux를 에뮬레이션하는 dmesg의 예:

[11903.002030] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11903.003179] ata3.00: failed command: READ FPDMA QUEUED
[11903.003364] ata3.00: cmd 60/08:00:a8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11903.003385]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11903.004074] ata3.00: status: { DRDY }
[11903.004248] ata3: hard resetting link
[11903.325703] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11903.327097] ata3.00: configured for UDMA/133
[11903.328025] ata3.00: device reported invalid CHS sector 0
[11903.329664] ata3: EH complete
[11941.000472] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11941.000769] ata3.00: failed command: READ FPDMA QUEUED
[11941.000952] ata3.00: cmd 60/08:00:c8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11941.000961]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11941.001353] ata3.00: status: { DRDY }
[11941.001504] ata3: hard resetting link
[11941.320297] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11941.321252] ata3.00: configured for UDMA/133
[11941.321379] ata3.00: device reported invalid CHS sector 0
[11941.321553] ata3: EH complete
[11980.001746] ata3.00: exception Emask 0x0 SAct 0x11fff SErr 0x0 action 0x6 frozen
[11980.002070] ata3.00: failed command: WRITE FPDMA QUEUED
[11980.002255] ata3.00: cmd 61/18:00:28:23:59/00:00:00:00:00/40 tag 0 ncq 12288 out
[11980.002265]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
-------------------
There are many other errors, like "lost write page", "Journal has aborted", "Buffer I/O error", "hard resetting link" and many others.

그 후 다시 설치하는 이유는 다음과 같습니다.

mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected

rootfs sda1에 예약된 전체 장치 sda가 읽기 전용이기 때문입니다.

내 경험에 따르면 다음과 같은 경우에 이런 일이 발생합니다.

1. 실제로 하드 드라이브가 손상되었습니다. 반환된 쓰기 문제는 하드 드라이브 상태에 따라 다릅니다.
2. 호스트가 오버로드되고 Linux 게스트 가상 하드 디스크 쓰기 시간이 초과됩니다.
3. 과부하된 FC 케이블 또는 SAN 장치(파이버 채널 기반 어레이 디스크)
4. FC 또는 FCoE를 통한 연결이 일시적으로 끊어졌습니다. FC 패킷의 손실/시간 초과 가능성

이 경우 장치는 실제로 읽기-쓰기가 가능하지만 Linux 커널은 내부적으로 장치를 읽기 전용으로 표시하고 읽기 전용 방식으로 사용합니다. 이는 손상을 방지하도록 설계된 커널 기능이지만 지점 1에서만 사용할 수 있습니다.

문제는. hdd 블록 장치가 제대로 작동하고 있음을 커널에 수동으로 알리는 방법은 무엇입니까?

이것이 없으면 커널은 장치를 "CD-ROM"과 같은 읽기 전용으로 처리하며 mount/remount -o read-write , fsck 등을 포함한 다른 명령은 제대로 작동할 기회가 없습니다.

도움을 주고 싶지만 문제의 본질을 이해하지 못하는 사람들이 보낸 효과가 없고 스팸인 답변:

1. 읽기-쓰기로 다시 마운트해 보십시오(불가능, 장치는 RO임).
2. fsck(소용이 무엇입니까? 장치는 RO이므로 수리할 수 없습니다)
3. "모르겠어요"(처음에는 이해가 되지만 쓸모가 없음)
4. "기기 교체"*(대개 문제는 다른 것임)

위 문제의 공식을 아는 사람이 있나요? 읽기 전용에서 읽기-쓰기 상태로 복원하기 위해 쓰기 가능한 블록 장치에 대한 플래그를 토글하시겠습니까? 현재로서는 무엇을 해야 할지 아는 사람이 아무도 없는 것 같습니다.

다음은 몇 가지 해결 방법이지만 일반적으로 반쯤 사용할 수 있거나 사용할 수 없습니다.

1. 삭제 모듈은 지정된 하드 디스크 또는 스토리지 배열에 대한 액세스를 지원합니다. 불행하게도 손상된 장치에 rootfs가 유지되거나 드라이버가 손상된 장치와 rootfs를 유지하는 장치를 모두 유지하는 경우가 많습니다.
2. 장치에 대한 FC 액세스를 제거하고 다시 연결(fctools)하는 것이 항상 가능한 것은 아니며 항상 작동하는 것도 아닙니다.
3. 전체 시스템을 다시 시작하십시오. 종종 이것만이 가능하며 우리는 항상 그렇게 하도록 강요받습니다.

지점 1과 2에서는 커널에 장치와의 연결을 완전히 끊었다가 다시 연결하라고 알립니다. 커널은 이를 새로운 작동 장치를 추가하는 것으로 인식합니다. USB 장치를 사용하여 이를 시뮬레이션하고 일시적으로 전원 공급 장치를 분리할 수 있습니다. 포인트 3은 마지막 기회이며 일반적으로 작동합니다. 그런데 왜 모든 것을 다시 시작해야 합니까? 불행하게도 우리는 모든 면에서 모든 로그 업데이트와 더티 버퍼를 잃었습니다.

동일한 상황에서 저는 아무런 문제 없이 Windows(데스크톱 및 서버)를 사용하고 있습니다.