새벽 2시, 슬랙 알림이 울립니다. "No space left on device — 서비스 쓰기 실패." df -h를 치니 루트 파티션이 100%입니다. du -sh /*로 큰 디렉토리를 찾아가다가 /var/log에 30GB짜리 로그가 쌓여 있습니다. 지웠는데 df -h가 여전히 100%. 알고 보니 삭제한 파일을 nginx 프로세스가 계속 열고 있어서 공간이 실제로 반환되지 않은 것이었습니다. lsof | grep deleted를 치고서야 원인을 찾았습니다.
df → du → lsof, 이 세 명령의 순서가 디스크 장애 진단의 기본입니다.
디스크와 스토리지 관리
- 1물리 디스크 → 파티션 → 파일시스템 → 마운트 포인트의 계층 구조를 설명할 수 있다
- 2df, du, lsblk, lsof로 디스크 사용량을 진단하고 용량 문제를 해결할 수 있다
- 3fdisk와 mkfs로 파티션을 생성하고 파일시스템을 포맷할 수 있다
- 4/etc/fstab으로 마운트를 영구 설정하고 부팅 실패를 예방할 수 있다
- 5inode 고갈과 열린 파일 공간 미반환 문제를 진단하고 해결할 수 있다
lsblk -fdf -hTsudo apt install -y sysstat iotop파티션 조작은 실제 데이터가 없는 별도 디스크에서 수행하세요
Linux 스토리지 계층 구조
확대
서버에 새 디스크를 붙였는데 ls /dev에는 보이는데 파일로 저장할 수가 없고, df -h에도 나타나지 않습니다. 또는 df -h로 보면 공간이 충분한데 파일 쓰기에서 "No space left on device" 에러가 나기도 합니다. 이런 상황에서 원인을 찾으려면 물리 디스크가 파티션, 파일시스템, 마운트 포인트를 거쳐 경로가 되기까지의 계층 구조를 알아야 합니다. 어느 단계가 빠졌는지 파악하면 원인을 빠르게 좁힐 수 있습니다.
리눅스에서 디스크는 추상화 계층을 거쳐 사용자에게 노출됩니다. 물리 하드웨어부터 실제 파일 경로까지 4단계 구조로 이해하면 장애 원인을 빠르게 추적할 수 있습니다.
확대
저장 장치는 다음 4계층으로 추상화됩니다.
- 물리 디스크 (Physical Disk)
- 파티션 (Partition) — 디스크를 논리적으로 분할
- 파일시스템 (Filesystem) — 데이터 저장 구조
- 마운트 포인트 (Mount Point) — 접근 경로
장치 파일 명명 규칙
리눅스는 모든 하드웨어를 /dev/ 디렉토리 아래 파일로 표현합니다.
| 장치 경로 | 설명 |
|---|---|
/dev/sda | 첫 번째 SATA/SAS 디스크 |
/dev/sdb | 두 번째 SATA/SAS 디스크 |
/dev/sda1 | /dev/sda의 첫 번째 파티션 |
/dev/sda2 | /dev/sda의 두 번째 파티션 |
/dev/nvme0n1 | 첫 번째 NVMe SSD |
/dev/nvme0n1p1 | /dev/nvme0n1의 첫 번째 파티션 |
/dev/vda | 가상 머신(KVM/QEMU)의 첫 번째 가상 디스크 |
명명 패턴 읽는 법:
nvme0n1p2에서0은 컨트롤러 번호,n1은 네임스페이스(디스크) 번호,p2는 파티션 번호입니다.
파티션 테이블: MBR vs GPT
디스크를 파티션으로 나누려면 파티션 테이블 형식을 먼저 선택해야 합니다.
| 항목 | MBR (Master Boot Record) | GPT (GUID Partition Table) |
|---|---|---|
| 최대 디스크 크기 | 2TB | 9.4ZB (사실상 무제한) |
| 최대 파티션 수 | 4개 (주 파티션) | 128개 |
| 부트 지원 | BIOS | UEFI (BIOS도 가능) |
| 데이터 이중화 | 없음 | 헤더와 파티션 테이블 이중 저장 |
| 현재 권장 여부 | 레거시 시스템 | 신규 시스템 표준 |
2TB 이상 디스크나 신규 서버에는 반드시 GPT를 사용하세요. 클라우드 환경(AWS, GCP, Azure)의 부팅 볼륨은 대부분 GPT로 포맷되어 있습니다.
파일시스템 종류와 특징
확대
새 디스크를 추가하거나 파티션을 포맷할 때 mkfs.ext4를 쓸지 mkfs.xfs를 쓸지 선택해야 합니다. 대부분의 경우 Ubuntu는 ext4를, RHEL/CentOS는 XFS를 기본으로 씁니다. 파일시스템 종류가 다르면 복구 방법도, 대용량 파일 처리 특성도 달라지기 때문에 나중에 바꾸려면 데이터를 옮기고 포맷을 다시 해야 합니다. 처음 선택이 중요하고, 어떤 상황에 어떤 파일시스템이 맞는지를 알아야 합니다.
파티션 위에 올라가는 파일시스템은 데이터를 어떻게 저장하고 복구할지를 결정합니다. 리눅스 환경에서 주로 만나게 될 세 가지 파일시스템을 비교합니다.
| 항목 | ext4 | XFS | Btrfs |
|---|---|---|---|
| 안정성 | 매우 높음 (오랜 검증) | 높음 | 중간 (계속 개선 중) |
| 최대 파일 크기 | 16TB | 8EB | 16EB |
| 최대 파일시스템 크기 | 1EB | 8EB | 16EB |
| 저널링 | 지원 | 지원 (메타데이터) | 지원 (Copy-on-Write) |
| 스냅샷 | 미지원 | 미지원 (LVM 필요) | 네이티브 지원 |
| 온라인 축소 | 불가 | 불가 | 가능 |
| 주요 사용 사례 | 범용, 부팅 볼륨 | 대용량 파일, 데이터베이스 | 백업 서버, NAS |
| 대표 배포판 | Ubuntu, Debian | RHEL, Rocky Linux | openSUSE |
실무 선택 기준
- 일반 서버 루트 볼륨: ext4 (안정성 우선, 검증된 복구 도구)
- 데이터베이스 서버: XFS (대용량 순차 I/O 성능 우수)
- 백업/스냅샷 서버: Btrfs (스냅샷 기능 활용)
- 클라우드 AWS EC2: 기본값은 ext4, Amazon Linux 2023은 XFS
inode란? 파일시스템은 각 파일에 대한 메타데이터(크기, 권한, 타임스탬프, 위치 등)를 inode에 저장합니다. inode 수는 파일시스템 생성 시 고정되며, inode를 모두 소진하면 디스크 공간이 남아 있어도 파일을 생성할 수 없습니다.
새로 꽂은 디스크가 쓸 수 있는 /data가 되기까지 — 인식부터 fstab까지 5단계
새 디스크를 붙였는데 파일이 안 써지거나, 어제까지 되던 /data가 재부팅 후 텅 비는 일은 모두 "디스크가 경로가 되는 5계단" 중 어디까지 올라갔는지의 문제입니다. 이 순서를 흐름으로 알아 두면 fdisk·mkfs·mount·fstab 중 무엇이 빠졌는지를 단계로 짚을 수 있고, "디스크는 보이는데 왜 못 쓰지"를 추측이 아니라 진단으로 좁힐 수 있습니다.
[새 디스크 연결] (VM에 볼륨 추가 / 클라우드에서 디스크 attach)
│
① 커널이 장치로 인식 → /dev/sdb 등장 (lsblk엔 보이나 MOUNTPOINT 없음)
│
② (선택) 파티션 생성 → /dev/sdb1 (fdisk=MBR·2TB↓ / parted=GPT·2TB↑)
│ 전체를 한 볼륨으로 쓰면 건너뛰고 /dev/sdb 를 그대로 사용
│
③ 파일시스템 생성 mkfs → mkfs.ext4 /dev/sdb1 (빈 파티션에 저장 구조를 씀)
│ 이때 UUID가 부여됨 (blkid로 확인)
│
④ 마운트 mount → mount /dev/sdb1 /data → 이제 /data 로 읽고 씀
│ 단, 이건 임시 — 재부팅하면 사라짐
│
⑤ fstab 등록 (영속화) → UUID=... /data ext4 defaults,nofail 0 2
▼
[재부팅 후에도 자동 마운트되는 /data]
각 단계가 하는 일과, 막히면 나타나는 증상:
| 단계 | 하는 일 | 여기서 막히면 |
|---|---|---|
| ① 장치 인식 | 커널이 디스크를 블록 장치(/dev/sdb)로 노출. lsblk엔 보이지만 아직 MOUNTPOINT 없음 | lsblk에 안 보이면 인식 문제 → 클라우드는 attach 확인, echo 1 > /sys/.../rescan로 재탐지 |
| ② 파티션(선택) | 디스크를 나눠 /dev/sdb1 생성. 2TB 초과·다수 파티션은 GPT(parted·gdisk) 필요 | MBR로 2TB↑ 디스크를 잡으면 약 2TB에서 잘림 → GPT로 다시. 전체를 쓰면 이 단계 생략 |
| ③ 파일시스템 mkfs | 빈 파티션에 ext4·xfs 저장 구조를 만들고 UUID를 부여 | 포맷 안 한 장치를 마운트 → wrong fs type, bad option 에러. 장치 지정 실수는 데이터 파괴 |
| ④ 마운트 | 파일시스템을 디렉터리(/data)에 연결. 그 순간부터 경로로 접근 가능 | 마운트만 하고 fstab 미등록 → 재부팅 시 사라져 앱이 루트 파티션에 씀(용량 사고) |
| ⑤ fstab 등록 | UUID=... /data ...로 부팅 시 자동 마운트 영속화. 장치명 대신 UUID 사용 | 오타·없는 UUID·nofail 누락 → 부팅이 emergency mode로 추락. mount -a로 사전 검증 |
즉 "디스크가 보이는데 왜 못 쓰지"는 이 다섯 계단 중 어디까지 올라갔는지로 갈립니다 — /dev/sdb는 있는데 파일이 안 써지면 ③·④(포맷·마운트)가 빠진 것이고, 어제까지 되던 /data가 재부팅 후 비어 있으면 ⑤(fstab)를 안 한 것입니다. 장치명(/dev/sdb1)은 디스크 추가·순서 변경으로 바뀔 수 있으니 fstab에는 반드시 안정적인 UUID를 씁니다. 새 디스크 문제를 만나면 lsblk -f(장치·파일시스템·마운트가 한 줄에 다 보임) → blkid(UUID) → mount -a(fstab 문법) 순으로 확인하면 어느 계단에서 끊겼는지 바로 좁혀집니다. 여기에 "용량은 남았는데 파일이 안 만들어짐"은 이 계단 밖의 문제 — df -i로 inode 고갈을 따로 확인합니다.
실습: 디스크 상태 진단부터 I/O 분석까지
실습 전 디렉토리와 예제 파일을 먼저 준비합니다.
# 실습 디렉토리 준비
mkdir -p /tmp/linux/part3/exam_1 && cd /tmp/linux/part3/exam_1
# 디스크 실습용 테스트 파일 생성
dd if=/dev/urandom of=/tmp/linux/part3/exam_1/testfile_100m.bin bs=1M count=100 2>/dev/null
echo "테스트 파일 생성 완료: $(du -sh /tmp/linux/part3/exam_1/testfile_100m.bin)"
이제 실습을 진행합니다.
df(disk free)는 현재 마운트된 모든 파일시스템의 용량 정보를 보여줍니다. -h는 사람이 읽기 좋은 단위(GB, MB), -T는 파일시스템 타입을 추가로 출력합니다.
df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p1 ext4 30G 14G 15G 49% /
tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/nvme0n1p3 ext4 100G 67G 28G 71% /var
/dev/sdb1 xfs 500G 312G 188G 63% /data
/dev/sdc1 xfs 2.0T 1.1T 900G 56% /backup
tmpfs tmpfs 3.9G 1.2M 3.9G 1% /run
각 컬럼 읽는 법:
Filesystem: 장치 파일 경로Type: 파일시스템 종류Size: 전체 용량Used: 사용 중인 용량Avail: 실제 사용 가능한 용량 (루트 예약 공간 제외)Use%: 사용률 — 85% 이상이면 즉시 확인 필요Mounted on: 마운트 포인트
# 특정 디렉토리가 어떤 파티션에 속하는지 확인
df -hT /var/log
# tmpfs(메모리 기반 임시 파일시스템) 제외
df -hT --exclude-type=tmpfs
# 사용률 내림차순 정렬 (경보 대응 시 유용)
df -h | sort -rk5 | head -10
df -hT- df -h 출력에서 Use% 컬럼이 각 파티션의 실제 사용률(%)을 보여준다
- df -hT 출력에서 Type 컬럼이 ext4, xfs, tmpfs 등 파일시스템 타입을 표시한다
- tmpfs는 메모리 기반 파일시스템이므로 --exclude-type=tmpfs 시 목록에서 사라진다
- sort -rk5 결과에서 사용률이 높은 파티션이 맨 위에 오는 것을 확인한다
- 읽기 순서: Filesystem(장치) → Use%(사용률) → Avail(여유 공간) → Mounted on(마운트 경로) 순으로 본다
- Use% 85% 이상이면 모니터링 강화 필요 / 95% 이상이면 즉시 정리 — 100%에 도달하면 로그 쓰기 실패로 서비스 장애 발생
- df Use% 낮은데 파일 생성 실패 → df -i 로 inode 사용률 확인 — 작은 파일이 폭발적으로 늘면 바이트 공간은 남아도 inode가 소진된다
- df -i 에서 IUse% 90% 이상이면 inode 고갈 위험 — 이메일 스풀, PHP 세션, 임시 캐시 파일을 점검한다
du(disk usage)는 파일과 디렉토리의 실제 점유 용량을 계산합니다. df로 어떤 파티션이 가득 찼는지 파악했다면, du로 주범을 찾습니다.
du -sh /var/log/* | sort -rh | head -20
4.2G /var/log/journal
1.8G /var/log/nginx
956M /var/log/postgresql
312M /var/log/syslog
189M /var/log/auth.log
87M /var/log/kern.log
45M /var/log/apt
12M /var/log/dpkg.log
8.4M /var/log/faillog
2.1M /var/log/btmp
옵션 설명:
-s: 각 항목의 합계만 출력 (하위 디렉토리 개별 표시 안 함)-h: 사람이 읽기 좋은 단위sort -rh: 용량 기준 내림차순 정렬 (-h는 K/M/G 단위 인식)head -20: 상위 20개만 출력
# 현재 디렉토리 기준으로 하위 1단계만 분석
du -sh /* 2>/dev/null | sort -rh | head -15
# 특정 크기 이상 파일 찾기 (100MB 이상)
find /var -type f -size +100M -exec ls -lh {} \; 2>/dev/null
# 최근 24시간 내 수정된 대용량 파일 추적
find / -type f -size +50M -mtime -1 2>/dev/null | xargs ls -lh
주의:
du -sh /*는 전체 파일시스템을 탐색하므로 대형 서버에서는 시간이 걸릴 수 있습니다. I/O 부하가 높은 운영 서버에서는ionice -c3 du -sh /var/*처럼 I/O 우선순위를 낮춰서 실행하세요.
du -sh /var/log/* | sort -rh | head -20lsblk는 시스템의 모든 블록 디바이스(디스크, 파티션, LVM 볼륨 등)를 트리 형태로 보여줍니다. -f 옵션을 추가하면 파일시스템 타입과 UUID, 마운트 포인트까지 함께 출력됩니다.
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT32 4E21-3A9F 511M 1% /boot/efi
├─nvme0n1p2 ext4 1.0 a3f2c1d8-7b4e-4f91-9c2a-1e8f6b3d5a7c 884M 11% /boot
└─nvme0n1p3 ext4 1.0 b7d4e2f9-3c1a-4b82-8d5f-9e7a2c4b6f1e 15G 47% /
sdb
└─sdb1 xfs data f1a2b3c4-d5e6-7f8a-9b0c-1d2e3f4a5b6c 188G 63% /data
sdc
└─sdc1 xfs backup 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d 900G 55% /backup
트리 구조 읽는 법:
- 최상위 항목(
nvme0n1,sdb)이 물리 디스크 ├─,└─하위 항목이 파티션UUID는 장치 이름 대신/etc/fstab에서 안정적인 식별자로 사용
# 디스크 크기 정보도 함께 출력
lsblk -f -o NAME,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS
# 특정 디바이스만 확인
lsblk -f /dev/sdb
# 파티션 테이블 상세 정보 (루트 권한 필요)
sudo fdisk -l /dev/nvme0n1
fdisk -l 출력 예시:
Disk /dev/nvme0n1: 30 GiB, 32212254720 bytes, 62914560 sectors
Disk model: Amazon Elastic Block Store
Units: sectors of 1 * 512 = 512 bytes
Distor size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 3147775 2097152 1G Linux filesystem
/dev/nvme0n1p3 3147776 62914526 59766751 28.5G Linux filesystem
lsblk -f마운트는 파일시스템을 디렉토리 트리에 연결하는 작업입니다. 수동 마운트는 재부팅 시 사라지므로, 영구 설정은 /etc/fstab에 등록해야 합니다.
# 현재 마운트된 파일시스템 목록 확인
mount | grep -v "^cgroup\|^proc\|^sys\|^tmpfs\|^devtmpfs"
/dev/nvme0n1p3 on / type ext4 (rw,relatime)
/dev/nvme0n1p2 on /boot type ext4 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077)
/dev/sdb1 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8,noquota)
/dev/sdc1 on /backup type xfs (rw,relatime,attr2,inode64,logbufs=8,noquota)
수동 마운트 및 언마운트:
# 마운트 포인트 디렉토리 생성
sudo mkdir -p /mnt/external
# 파일시스템 마운트
sudo mount /dev/sdd1 /mnt/external
# 읽기 전용으로 마운트
sudo mount -o ro /dev/sdd1 /mnt/external
# 언마운트 (사용 중인 프로세스가 있으면 실패)
sudo umount /mnt/external
# 사용 중인 프로세스 확인 후 언마운트
lsof +D /mnt/external
sudo fuser -m /mnt/external
/etc/fstab 영구 마운트 설정:
# fstab 형식: <장치> <마운트포인트> <타입> <옵션> <dump> <fsck>
cat /etc/fstab
# /etc/fstab
UUID=b7d4e2f9-3c1a-4b82-8d5f-9e7a2c4b6f1e / ext4 defaults 0 1
UUID=a3f2c1d8-7b4e-4f91-9c2a-1e8f6b3d5a7c /boot ext4 defaults 0 2
UUID=4E21-3A9F /boot/efi vfat umask=0077 0 1
UUID=f1a2b3c4-d5e6-7f8a-9b0c-1d2e3f4a5b6c /data xfs defaults,nofail 0 2
UUID=9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d /backup xfs defaults,nofail 0 2
fstab 주요 옵션:
| 옵션 | 설명 |
|---|---|
defaults | rw, suid, dev, exec, auto, nouser, async 기본값 묶음 |
nofail | 마운트 실패해도 부팅 계속 진행 (외부 볼륨 필수) |
noatime | 파일 접근 시 atime 갱신 안 함 (I/O 성능 향상) |
ro | 읽기 전용 마운트 |
0 0 | dump 비활성화, fsck 건너뜀 |
0 1 | 루트 파일시스템용 fsck 우선순위 |
0 2 | 루트 이후 fsck 실행 |
# fstab 수정 후 문법 검증 없이 전체 마운트 시도 (재부팅 전 테스트)
sudo mount -a
# UUID 확인 방법
blkid /dev/sdb1
mount / umount + /etc/fstabCPU와 메모리가 여유 있는데 서버가 느리다면 디스크 I/O 병목일 수 있습니다. iostat과 iotop으로 I/O 현황을 실시간으로 파악합니다.
# 1초 간격으로 확장 I/O 통계 출력 (sysstat 패키지 필요)
iostat -x 1
Linux 5.15.0-89-generic 03/26/2026 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
8.25 0.00 3.42 31.67 0.12 56.54
Device r/s w/s rkB/s wkB/s r_await w_await util
nvme0n1 12.40 245.80 156.80 15732.40 0.42 2.18 67.3%
sdb 0.20 189.60 2.60 12134.40 1.20 35.47 98.2%
sdc 0.10 4.20 1.20 268.80 2.10 8.34 3.1%
핵심 지표 읽는 법:
%iowait: CPU가 I/O 대기로 낭비한 비율 — 20% 이상이면 I/O 병목 의심r/s,w/s: 초당 읽기/쓰기 요청 수rkB/s,wkB/s: 초당 읽기/쓰기 처리량 (KB)r_await,w_await: 읽기/쓰기 평균 응답시간 (ms) — HDD 20ms, SSD 1ms 이상이면 과부하util: 장치 사용률 —sdb가 98.2%로 포화 상태
# 프로세스별 I/O 사용량 실시간 모니터링 (루트 권한 필요)
sudo iotop -o -d 2
# -o: I/O를 실제로 사용 중인 프로세스만 표시
# -d 2: 2초 간격 갱신
Total DISK READ: 1.23 M/s | Total DISK WRITE: 14.87 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
8421 be/4 postgres 0.00 B/s 13.45 M/s 0.00% 89.23% postgres: checkpointer
3201 be/4 www-data 892.34 K/s 1.23 M/s 0.00% 8.12% nginx: worker
891 be/4 root 0.00 B/s 198.23 K/s 0.00% 1.34% journald
# iotop 없을 때 대안: /proc/diskstats로 수동 확인
cat /proc/diskstats | awk '{print $3, $6, $10}' | grep -v "^loop\|^ram"
# 특정 장치의 I/O 대기 큐 크기 확인
cat /sys/block/sdb/queue/nr_requests
iostat -x 1 / iotop새 서버나 스토리지 볼륨을 받았을 때, 또는 성능 이슈가 의심될 때 디스크 순차 쓰기 속도를 측정합니다.
# /tmp에 1GB 파일 쓰기 테스트 (bs=1M × count=1000)
dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 conv=fdatasync
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.47218 s, 302 MB/s
옵션 설명:
if=/dev/zero: 입력 소스로/dev/zero(무한 0 바이트 스트림) 사용of=/tmp/testfile: 출력 파일 경로bs=1M: 블록 크기 1MB (큰 블록 = 순차 I/O 시나리오)count=1000: 1000블록 = 1GBconv=fdatasync: 커널 버퍼 캐시를 거치지 않고 디스크에 직접 쓰기 (실제 디스크 속도 측정)
속도 기준값 (참고):
| 스토리지 유형 | 예상 순차 쓰기 속도 |
|---|---|
| AWS EBS gp3 | 125 ~ 1000 MB/s |
| AWS EBS io2 | 256 KB/s ~ 4 GB/s |
| NVMe SSD (로컬) | 1 ~ 7 GB/s |
| SATA SSD | 300 ~ 560 MB/s |
| HDD (SATA) | 80 ~ 200 MB/s |
# 테스트 후 반드시 파일 삭제
rm /tmp/testfile
# 읽기 속도 테스트 (페이지 캐시 비우기 후 측정)
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
dd if=/tmp/testfile of=/dev/null bs=1M
주의: 운영 서버에서
dd테스트 시 대상 경로를 반드시 확인하세요.of=/dev/sdb처럼 장치 파일을 직접 지정하면 해당 디스크 데이터가 영구 삭제됩니다.
dd if=/dev/zero of=/tmp/test bs=1M count=1000트러블슈팅: 현장에서 마주치는 디스크 장애
증상
[Errno 28] No space left on device: '/var/log/app.log'
write error: No space left on device
cp: cannot create regular file '/tmp/backup.tar.gz': No space left on device
원인 진단
1단계: 어떤 파티션이 가득 찼는지 파악
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p3 30G 30G 0 100% /var
2단계: 문제 파티션에서 주범 추적
du -sh /var/* 2>/dev/null | sort -rh | head -15
18G /var/log
7.2G /var/cache
3.1G /var/lib
du -sh /var/log/* 2>/dev/null | sort -rh | head -10
16G /var/log/journal
1.1G /var/log/nginx
450M /var/log/app
3단계: 즉각 대응
# systemd journal 로그 정리 (최근 7일치만 보존)
sudo journalctl --vacuum-time=7d
# 오래된 로그 아카이브 삭제
sudo find /var/log -name "*.gz" -mtime +30 -delete
sudo find /var/log -name "*.log.*" -mtime +14 -delete
# /tmp 정리
sudo find /tmp -type f -mtime +3 -delete
# 코어 덤프 정리
sudo find /var/crash /tmp -name "core.*" -delete
sudo coredumpctl list
sudo rm -rf /var/lib/systemd/coredump/*
4단계: 삭제했는데도 공간이 안 늘어날 때 — 열려있는 삭제 파일
파일을 rm으로 삭제해도, 프로세스가 해당 파일을 열고 있으면 실제 블록은 해제되지 않습니다.
# 삭제됐지만 프로세스가 여전히 열고 있는 파일 찾기
sudo lsof | grep "(deleted)"
nginx 3201 www-data 3w REG 259,3 9663676416 1234567 /var/log/nginx/access.log (deleted)
# 해결: 해당 프로세스 재시작
sudo systemctl restart nginx
# 또는 프로세스를 종료하지 않고 파일 내용만 비우기 (PID와 fd 번호 활용)
> /proc/3201/fd/3
재발 방지
# logrotate 설정 확인
cat /etc/logrotate.d/nginx
# systemd journal 최대 크기 제한
sudo sed -i 's/#SystemMaxUse=/SystemMaxUse=2G/' /etc/systemd/journald.conf
sudo systemctl restart systemd-journald
증상
touch /var/www/newfile.txt
touch: cannot touch '/var/www/newfile.txt': No space left on device
df -h # 여전히 공간 있음
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 500G 245G 255G 49% /var/www # 49%인데 파일 생성 실패?
원인 파악
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/nvme0n1p3 1966080 1966080 0 100% /var
/dev/sdb1 31252480 3421012 27831468 11% /data
/var 파티션의 inode가 100% 소진되었습니다. 디스크 바이트는 남아 있지만 파일을 더 만들 수 없습니다.
주범 찾기
inode를 대량 소비하는 주원인은 작은 파일이 수없이 많은 경우입니다 (이메일 스풀, 캐시, 세션 파일, PHP 세션 등).
# 하위 디렉토리별 파일 수 카운트
for dir in /var/*/; do
count=$(find "$dir" -type f 2>/dev/null | wc -l)
echo "$count $dir"
done | sort -rn | head -15
4821903 /var/spool/postfix/deferred/
342891 /var/cache/php/sessions/
89234 /var/tmp/
해결
# postfix 큐 긴급 정리 (운영 환경 주의)
sudo postsuper -d ALL deferred
# PHP 세션 파일 정리 (30분 이상 된 것)
sudo find /var/cache/php/sessions/ -type f -mmin +30 -delete
# 처리 후 inode 확인
df -i /var
재발 방지
파일시스템 생성 시 inode 밀도를 높여 소파일 과다 저장 환경에 대비합니다. bytes-per-inode 값을 낮추면 inode 수가 늘어납니다. 단, 포맷 명령이므로 대상 장치를 반드시 확인하세요.
파일시스템 포맷 — 장치 내 기존 데이터 영구 삭제
안전한 실행 조건: lsblk로 대상 장치가 데이터 없는 추가 디스크임을 확인하고, umount로 마운트 해제 후 실행
실행 전 반드시 확인
- lsblk -f 로 /dev/sdd1 이 실습용 빈 파티션인지 확인 (FSTYPE 컬럼이 비어있어야 함)
- df -h 로 해당 장치가 현재 마운트되어 있지 않은지 확인
- umount /dev/sdd1 으로 마운트 해제 후 실행
mkfs.ext4 -i 4096 /dev/sdd1위 항목을 모두 확인한 후 복사할 수 있습니다
증상
/etc/fstab을 수정하고 재부팅했더니 서버가 응급 복구 모드로 진입합니다.
[ *** ] A start job is running for /data (2min 30s / no limit)
[FAILED] Failed to mount /data.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance (or press Control-D to continue):
원인 유형
- 존재하지 않는 UUID 입력
- 마운트 포인트 디렉토리 미생성
- 잘못된 파일시스템 타입 지정
nofail옵션 누락으로 선택적 볼륨 실패가 부팅 중단 유발
복구 절차
# 1. emergency mode에서 root 암호 입력 후 로그인
# 2. 루트 파일시스템을 읽기-쓰기로 재마운트
mount -o remount,rw /
# 3. fstab 편집
nano /etc/fstab
# 문제가 된 라인 주석 처리 또는 수정
# 4. 구문 검증
mount -a --fake # 실제 마운트 없이 fstab 구문 검사
# 5. 재부팅
reboot
올바른 fstab 작성 패턴
# 클라우드/외부 볼륨에는 반드시 nofail 추가
UUID=f1a2b3c4-d5e6-7f8a-9b0c-1d2e3f4a5b6c /data xfs defaults,nofail 0 2
# fstab 수정 후 재부팅 전 반드시 테스트
sudo mount -a # 오류 없으면 안전
예방 습관: fstab 수정 후
sudo mount -a로 반드시 테스트합니다. 클라우드 환경에서 데이터 볼륨에는 반드시nofail을 추가하세요. AWS EC2에서 EBS가 연결되기 전에 인스턴스가 부팅을 시도할 수 있습니다.
심화 — 파일시스템이 비웠다고 장치가 비운 건 아니다
심화: 삭제와 반환 사이의 계층 — TRIM/discard
df와 du가 안 맞는 고전적 원인은 '열린 삭제 파일'이지만, 그것만 알고 있으면 놓치는 더 아래 계층이 있습니다. 파일을 지웠을 때 공간이 '파일시스템에서 free가 되는 것'과 '하부 블록 장치가 그 블록을 실제로 회수하는 것'은 별개의 사건입니다. 이 구분을 모르면 SSD·씬 프로비저닝·클라우드 볼륨에서 "안에서는 지웠는데 밖에서는 안 줄어드는" 상황에 당황하게 됩니다.
- 삭제는 파일시스템 계층에서 끝납니다.
rm은 해당 블록을 파일시스템의 여유 목록에 되돌려 놓을 뿐, 하부 블록 장치(SSD 컨트롤러, 씬 프로비저닝 SAN, LVM thin-pool, qcow2 이미지, 클라우드 EBS)에게 "이 블록 이제 안 써"라고 알리지 않습니다. - 그래서 하부 장치는 한 번 쓰인 블록을 계속 '사용 중'으로 봅니다. 결과는 두 가지입니다. (1) SSD는 실제로 비어 있는 블록을 모르니 가비지 컬렉션 대상에서 빼지 못해, 시간이 지날수록 write amplification이 늘고 쓰기 성능이 떨어집니다. (2) 씬 프로비저닝·이미지·스냅샷은 게스트가 이미 지운 데이터까지 최대 사용량 기준으로 계속 차지해, 호스트 용량과 비용이 부풀고 스냅샷이 비대해집니다.
- 해결은 discard(TRIM)로 하부에 알리는 것입니다. 주기적으로
sudo fstrim -av를 돌려 미사용 블록을 하부 장치에 통보하면, SSD는 회수하고 씬풀·이미지는 공간을 되돌립니다. 대부분의 배포판은fstrim.timer(주 1회)를 제공하니systemctl enable --now fstrim.timer한 줄이면 자동화됩니다. - 상시 discard도 있지만 기본값은 아닙니다. 마운트 옵션
-o discard는 파일을 지울 때마다 즉시 TRIM을 보내지만, 삭제마다 오버헤드가 생겨 현대 관행은 상시 discard보다 주기적fstrim.timer를 선호합니다. 단, 하부 스토리지가 discard를 볼륨까지 전달하도록 구성돼 있어야 효과가 납니다(예: qemudiscard=unmap, LVMissue_discards).lsblk -D의 DISC-GRAN·DISC-MAX가 0이 아니면 discard를 지원한다는 뜻입니다.
정리하면, '열린 삭제 파일'은 fd 계층의 문제(프로세스가 잡고 있음)이고, TRIM은 블록 계층의 문제(하부 장치가 아직 모름)입니다. 둘은 증상이 비슷해 보여도 진단·처방이 완전히 다릅니다.
상황: 가상 머신(또는 씬 프로비저닝 볼륨) 안에서 대량의 로그·임시 파일을 만들었다가 지웠습니다. 게스트의 df는 40%로 정상으로 돌아왔는데, 호스트에서 본 qcow2 이미지 파일(또는 thin-pool 사용량)은 한때의 최대치까지 부풀어 그대로 유지됩니다. 이 상태가 반복되면 호스트 디스크가 위험해집니다.
원인: 게스트에서의 파일 삭제는 게스트 파일시스템 안에서만 블록을 free로 표시했을 뿐입니다. 하부 블록 장치(qcow2·thin-pool)는 게스트가 discard(TRIM)를 명시적으로 보내지 않는 한 그 블록이 비었다는 것을 모르므로, 한 번 쓰인 블록을 계속 사용 중으로 잡아 이미지가 최대 사용량 기준으로 남습니다. 프로세스가 fd로 파일을 붙잡고 있는 deleted-but-open 문제와는 다른, 한 계층 아래의 현상입니다.
진단: 게스트 df는 정상인데 호스트 측 이미지·씬풀 사용량이 줄지 않으면 이 문제로 강하게 의심합니다. 게스트에서 lsblk -D로 DISC-GRAN·DISC-MAX가 0이 아닌지(=discard 지원) 확인하고, 마운트 옵션에 discard도 없고 fstrim도 최근 돌지 않았는지 봅니다. lsof | grep deleted로 열린 삭제 파일이 없음을 확인하면 fd 계층 원인은 배제됩니다.
해결: 게스트에서 sudo fstrim -av를 실행해 미사용 블록을 하부 장치에 반환합니다 — qcow2·thin-pool이 공간을 회수합니다. 재발 방지로 sudo systemctl enable --now fstrim.timer(주간 자동 실행)를 켭니다. 이 반환이 실제로 먹히려면 하부 스토리지가 discard를 볼륨까지 전달하도록 구성돼 있어야 합니다(qemu discard=unmap, LVM issue_discards=1 등). 상시 -o discard 마운트도 가능하지만 삭제마다 오버헤드가 있어, 주기적 fstrim이 표준 처방입니다.
실무 시나리오
새벽 2시, 모니터링 시스템이 운영 서버 /var 파티션 90% 사용률 알람을 발송했습니다. 서비스는 아직 정상이지만 계속 증가하면 수 시간 내에 장애가 발생합니다.
표준 진단 플로우
# Step 1: 전체 파티션 상태 파악
df -hT
# → /var 파티션이 90%
# Step 2: /var 내 주요 디렉토리 용량 분석
sudo du -sh /var/* 2>/dev/null | sort -rh | head -10
# → /var/log 가 가장 크다고 가정
# Step 3: 로그 디렉토리 드릴다운
sudo du -sh /var/log/* 2>/dev/null | sort -rh | head -10
# → /var/log/app/access.log 가 30GB로 비정상 크기
# Step 4: 삭제됐는데 공간이 안 줄어드는지 확인
sudo lsof | grep "(deleted)" | awk '{print $1, $2, $7, $NF}' | sort -k3 -rn | head -10
# → 앱 프로세스가 삭제된 파일을 여전히 열고 있는지 확인
# Step 5: 실시간 쓰기 중인 프로세스 특정
sudo iotop -o -d 1
# Step 6: 로그 로테이션 강제 실행
sudo logrotate -f /etc/logrotate.d/myapp
# Step 7: 서비스 재시작으로 파일 핸들 해제
sudo systemctl restart myapp
# Step 8: 공간 회복 확인
df -h /var
임시 방편이 아닌 근본 해결
# 로그 레벨 확인 (DEBUG 레벨이면 INFO로 낮추기)
grep -i "log.level\|LOG_LEVEL" /etc/myapp/config.yaml
# logrotate 주기와 보존 정책 검토
cat /etc/logrotate.d/myapp
# rotate 7 → 더 짧게, daily → 더 자주
# 로그 볼륨을 별도 파티션으로 분리 검토 (장기 대책)
새로운 EC2 인스턴스를 시작할 때 /data 볼륨(EBS)이 서비스 시작 전에 반드시 마운트되어 있어야 합니다. 잘못된 순서로 서비스가 먼저 시작되면 /data에 쓰려던 파일이 루트 파티션에 쌓이고, EBS가 나중에 마운트되면 해당 마운트 포인트가 가려집니다.
문제 상황
# 서비스 시작 후 EBS가 마운트된 경우 발생하는 문제
ls /data/ # EBS 마운트 전 루트에 쌓인 파일들이 보임
umount /data # EBS 언마운트
ls /data/ # 루트에 쌓인 쓰레기 파일 노출
systemd 의존성으로 마운트 보장
# /etc/systemd/system/data.mount 생성 (파일명이 마운트 경로와 일치해야 함)
sudo tee /etc/systemd/system/data.mount << 'EOF'
[Unit]
Description=Data Volume Mount
After=local-fs.target
[Mount]
What=/dev/disk/by-uuid/f1a2b3c4-d5e6-7f8a-9b0c-1d2e3f4a5b6c
Where=/data
Type=xfs
Options=defaults,nofail
[Install]
WantedBy=multi-user.target
EOF
# 서비스에서 마운트 의존성 선언
sudo tee /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Application
After=network.target data.mount
Requires=data.mount
[Service]
ExecStart=/usr/bin/myapp
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable data.mount myapp
스크립트 방식 마운트 검증 (부트스트랩)
EC2 User Data나 Ansible로 프로비저닝할 때 사용할 수 있는 패턴입니다.
#!/bin/bash
# /usr/local/bin/ensure-data-mount.sh
MOUNT_POINT="/data"
DEVICE_UUID="f1a2b3c4-d5e6-7f8a-9b0c-1d2e3f4a5b6c"
MAX_WAIT=60
WAITED=0
echo "Waiting for data volume to be available..."
while ! blkid | grep -q "$DEVICE_UUID"; do
if [ $WAITED -ge $MAX_WAIT ]; then
echo "ERROR: Data volume not found after ${MAX_WAIT}s. Aborting."
exit 1
fi
sleep 2
WAITED=$((WAITED + 2))
echo " Still waiting... (${WAITED}s)"
done
echo "Device found. Mounting to ${MOUNT_POINT}..."
mkdir -p "$MOUNT_POINT"
mount UUID="$DEVICE_UUID" "$MOUNT_POINT"
if mountpoint -q "$MOUNT_POINT"; then
echo "Mount successful: $(df -h $MOUNT_POINT | tail -1)"
else
echo "ERROR: Mount failed."
exit 1
fi
chmod +x /usr/local/bin/ensure-data-mount.sh
# ExecStartPre에 등록하여 서비스 시작 전 실행 보장
명령어·단축키 빠른 참조
이 모듈에서 다룬 디스크·스토리지 진단 명령을 실전 옵션과 함께 모았습니다. df → du → lsof 순서가 디스크 풀 장애 진단의 기본입니다.
| 명령어/단축키 | 용도 | 자주 쓰는 예 |
|---|---|---|
df -hT / df -i | 용량·inode 사용률 확인 | df -h | sort -rk5, df -i(inode 고갈 확인) |
du -sh | 디렉토리별 실제 용량 | du -sh /var/log/* | sort -rh | head |
lsblk -f | 블록 장치·파티션 트리 | FSTYPE·UUID·마운트 한눈에 |
fdisk -l | 파티션 테이블 상세 | sudo fdisk -l /dev/nvme0n1 |
mount / umount | 파일시스템 연결·해제 | sudo mount -o ro /dev/sdd1 /mnt |
/etc/fstab + mount -a | 영구 마운트·문법 검증 | sudo mount -a(재부팅 전 테스트), nofail 필수 |
blkid | 장치 UUID 확인 | blkid /dev/sdb1 |
iostat -x | 디스크 I/O 통계 | iostat -x 1(%iowait·util·await 확인) |
iotop | 프로세스별 I/O 실시간 | sudo iotop -o -d 2 |
lsof | grep deleted | 삭제됐지만 열린 파일 추적 | sudo lsof | grep "(deleted)" |
find -size | 대용량 파일 찾기 | find /var -type f -size +100M 2>/dev/null |
dd | 디스크 쓰기 속도 측정 | dd if=/dev/zero of=/tmp/t bs=1M count=1000 conv=fdatasync |
mkfs.ext4 / mkfs.xfs | 파일시스템 포맷(주의) | mkfs.ext4 -i 4096 /dev/sdd1(inode 밀도↑) |
fstrim -av | 미사용 블록 하부 반환(TRIM) | sudo fstrim -av, fstrim.timer로 주기화 |
관련 모듈로 더 깊이:
- Read-only 파일시스템 에러 진단과 디스크 IO 성능 병목 잡기 — 디스크가 가득 찼는데
du로 안 잡힐 때(고스트 파일·inode 고갈) 추적하는 법 - LVM과 볼륨 관리 기본 개념 및 실습 — 파티션 크기를 무중단으로 늘리고 줄이는 논리 볼륨 관리
- 절대/상대 경로와 리눅스 디렉터리 구조 마스터 — 마운트된 파일시스템 안에서 경로를 다루는 기초 감각
다음 모듈에서는 LVM(Logical Volume Manager) — 파티션 크기를 유연하게 조정하는 논리 볼륨 관리를 다룹니다.