☰

Linux, 일시적인 충돌 후 HDD 상태를 ReadOnly에서 변경하는 방법은 무엇입니까?

tag-icon • tag-icon linux readonly mount
Linux, 일시적인 충돌 후 HDD 상태를 ReadOnly에서 변경하는 방법은 무엇입니까?

현재로서는 이 문제에 대한 답변이 없습니다.

일반적으로 블록 장치에 대한 읽기 또는 쓰기에 문제가 발생한 후 커널은 WHOLE DEVICE에 대한 플래그를 읽기 전용으로 전환하기로 결정합니다. 이후 이 장치에 있는 파티션/파일 시스템에 쓰기를 하면 장치 상태와 함께 읽기 전용으로 전환됩니다. 쓰기가 불가능하기 때문입니다.

dmesg의 예는 조각 모음이 게스트 장치 이미지를 가져올 때 VirtualBox를 사용하는 Windows8의 게스트 Linux에 대한 시뮬레이션입니다.

[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. HDD가 정말 손상되었습니다. 반환된 쓰기 문제는 HDD 상태에 따라 다릅니다.
  2. 호스트 시스템이 오버로드되고 Linux 게스트 가상 HDD 쓰기 시간이 초과됩니다.
  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. 제거 모듈은 지정된 HDD 또는 스토리지 배열에 대한 액세스를 지원합니다. 불행히도 일반적으로 손상된 장치는 rootfs를 유지하거나 드라이버는 손상된 장치와 rootfs를 유지하는 장치를 모두 유지합니다.
  2. 장치에 대한 FC 액세스를 제거하고 다시 연결합니다(fctools). 항상 가능한 것은 아니며 항상 작동하는 것은 아닙니다.
  3. 전체 기계를 다시 시작하십시오. 일반적으로 이것은 항상 가능하며 우리는 항상 그렇게 해야 합니다.

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

동일한 상황에서 Windows(데스크톱 및 서버)에는 문제가 없습니다.

답변1

blockdev --setrw또는 로 시도해 보세요hdparm -r 0

답변2

Jose Luis Martin이 blockdev 사용을 제안한 것처럼, 내 2cent는 rw 및 forcefsck를 다시 마운트하는 것입니다.

(sda가 디스크라고 가정)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

답변3

이 위키 페이지를 확인하세요. libata에서 발생하는 오류에 대해 설명되어 있습니다.

https://ata.wiki.kernel.org/index.php/Libata_error_messages

위에서 본 내용에 따르면 시간 초과 문제가 있으며 언급된 문서에 따라 다음과 같습니다.

컨트롤러가 활성 ATA 명령에 응답하지 못했습니다. 원인은 다양할 수 있습니다. 대부분의 경우 이는 하드웨어에서 인터럽트를 예상했을 때 인터럽트를 전달하지 못한 관련 없는 인터럽트 하위 시스템 버그('pci=nomsi', 'acpi=off' 또는 'noapic'으로 부팅해 보세요)로 인해 발생합니다.

ACPI를 비활성화하거나(배포판 기반 방법 확인) 커널에 알려진 버그가 있는지 확인하고 최신이 아닌 경우 업데이트(또는 다운그레이드)할 수 있습니다.

답변4

###안녕하세요. 다음 명령어가 도움이 될 수 있습니다. 그러나 실행 중인 드라이브의 루트 파일 시스템을 마운트 해제하거나 수정하려고 시도하는 것은 안전하지 않습니다. 대신 부팅 가능한 장치에서 시스템을 부팅하십시오.

  1. 시스템에서 드라이브 찾기
$ mount | grep /dev/
  1. 드라이브 마운트 해제
$ sudo umount <your-mount-point-name>
  1. 다음 명령 중 하나를 사용하여 파일 시스템을 확인하고 복구하십시오.

###ext4 장치의 경우

$ sudo fsck.ext4 -f /dev/sda1

###DOS 장치의 경우

$ sudo dosfsck -a /dev/sda1

###또는 단순히 fsck명령을 실행할 수도 있습니다.

$ sudo fsck /dev/sda1
  1. 장치를 다시 마운트하십시오.
$ sudo mkdir <your-mount-point-name>

그러면 새로운 마운트 지점이 생성됩니다. 그런 다음 다음을 실행하십시오.

$ sudo mount -o rw,uid=1000,gid=1000,user,exec,umask=003,blksize=4096 /dev/sdc1 /media/<your-mount-point-name>

가셔도 됩니다. 그러나 명령에 대한 자세한 내용은 다음을 참조하세요.벨둥

관련 정보