리눅스 서버가 갑자기 Read-only file system으로 전환되면 대부분 애플리케이션 장애가 연쇄적으로 발생한다. 이때 가장 먼저 확인해야 할 것은 애플리케이션 로그가 아닌, 커널과 파일시스템 로그다.

대표적인 커널 로그 패턴 (원인) #

EXT4-fs error (device sda1): ext4_journal_check_start: Detected aborted journal
EXT4-fs (sda1): Remounting filesystem read-only

• 의미: ext4 저널 오류 발생 → 커널이 파일 시스템 보호를 위해 강제로 Read-only 마운트 수행

Buffer I/O error on dev sda, logical block 123456
blk_update_request: I/O error, dev sda, sector 789012

• 의미: 디스크 I/O 오류 → 물리 디스크 또는 스토리지/하이퍼바이저 계층 문제 가능성 높음

애플리케이션 로그에서 보이는 징후 (결과) #

touch: cannot touch '/var/run/app.pid': Read-only file system
mkdir: cannot create directory ‘/var/log/app’: Read-only file system

• 의미: 이미 파일시스템이 Read-only 상태임. (이 로그는 원인이 아니라 결과임에 유의)

dmesg에서 보이는 결정적 신호 #

Aborting journal on device sda1.
EXT4-fs error (device sda1)

• 이 로그가 보이면 → 커널 판단으로 쓰기 차단 완료 (재부팅 없이 자동 복구 안 됨)

즉시 확인해야 할 체크 포인트 (Command) #

# 1. 현재 마운트 상태 확인 (ro 옵션 확인)
mount | grep ' ro,'

# 2. 커널 메시지에서 에러 패턴 검색
dmesg | egrep -i 'ext4|i/o error|read-only'

# 3. 최신 커널 로그 확인
journalctl -k | tail

핵심 요약 #

1. Read-only 전환은 보호 동작이지 원인이 아니다.
2. 원인은 대부분 디스크 I/O 오류, 저널 손상, 스토리지 장애다.
3. 로그에서 Remounting filesystem read-only가 보이면 이미 장애는 발생한 상태다.
4. 이 패턴을 먼저 잡고 인프라/OS 레벨을 봐야지, 불필요한 애플리케이션 디버깅을 피할 수 있다.

🛠 마지막 수정일: 2025.12.23