스토리지 단절 로그 분석

스토리지 단절 로그를 blocked task, blk_update_request, Buffer I/O error, D 상태 프로세스, 디바이스 매핑, SMART/NVMe/multipath/NFS 기준으로 분석합니다.

스토리지 단절 로그는 단순한 디스크 오류 메시지가 아니라, 커널 I/O 경로에서 요청이 오래 막혔다는 신호입니다. blocked for more than 120 seconds, blk_update_request, Buffer I/O error, sd X:X:X:X, reset, abort 같은 문구를 함께 보면 어느 계층에서 멈췄는지 추적할 수 있습니다.

대표 로그 예시

[  123.456789] INFO: task myapp:1234 blocked for more than 120 seconds.
[  123.456790] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  123.456800] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 01 23 45 67 00 00 10 00
[  123.456810] blk_update_request: I/O error, dev sda, sector 1234567
[  123.456820] Buffer I/O error on dev sda, logical block 12345, async page read
[  123.456830] INFO: task systemd:1 blocked for more than 120 seconds.

blocked for more than 120 seconds는 프로세스가 uninterruptible sleep 상태, 즉 보통 D 상태에서 오래 기다렸다는 뜻입니다. 원인은 로컬 디스크, RAID, SAN, iSCSI, NFS, multipath, 파일시스템 lock 등 다양합니다.

로그 수집 명령

장애 시간대를 기준으로 커널 로그를 먼저 모읍니다.

journalctl -k -S "2026-06-23 14:00:00" -U "2026-06-23 15:00:00" --no-pager \
  | egrep -i 'blocked for more than|I/O error|blk_update|Buffer I/O|reset|abort|nfs|multipath|scsi|nvme|xfs|ext4'

dmesg -T | egrep -i 'blocked for more than|I/O error|blk_update|Buffer I/O|reset|abort|nfs|multipath|scsi|nvme|xfs|ext4' | tail -n 200

동시에 D 상태 프로세스가 있는지 확인합니다.

ps -eo pid,ppid,stat,wchan:32,comm,args | awk '$3 ~ /D/ {print}'
cat /proc/loadavg
vmstat 1 5

디바이스 매핑

로그의 dev sda가 어떤 디스크, LVM, 파일시스템, 마운트포인트와 연결되는지 매핑합니다.

lsblk -o NAME,KNAME,MAJ:MIN,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN
findmnt -D
udevadm info --query=all --name=/dev/sda | egrep 'ID_SERIAL|ID_WWN|ID_MODEL'

LVM 환경에서는 논리 볼륨과 실제 디바이스를 같이 봅니다.

sudo pvs -o+pv_used,devices
sudo vgs
sudo lvs -a -o +devices

파일시스템 오류 확인

XFS와 ext4는 오류 메시지 패턴이 다릅니다.

journalctl -k --no-pager | egrep -i 'XFS|EXT4|remount|read-only|metadata I/O error' | tail -n 120
mount | grep ' ro[),]'

파일시스템이 read-only로 remount되었다면 애플리케이션 장애가 이미 진행 중일 가능성이 큽니다. 이 상태에서 무리하게 쓰기 작업을 계속하지 말고 원인 디바이스와 백업 상태를 먼저 확인합니다.

I/O 지연과 장치 상태

iostat -xz 1 10
pidstat -d 1 5
sudo smartctl -H /dev/sda
sudo smartctl -a /dev/sda
sudo nvme smart-log /dev/nvme0 2>/dev/null || true

SAN/iSCSI/multipath 환경에서는 path 상태도 같이 봅니다.

multipath -ll
iscsiadm -m session
iscsiadm -m session -P 3
journalctl -k --no-pager | egrep -i 'multipath|iscsi|rejecting I/O|path.*down|path.*up' | tail -n 120

NFS 단절과 구분

NFS 장애는 로컬 sda I/O error와 다른 메시지로 보이는 경우가 많습니다.

journalctl -k --no-pager | egrep -i 'nfs: server|not responding|stale file handle|rpc|lockd' | tail -n 120
nfsstat -m
findmnt -t nfs,nfs4

NFS mount가 hang 상태라면 해당 마운트포인트에서 ls, du, find 같은 명령도 멈출 수 있습니다. 자동 점검에서는 반드시 timeout을 사용하세요.

분석 결론 작성 방식

스토리지 단절 보고에는 다음 정보를 남깁니다.

  • 장애 시간대와 최초 커널 로그
  • 문제가 난 디바이스명과 실제 스토리지 식별자
  • 영향 받은 마운트포인트와 파일시스템
  • D 상태 프로세스 목록
  • I/O 지연 지표와 SMART/NVMe/multipath 상태
  • read-only remount 여부

이렇게 정리하면 “디스크 자체 장애”, “스토리지 네트워크 단절”, “NFS 서버 응답 없음”, “파일시스템 오류”, “애플리케이션이 I/O를 과도하게 만든 상황”을 구분할 수 있습니다.

BGM EVER