ext4 저널링 모드, data=ordered·writeback·journal을 운영 조건으로 고르는 법
AI를 활용하여 생성한 이미지입니다.
ext4에서 저널링은 파일시스템이 갑자기 꺼졌을 때 메타데이터가 중간 상태로 남지 않도록 돕는 장치예요. 다만 “저널링을 켰다”로 끝나지 않습니다. 파일 데이터까지 저널에 기록할지, 메타데이터만 먼저 보호할지에 따라 복구 때 보이는 결과와 쓰기 비용이 달라져요.[1][2]
세 모드는 무엇이 다를까?
| 모드 | 기록 순서 | 어울리는 조건 | 감수할 점 |
|---|---|---|---|
data=ordered |
파일 데이터를 본래 위치에 먼저 밀어 넣은 뒤 메타데이터를 커밋해요. | 일반 서버와 데스크톱의 기본값 | 파일 데이터 전체를 저널에 복사하지는 않아요. |
data=writeback |
데이터와 메타데이터의 기록 순서를 보장하지 않아요. | 성능을 우선하고 애플리케이션이 자체 무결성을 관리하는 경우 | 장애 뒤 오래된 데이터가 파일에 보일 수 있어요. |
data=journal |
파일 데이터와 메타데이터를 모두 저널에 커밋한 뒤 본래 위치에 써요. | 파일 내용의 일관성이 특히 중요한 좁은 구간 | 쓰기량과 지연이 커질 수 있어요. |
Linux Kernel 문서는 ext4의 기본 data=ordered가 메타데이터를 저널에 기록하지만 파일 데이터 블록까지 일관성을 보장하는 방식은 아니라고 설명해요. data=journal은 더 안전한 대신 느리고, data=writeback은 기록 순서를 유지하지 않아 장애 뒤 오래된 데이터가 나타날 수 있습니다.[1] 여기서 “파일시스템이 마운트된다”와 “애플리케이션 데이터가 최신이다”를 같은 뜻으로 보면 안 돼요.
장애 복구에서 확인할 순서
- 먼저 읽기 전용으로 파일시스템 상태와 현재 마운트 옵션을 확인합니다.
findmnt -no SOURCE,FSTYPE,OPTIONS /data처럼 대상 장치를 확인하고, 운영 중인 루트 파일시스템에는 바로 재마운트를 시도하지 마세요. - 최근 비정상 종료가 있었는지, 애플리케이션이 파일을 임시 파일에 쓴 뒤 rename하는 방식인지 확인합니다. 저널은 파일시스템 구조를 보호하지만 애플리케이션의 마지막 저장 시점까지 복원해 주지는 않아요.
- 부팅 후 로그에서 저널 replay, I/O 오류, 장치 리셋을 분리해 봅니다. replay 자체는 비정상이라기보다 이전 커밋 기록을 적용하는 과정일 수 있고, 같은 장치 오류가 반복되는지가 더 중요해요.
- 백업 사본을 확보한 뒤에만 모드 변경을 검토합니다. 모드 변경은 장애의 원인을 고치는 작업이 아니라 기록 정책을 바꾸는 작업이에요.
writeback을 성능 옵션처럼 쓰면 안 되는 이유
data=writeback은 가장 빠른 모드라는 식으로 단순 비교하기 어렵습니다. 저장장치, 지연 할당, 애플리케이션의 fsync 사용, 백업 방식이 함께 결과를 바꿔요. 파일시스템 내부의 구조적 일관성이 유지되더라도, 충돌 직전의 새 파일 내용 대신 이전 내용이나 빈 내용이 보일 수 있다는 한계가 있습니다.[2]
데이터베이스나 큐처럼 “마지막 커밋 이후의 값”이 중요한 서비스라면 먼저 애플리케이션의 내구성 설계를 확인하세요. ext4 모드만 바꿔서 데이터베이스의 트랜잭션 보장을 대신할 수는 없습니다. 반대로 임시 캐시나 다시 만들 수 있는 빌드 산출물이라면 data=journal을 적용할 이유가 약해요.
운영 중 바꾸기 전에 보는 항목
- 해당 경로가 루트·부팅·데이터베이스·캐시 중 어디에 속하는지 구분하기
- 현재 옵션과 파일시스템 유형을
findmnt와tune2fs -l로 읽기 전용 확인하기 - 백업 복구 테스트에서 파일 내용과 메타데이터를 각각 비교하기
- 서비스가
fsync와 원자적 rename을 어떻게 사용하는지 확인하기 - 변경 뒤 성능보다 장애 복구 결과를 먼저 검증하기
로그가 너무 커져 디스크를 압박하는 문제는 저널과 별개로 systemd journal 보존 정책을 봐야 해요. ext4의 파일시스템 저널을 지우는 방식으로 애플리케이션 로그 문제를 해결하려 하지 말고, journalctl 로그 용량과 보존 기간을 점검하는 글에서 구분해 확인하세요.
모드 변경을 보류해야 하는 경우
루트 파일시스템이나 복구 도구가 없는 원격 서버에서 즉시 마운트 옵션을 바꾸는 것은 피하세요. 잘못된 옵션으로 부팅이 멈추면 설정을 되돌릴 콘솔 접근이 필요해요. 먼저 동일한 커널과 파일시스템을 가진 별도 환경에서 백업을 복원하고, 비정상 종료를 재현한 뒤 파일 내용과 애플리케이션 로그를 비교하는 편이 안전합니다.
또한 SSD 수명, 전원 보호, RAID 컨트롤러 캐시처럼 저장장치 아래 계층의 문제도 따로 봐야 합니다. 저널 모드는 전원 장애를 완전히 대신하는 기능이 아니고, 디스크가 기록 완료를 거짓으로 응답하거나 데이터가 손상된 경우까지 복구해 주지 않아요. 중요한 데이터라면 모드 선택과 별개로 백업 복원 시간을 측정하고 정기적으로 실제 복구를 연습해야 합니다.
실제 적용을 결정할 때는 “가장 안전한 모드”보다 서비스가 잃어도 되는 데이터와 복구 시간부터 적어 보세요. 새 모드의 성능이 좋아 보여도 장애 뒤 수동 복구가 길어지면 전체 운영 비용이 커질 수 있습니다. 적용 전·후에 같은 파일 복사 작업, 동시 쓰기, 강제 재부팅 테스트를 기록하면 감으로 옵션을 고르는 일을 줄일 수 있어요.
