LINUX · FILE I/O

컨테이너 파일 I/O: 느린 경로를 계층별로 나누기

같은 파일 경로라도 이름 탐색, 데이터 캐시, copy-up, 가상화 전송 경로가 다르다. 저장장치를 탓하기 전에 어떤 작업이 어디서 기다리는지 구분한다.

먼저 같은 파일·같은 동작인지 확인한다

컨테이너 내부의 경로 문자열만으로 호스트의 파일과 같은 대상을 읽는다고 단정할 수 없다. 대상 프로세스의 마운트 네임스페이스, 루트, 마운트 유형, 런타임과 snapshotter를 먼저 기록한다. 파일 열기, 작은 메타데이터 조회, 순차 읽기, 동기화가 포함된 쓰기는 서로 다른 작업이다.

분기와 관측 지점을 나눈 자체 개념도
  1. 대상 프로세스·마운트: 어느 파일인가

  2. 이름 탐색·메타데이터 또는 데이터 접근: 어떤 작업인가

  3. 계층·백엔드·대기 시간: 어디에 비용이 생겼는가

이름 탐색의 dentry·inode 캐시와 파일 내용의 페이지 캐시는 같은 관측값이 아니다. 파일 수가 많을 때와 큰 파일을 반복 읽을 때를 하나의 캐시 적중률로 설명하지 않는다. 여유 바이트와 사용 가능한 inode 수도 별도로 확인한다.

첫 쓰기와 이미 복사된 파일을 구분한다

OverlayFS의 lower 파일을 쓰기 가능한 형태로 바꾸는 경로에는 upper로 옮기는 copy-up이 개입할 수 있다. 이미 upper에 올라온 파일의 반복 접근과 처음 접근은 조건이 다르다. metacopy가 켜진 메타데이터 변경은 데이터 복사를 미룰 수 있으므로 chmod가 언제나 파일 전체를 복사한다고 단정하지 않는다.

Linux OverlayFS: copy-up과 metacopy

Docker의 classic overlay2 설명을 모든 containerd snapshotter에 그대로 적용하지 않는다. 실제 저장 드라이버와 마운트 옵션이 무엇인지 확인하고, 컨테이너 이미지 계층과 bind mount·volume을 구분한다. 비교할 때 파일 위치가 달라졌다면 그것도 실험 조건의 변경이다.

Docker OverlayFS 저장 드라이버 문서

FUSE·Virtiofs·DAX는 같은 경로가 아니다

Virtiofs는 가상 머신과 호스트 사이의 공유 파일시스템이며 FUSE 프로토콜과 virtqueue 전송을 사용한다. 이것만으로 모든 데이터 접근에 같은 사용자 공간 왕복 비용이 든다고 결론 내릴 수 없다. DAX 사용 여부는 파일과 구성에 따라 달라질 수 있다.

Linux Virtiofs 문서

Linux DAX: 파일별 동작과 Virtiofs 정책

FUSE passthrough는 지원·설정·backing file 연결 조건을 만족한 경로의 별도 기능이다. 이를 일반 FUSE 동작의 기본값으로 쓰거나 모든 연산이 daemon을 우회한다고 설명하지 않는다. 읽기 전용 파일시스템이라는 성질과 무결성 검증 계층의 역할도 구분해야 한다.

Linux FUSE passthrough 문서

설정을 바꾸기 전에 관측표를 채운다

읽기 전용 진단 기록
질문구분할 관측값
같은 대상인가프로세스·네임스페이스·마운트·파일 위치
무엇이 느린가open/stat/read/write/fsync별 지연
처음만 느린가동일 파일의 첫 접근과 반복 접근
자원이 부족한가CPU·메모리 압력·I/O 대기·inode·공간

읽을 권한이 있는 mountinfo와 기존 측정 로그부터 확인한다. 캐시 비우기, 마운트 옵션 변경, 스토리지 드라이버 교체는 비교 조건과 서비스에 영향을 주므로 이 진단의 첫 단계가 아니다. 새 부하 실험이 필요하면 데이터 크기·쓰기량·실행 환경을 별도 합의한다.

출처와 재현 범위

Annand의 컨테이너 파일 I/O 논의를 출발점으로 진단 순서를 독립적으로 구성했다. 특정 런타임의 속도 순위, 성능 개선률, 실제 장애 원인을 재현한 결과가 아니다.

참고 원문: 컨테이너 파일 I/O