Linux의 읽기 전용 파일 시스템 오류: 다시 마운트하기 전에 원인 확인

1. 실패 경로의 파일 시스템 확인

EROFS가 난 경로에 `findmnt --target /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS`를 사용하고 디스크명을 추측하지 않는다. util-linux 설명에 따르면 --target은 파일이나 디렉터리를 받아 해당 파일 시스템을 보여 준다. 네 필드를 정확히 기록한다. 명령이 실패하거나 대상이 불명확하면 같은 네임스페이스에서 존재하는 부모 경로를 확인하고 마운트를 확정한 뒤 복구 장치를 선택한다.

원래 경로는 쓰기가 가능해도 읽기 전용 bind 쪽에서는 실패할 수 있다. 다른 마운트 네임스페이스의 컨테이너, 네트워크 파일 시스템, 읽기 전용 스냅샷일 수도 있다. 컨테이너나 서비스에서 난 오류라면 정당한 관리 권한으로 같은 네임스페이스 안에서 살핀다. 호스트의 상태가 쓰기를 거부한 환경과 같지 않을 수 있다.

SOURCE가 원격 공유, loop 장치, device-mapper 볼륨, 스냅샷이면 그 정체를 유지한다. 이름이 비슷하다는 이유로 다른 물리 파티션을 복구하면 상황을 악화시킬 수 있다.

2. 상태를 바꾸기 전에 증거 보관

장애가 남아 있을 때 마운트 기록과 최근 커널 메시지를 보관한다. 읽기용 명령 예는 위 findmnt, `journalctl -k -b --no-pager`, 권한이 있다면 `dmesg`다. 공유 전에 호스트명, 일련번호, 민감 경로를 가린다. systemd가 없다면 해당 시스템의 커널 로그 기능을 쓴다. dmesg -T의 시각은 절전 복귀 후 부정확할 수 있으므로 정확한 실제 시간 순서를 만들어 내지 말고 원본을 보관한다.

나중의 읽기 전용 메시지만 보지 말고 첫 관련 오류를 찾는다. I/O error, journal abort, EXT4-fs error, device reset, link down, multipath failure, write-protected는 원인이 다르다. Red Hat의 실제 사례에서는 모든 저장소 경로가 사라진 뒤 저널이 중단되고 파일 시스템이 읽기 전용으로 바뀌었다.

중요 데이터를 계속 제공한다면 불필요한 쓰기를 멈추고 백업이나 장애 전환을 준비한 다음 시험한다. 반복 재마운트는 하위 경로가 정상이라는 증거가 아니다.

3. 어느 계층이 읽기 전용인지 분류

의도한 정책: OPTIONS의 ro, 변경 불가 매체·스냅샷, /etc/fstab의 ro, 읽기 전용 bind, 원격 서버의 읽기 전용 공유다. 정책을 관리하는 계층에서 고친다. 로컬 재마운트는 일시적이거나 거부될 수 있고 부적절할 수도 있다.

보호 상태: 파일 시스템·저널 오류가 로그에 나타난다. ext4 문서는 errors=remount-ro를 오류 후 읽기 전용 전환으로 설명한다. 출시된 Linux 6.16 코드는 일반 SB_RDONLY 대신 긴급 읽기 전용 플래그를 설정하고 ext4 옵션에 emergency_ro를 표시한다. 설치된 커널의 동작을 확인한다. 단순한 rw 필드나 이 새 표시의 부재만으로 쓰기 안전을 입증할 수 없다. 로그와 실제 실패를 증거로 삼는다.

하위 저장소 보호·장애: 재마운트에 write-protected가 나오거나 장치, 버스, 컨트롤러, 케이블, multipath, 매체 오류가 있다. 먼저 경로를 고치거나 교체한다. 파일 시스템 검사는 메타데이터 손상을 복구할 수 있지만 사라지는 SAN 경로, 불량 케이블이나 컨트롤러 리셋을 고치지는 못한다.

원격·가상 계층: NFS, CIFS, FUSE, 클라우드 볼륨, 컨테이너 마운트, 변경 불가 이미지는 로컬 디스크 밖의 이유로 EROFS를 반환할 수 있다. 해당 계층의 상태와 정책 증거에 따라 조사하고 ext4 방법을 일괄 적용하지 않는다.

4. 유형에 맞는 도구로 오프라인 복구

파일 시스템 손상 증거가 있다면 중단, 장애 전환 또는 복구 환경 부팅으로 대상 마운트를 해제한다. 해제 후 장치를 다시 확인한다. e2fsck 설명은 마운트된 ext2/ext3/ext4 검사가 일반적으로 안전하지 않고, 읽기 전용 검사도 마운트 상태에서는 결과가 유효하지 않을 수 있다고 말한다.

fsck를 실행하라는 말을 그럴듯한 장치에 fsck -y를 실행하라는 뜻으로 받아들이지 않는다. 일반 프런트엔드는 유형별 도구로 넘기며 복구 모델은 다르다. Btrfs 문서는 해제부터 권하며, 경험 있는 개발자나 사용자의 조언 없이 --repair를 쓰지 말라고 경고한다. 기록한 FSTYPE의 현행 문서를 보고 가능한 백업을 마련하며 메타데이터 수정 여부를 파악한다.

저장소 경로 오류가 있다면 메타데이터 복구 전에 경로를 안정화한다. 그렇지 않으면 쓰기 재개 후 다시 손상될 수 있다.

5. 원인 해결 후 다시 마운트하고 검증

의도하지 않은 읽기 전용 상태의 원인을 해결한 뒤 기록한 정확한 TARGET에 파일 시스템·플랫폼 절차를 적용한다. 일반 로컬 예는 `mount -o remount,rw /exact/mountpoint`지만 만능 복구 명령은 아니다. 원격, bind, 컨테이너, 스냅샷, 관리형 볼륨에는 틀린 절차일 수 있다.

같은 실패 경로에 findmnt를 다시 실행한다. 지정한 안전 디렉터리에 통제된 쓰기를 한 번 하고 읽어 확인한 뒤 지운다. 새 파일 시스템·I/O 오류가 있는지 커널 로그를 확인하고 정상 작업 부하를 관찰해 재발을 살핀다.

목표 마운트가 쓰기 가능하고 sync나 애플리케이션 왕복 뒤에도 시험이 성공하며, 새 저장소·파일 시스템 오류나 읽기 전용 재발이 없을 때 완료로 판단한다. 재발하면 재마운트를 해결책으로 삼지 말고 보관한 증거로 장치, 컨트롤러, 네트워크 경로 또는 플랫폼 문제를 조사한다.