ext4의 data=ordered에서 metadata journal commit 전에 file data flush가 선행된다고 합니다. crash 뒤 파일 내용 일관성과 metadata 일관성을 어떻게 구분하나요?

data=ordered를 설명할 때는 metadata consistency와 file-data 최신성을 분리해야 합니다. ext4/JBD2에서 관련 dirty file data를 metadata journal commit보다 앞서 flush하도록 순서를 연결하는 모드이지, 여러 파일의 논리 transaction을 DB처럼 원자 commit하는 모드는 아닙니다. 설명용으로 새 inode N, data block D, directory entry x를 만들고 hello 5바이트를 쓴다고 하겠습니다. D만 dirty인 첫 시점, N·size=5·x가 metadata transaction에 들어간 둘째 시점, data flush와 valid commit record가 끝난 셋째 시점을 나눕니다. 첫째나 둘째에서 전원이 꺼지면 commit 유효성에 따라 x와 N이 replay 대상이 아닐 수 있고, 셋째 이후 장애라면 replay가 directory와 inode 구조를 복구할 수 있습니다. 그래도 “사용자가 쓴 최신 bytes 전체가 보존됐다”는 뜻은 아닙니다. 이미 존재하는 block overwrite, 장치 내부 write cache의 전원 보호, 여러 파일에 걸친 application invariant는 ordered mode 밖의 조건입니다. write() 반환도 장치 전원 장애 후 보존과 같지 않으므로 필요한 내구 경계에 fsync와 storage flush 계약을 맞춰야 합니다. replay 성공은 valid metadata transaction을 적용했다는 증거이지 DB WAL commit이나 애플리케이션 checksum 통과의 증거가 아닙니다. 따라서 복구 후 파일 포맷의 checksum·generation을 별도 확인합니다. 이 설명은 ext4/JBD2 문서 범위이며 다른 filesystem의 “ordered”라는 이름에 그대로 일반화하지 않습니다.