먼저 장치 읽기가 필요한지 봅니다
블록 장치 위 일반 파일의 buffered read를 기준으로 봅니다. 요청한 바이트가 유효한 페이지 캐시에 있으면 그 바이트를 얻기 위한 저장장치 읽기는 필요하지 않습니다. 별도의 readahead는 이어질 수 있습니다. 캐시에 없거나 아직 유효하지 않은 folio는 파일시스템의 read_folio·readahead 경로에서 채워질 수 있습니다.
O_DIRECT, 파일의 hole, 네트워크 파일시스템을 이 단일 흐름에 넣지 않습니다. 캐시 miss 하나가 곧 NVMe 명령 하나라는 대응도 성립하지 않습니다.
커널의 요청 큐와 NVMe 큐를 구분합니다
파일시스템이 만든 bio는 블록 계층의 request로 묶이거나 나뉠 수 있습니다. 합치기는 요청 특성·장치 한도·스케줄러 조건에 달려 있습니다. blk-mq의 소프트웨어 큐와 하드웨어 디스패치 큐는 NVMe Submission Queue 자체가 아닙니다.
유효한 캐시 hit → 요청 바이트를 캐시에서 반환
장치 읽기 필요 → 파일시스템·bio·request·드라이버
NVMe 명령 → 완료 상태 처리 → 상위 읽기 경로에 결과 전달
이 개념도는 객체마다 하나씩 직선 대응한다는 뜻이 아닙니다. 조사할 때는 파일 offset·길이, bio와 request의 관계, 큐·명령 식별자를 각 계층의 증거로 연결해야 합니다.
DMA 주소를 CPU 포인터로 읽지 않습니다
CPU의 가상 주소, 물리 주소, 장치에 제공하는 DMA 주소는 구분해야 합니다. IOMMU가 있으면 주소 변환이 개입할 수 있지만 모든 시스템이 같은 구성을 쓰지는 않습니다. DMA API의 매핑·방향·동기화 계약을 따라야 하며 CPU 포인터를 그대로 장치 주소로 간주하면 안 됩니다.
완료 항목과 성공을 구분합니다
NVMe over PCIe에서는 호스트가 SQ에 명령을 놓고 tail doorbell로 알립니다. 컨트롤러는 CQ에 결과를 남기며, 호스트는 오류 상태까지 처리한 뒤 CQ head를 알립니다. 명령 완료 순서는 제출 순서와 다를 수 있습니다.
MSI-X는 흔한 선택이지 필수 단일 경로가 아닙니다. 인터럽트가 설정되지 않을 수도 있고 coalescing으로 여러 완료를 함께 알릴 수도 있습니다. 완료마다 인터럽트 하나 또는 특정 CPU 하나가 반드시 대응한다고 쓰지 않습니다.
호스트에서 관찰한 것까지만 말합니다
애플리케이션 반환 시간, 블록 계층의 제출·완료, NVMe 명령 상태는 각각 측정 범위가 다릅니다. 이 기록만으로 SSD 내부의 NAND 읽기, FTL 처리, wear leveling이 어떤 순서로 실행됐는지 확정할 수 없습니다. 장치 초기화와 Admin Queue 생성은 I/O 데이터 경로에 앞선 별도 주제입니다.
이 글은 공식 문서와 기존 커널 글을 대조한 조건부 설명입니다. 실제 SSD 추적이나 성능 측정은 하지 않았으며, 출처 이미지의 작은 글자와 내부 동작까지 독립적으로 검증한 것도 아닙니다.