read(fd, buf, 100) 시스템 콜을 호출하면, 커널은 정말 단순히 '디스크에서 100바이트를 읽어오는' 작업만 수행할까요?

그렇지 않습니다. 파일 접근은 VFS부터 블록 디바이스 계층, 페이지 캐시, 메모리 매핑, Direct I/O, 비동기 I/O에 이르기까지 커널의 주요 시스템이 결합된 거대한 데이터 흐름입니다. 이 장에서 다루는 '파일'의 범주에는 /home/a.txt 같은 일반 파일(Regular File)뿐만 아니라 /dev/sda 같은 블록 디바이스 특수 파일도 포함됩니다. 우리의 출발점은 이미 VFS가 해당 파일의 read나 write 메서드를 호출한 직후입니다.

단순히 write() 콜이 성공을 반환했다고 해서, 갑작스러운 전원 차단 시 데이터 유실이 없다고 장담할 수 없습니다. 데이터의 현재 체류 계층을 정확히 파악하는 것이 파일 I/O 성능 병목 현상과 데이터 내구성(Durability) 이슈를 해결하는 핵심 열쇠입니다.

사용자가 read()를 호출하면 VFS 계층을 거쳐 해당 파일 객체에 매핑된 특정 파일시스템의 read 메서드가 호출됩니다. 디스크 기반 파일시스템 대부분과 블록 디바이스 파일의 읽기 메서드는 공통 인터페이스인 generic_file_read()를 통해 구현됩니다.

이 함수는 우선 두 가지 중요한 I/O 설명자를 준비합니다. iovec은 사용자 버퍼의 베이스 주소와 길이를 명시하는 벡터 구조체로, 복사 대상 목적지를 정의합니다. kiocb는 I/O 작업의 컨텍스트(동기/비동기 여부 등)를 추적하는 제어 블록 구조체입니다. 일반적인 동기 읽기의 경우 init_sync_kiocb 매크로를 통해 초기화됩니다.

준비가 끝나면 코어 함수인 __generic_file_aio_read()를 호출합니다. 명칭에 aio가 포함되어 있으나 동기화 및 비동기 읽기 경로 모두에서 공통으로 사용되는 핵심 함수입니다. 진입 시 가장 먼저 access_ok() 매크로를 실행하여 전달받은 사용자 버퍼 주소가 메모리 보호 구역을 침범하지 않는지 검증합니다. 잘못된 주소 공간 접근 시 시스템 크래시를 방지하기 위해 즉시 -EFAULT 에러를 반환합니다.

do_generic_file_read()는 실질적인 데이터 읽기 로직이 구동되는 심장부입니다. VFS로부터 "특정 파일의 오프셋부터 N바이트를 복사하라"는 요청을 받으면, 이 함수는 우선 메모리의 페이지 캐시를 탐색하고, 캐시 미스 시 디스크 스케줄러에 I/O를 요청하며, 최종적으로 사용자 영역으로 데이터를 복사(Copy-to-User)합니다.

작업 완료 전 mark_page_accessed()가 호출되어 "이 페이지는 활발히 사용 중"이라는 시그널을 LRU(Least Recently Used) 페이지 회수 알고리즘에 전달합니다. 이를 통해 해당 캐시 라인이 조기에 스왑 아웃(Swap out)되거나 삭제되는 것을 방지합니다.

캐시 미스 상황에서 do_generic_file_read()가 위임하는 readpage 콜백은 실질적으로 디스크와 통신하는 레이어입니다. 여기서부터는 파일시스템이 관리하는 일반 파일과 하드웨어를 직접 추상화하는 블록 디바이스 파일의 처리 메커니즘이 확연히 갈라집니다.

일반 파일의 경우, readpage는 마운트된 특정 파일시스템(예: ext4, xfs)의 구현체로 연결됩니다. Ext 계열의 경우 내부적으로 mpage_readpage(page, ext3_get_block) 구조를 따릅니다. 여기서 핵심은 ext3_get_block과 같은 논리-물리 주소 변환 함수입니다. 파일 내부의 논리적인 "N번째 데이터 블록"이 실제 스토리지의 어느 물리적 LBA(Logical Block Address)에 매핑되어 있는지는 해당 파일시스템의 아이노드 구조와 블록 비트맵을 해석해야만 알 수 있기 때문입니다.

반면, 블록 디바이스 파일(`/dev/sda` 등)의 readpage는 파일시스템 계층을 우회합니다. 범용 함수인 blkdev_readpage()가 호출되며, 내부에서는 block_read_full_page(page, blkdev_get_block) 구조를 사용합니다. 블록 디바이스 환경에서는 가상 파일의 오프셋 자체가 장치의 물리적 섹터 위치와 1:1로 직결되므로, 주소 변환을 담당하는 blkdev_get_block의 로직은 거의 항등 함수(Identity Function)에 가깝게 단순합니다.

비동기 I/O 컨트롤러에 의해 디스크 읽기가 완료되면 하드웨어 인터럽트가 발생하고, 완료 콜백인 mpage_end_io_read()가 실행됩니다. 이 함수는 방금 채워진 메모리 페이지의 플래그를 PG_uptodate로 변경하고 페이지 락(Lock)을 해제합니다. 이 신호에 의해 슬립(Sleep) 상태로 대기 중이던 읽기 프로세스의 스케줄링 큐가 깨어나 사용자 복사 로직을 재개하게 됩니다.

비디오 재생이나 대용량 로그 분석처럼 애플리케이션이 파일의 첫 오프셋부터 마지막 오프셋까지 선형적으로 스캔하고 있다면, 운영체제는 다음 번에 요구될 페이지 번호를 높은 확률로 예측할 수 있습니다. 커널은 이 공간적 지역성(Spatial Locality) 패턴을 감지하여 애플리케이션이 요청하기도 전에 디스크에서 미리 데이터를 끌어올리는데, 이 메커니즘이 바로 Read-ahead(미리 읽기)입니다.

기계식 HDD든 현대식 NVMe SSD든, 스토리지 컨트롤러는 작은 블록을 잘게 쪼개서 요청받는 것보다 인접한 대량의 블록을 하나의 명령으로 일괄 처리할 때 훨씬 뛰어난 대역폭을 발휘합니다. 미리 읽혀진 데이터는 페이지 캐시에 대기하다가, 프로세스가 해당 오프셋을 요청하는 즉시 I/O 블로킹 딜레이 없이 0밀리초에 가깝게 반환됩니다. 하지만 무작위 접근(Random Access) 워크로드에서 과도한 Read-ahead는 아까운 I/O 대역폭을 낭비하고 유용한 기존 캐시 페이지를 축출(Eviction)시키는 부작용(Cache Thrashing)을 초래합니다.

순차 접근 패턴의 판별 기준은 매우 명확합니다. 이번에 요청된 파일 오프셋의 첫 번째 페이지가 prev_page에 기록된 직전 접근 페이지 번호와 인접해 있다면 커널은 순차 스캔 상태로 확정합니다. 순차 히트가 연속해서 발생하면 시스템은 확신을 가지고 Ahead window의 프리페치(Prefetch) 사이즈를 기하급수적으로 확장합니다. 반대로 오프셋이 점프하는 랜덤 패턴이 감지되면, 두 윈도우의 상태를 리셋하고 무의미한 Read-ahead 작동을 즉각 정지시킵니다.

읽기 오퍼레이션에서의 성능 핵심이 "목표 페이지가 RAM 캐시에 적재되어 있는가?"였다면, 쓰기 연산에서의 핵심 화두는 "사용자가 전달한 데이터 페이로드가 커널 메모리에 안정적으로 안착되어 더티(Dirty) 상태로 전이되었는가?"로 귀결됩니다.

호출자가 write(fd, buf, count)를 실행할 때, 커널은 사용자 공간의 버퍼 내용을 해당 파일의 논리적 오프셋에 매핑되는 페이지 캐시 영역으로 복사합니다. 이 복사가 완료된 직후 해당 메모리 페이지에는 '더티(Dirty)' 플래그가 세팅됩니다. 더티 상태란 "RAM 상의 캐시 데이터가 수정되어 스토리지에 저장된 원본 데이터와 불일치하며, 향후 반드시 디스크로 동기화(Flush)되어야 하는 휘발성 상태"임을 의미합니다.

Ext4와 같은 주류 디스크 기반 파일시스템은 파일 객체의 쓰기 인터페이스를 generic_file_write() 계열 함수로 추상화합니다. 이 함수의 초기 진입점에서는 대상 파일의 inode 동기화 메커니즘인 i_sem (또는 i_mutex) 뮤텍스를 획득합니다. 만약 다중 프로세스가 동일한 파일에 동시다발적으로 쓰기를 시도할 경우, 논리적 파일 크기 증분 연산, 캐시 트리 구조 변경, 물리 스토리지 블록 할당 로직 등에서 치명적인 Race Condition이 발생할 수 있으므로, 쓰기 경로의 코어 섹션은 철저하게 직렬화(Serialization)되어 보호됩니다.

위와 같은 명시적 동기화 제약이 없는 한, 리눅스의 기본 쓰기 동작인 지연 할당(Delayed Allocation) 및 비동기적 쓰기(Asynchronous Write-behind)가 작동합니다. 이 비동기적 아키텍처 덕분에 I/O 병목이 메모리 대역폭 수준으로 은닉되지만, DB 트랜잭션 로그와 같이 데이터의 원자성(Atomicity)과 내구성(Durability)이 생명인 워크로드에서는 개발자가 fsync(), fdatasync()를 명시적으로 호출하여 메모리 장벽(Memory Barrier)을 세워야만 데이터 유실을 방지할 수 있습니다.

사용자가 제공한 원시 버퍼의 바이트 스트림이 구체적으로 어떤 단계를 거쳐 커널의 캐시 트리 내 '더티 페이지' 구조로 스며드는 것일까요? 코어 루프 함수인 __generic_file_aio_write_nolock()의 치밀한 동작 파이프라인에서 그 해답을 찾을 수 있습니다.

페이지 복사 루프 내에 존재하는 prepare_write 단계는 "스토리지의 물리적 공간을 조달하는 준비 과정"이며, 이어서 실행되는 commit_write는 "메모리 상의 수정 내역이 유효한 더티 상태임을 시스템에 공표하는 확정 과정"입니다.

일반 파일 시스템(예: Ext2/3)에서 prepare_write는 스토리지 아키텍처에 종속적인 래퍼 함수로 라우팅됩니다. 내부의 block_prepare_write(page, from, to, ext2_get_block) 계열 함수는 매우 무거운 임무를 수행합니다. 새로 기록될 데이터가 파일의 기존 크기를 초과하거나 중간의 희소 영역(File Hole)을 덮어쓰게 될 경우, 커널의 블록 할당자(Block Allocator)를 호출하여 가용 디스크 섹터에서 새로운 물리적 블록을 배정받아야 하기 때문입니다.

데이터 복사가 성공적으로 마무리되면 트랜잭션의 마무리를 알리는 commit_write가 호출됩니다. generic_commit_write() 코어 함수는 타겟 범위의 버퍼 헤드들에 BH_Uptodate(최신 데이터 보유)와 BH_Dirty(디스크 동기화 필요) 상태 플래그를 각인합니다. 페이지를 구성하는 모든 하위 버퍼들이 최신 상태가 되면 상위 컨테이너인 페이지 자체에도 PG_uptodate와 PG_dirty 속성이 상속되며, 더 나아가 페이지 캐시의 척추인 Radix Tree(또는 XArray) 노드에 명시적인 더티 태그가 부착됩니다. 이 효율적인 트리 태깅 시스템 덕분에 향후 백그라운드 스레드가 전체 메모리를 뒤지지 않고도 플러시할 더티 페이지들을 O(1)에 가깝게 색인할 수 있습니다.

결과적으로 비동기적 write() 콜이 생성해 낸 무수히 많은 더티 페이지들은 시스템의 어디선가 모여 물리적 스토리지로 기록되어야만 비로소 생명주기를 마감합니다. 이 중대한 책무를 수행하는 백그라운드 엔진이 바로 커널의 Writeback(플러셔 스레드) 경로입니다.

운영체제가 주기적으로, 혹은 메모리 압박에 의해 더티 페이지 축출을 결심하면 특정 파일 구조체의 address_space 객체에 등록된 writepages 메서드를 연쇄적으로 호출합니다. Ext 계열 파일시스템의 경우 내부 구현체인 mpage_writepages(mapping, wbc, ext2_get_block)로 진입합니다. 여기서 전달되는 파라미터 wbc(writeback_control) 구조체는 운영체제의 핵심 I/O 스케줄링 정책을 담고 있으며, 스캔할 페이지 인덱스 범위, 처리할 최대 페이지 할당량, 블로킹(Wait) 모드 여부 등의 전략적 지시를 포함합니다.

전통적인 read(), write() 시스템 콜 인터페이스를 빈번하게 호출하는 대신, 디스크 상의 파일을 운영체제의 페이징 기법을 이용해 프로세스의 가상 주소 공간에 직접 매핑하는 우아한 해법이 존재합니다. 이렇게 되면 개발자는 마치 일반적인 C언어 배열이나 힙(Heap) 메모리를 다루듯 포인터 연산만으로 파일 내용을 수정하고 접근할 수 있으며, 커널과의 컨텍스트 스위칭 비용을 혁신적으로 절감할 수 있습니다. 이 매커니즘이 바로 Memory Mapping (mmap)입니다.

커널에서 특정 프로세스의 메모리 매핑 구역을 표현하는 핵심 자료구조는 vm_area_struct (VMA)입니다. 이 구조체 내의 vm_file 포인터는 매핑의 소스가 되는 파일 객체를 가리키며, vm_pgoff는 원본 파일 내에서 매핑이 시작되는 페이지 오프셋 단위를 명시합니다. vm_start와 vm_end 쌍은 프로세스 가상 공간에 할당된 시작과 끝 주소 경계를 정의합니다.

공유 매핑(Shared)으로 불러들인 페이지 영역은 언제나 파일시스템의 페이지 캐시 생태계 내에 존재합니다. 전용 매핑(Private) 페이지들 또한 최초에는 원본 파일의 페이지 캐시를 가리키며 낭비를 줄이다가, 최초의 데이터 수정 명령이 하달되는 순간 Copy-On-Write 폴트 핸들러에 의해 새로운 익명(Anonymous) 페이지 프레임으로 분리 독립됩니다. 이 시점부터 분리된 복제 페이지는 파일시스템 캐시와 연을 끊고 프로세스의 독립적인 익명 메모리로 관리됩니다.

CPU가 mmap으로 획득한 가상 주소를 역참조하려 할 때, 해당 주소의 페이지 테이블 엔트리(PTE)가 물리 메모리에 매핑되어 있지 않으므로 MMU는 운영체제 커널로 제어권을 넘기는 하드웨어 트랩(Page Fault)을 발생시킵니다. 커널의 범용 폴트 핸들러는 예외 주소가 속한 VMA 영역을 찾아내고, 파일 매핑 구역임을 인지한 뒤 do_no_page() 서브루틴을 거쳐 파일시스템에 특화된 nopage (또는 fault) 콜백 메서드를 기동시킵니다.

가장 범용적인 파일 매핑 폴트 핸들러는 filemap_nopage()입니다. 이 루틴은 먼저 VMA의 vm_file 디스크립터에서 타겟 파일 객체를 식별합니다. 이후 폴트가 발생한 가상 주소와 VMA의 시작 주소(vm_start), 그리고 파일 시작 오프셋(vm_pgoff) 간의 차이를 연산하여 정확히 파일 안의 몇 번째 논리 페이지 블록을 가져와야 하는지 산출해냅니다. 계산된 인덱스를 바탕으로 find_get_page()를 통해 캐시를 조회하고, 부재중이라면 page_cache_read()를 촉발시켜 스토리지 컨트롤러로부터 데이터를 끌어올립니다.

공유 매핑 영역의 데이터를 확실하게 디스크로 영속화하기 위해 프로세스는 msync() 시스템 콜을 호출합니다. 커널 내부의 filemap_sync() 루틴이 가상 주소 공간의 페이지 테이블 엔트리(PTE)들을 순회하면서, 하드웨어 MMU가 세팅한 하드웨어 레벨의 Dirty 비트를 추출해냅니다. 이 비트 정보를 초기화함과 동시에 하드웨어 TLB 캐시를 플러시하고, 커널 페이지 캐시 구조체의 PG_dirty 속성으로 논리적 오염 상태를 격상시킵니다. CPU 아키텍처 수준의 변경 이력을 VFS 파일시스템 수준의 더티 상태로 끌어올리는 이 핵심 과정을 거친 후, MS_SYNC 옵션의 경우 filemap_fdatawrite()와 filemap_fdatawait()를 차례로 호출하여 스토리지 동기화의 종지부를 찍습니다.

PostgreSQL이나 Oracle과 같은 고도화된 데이터베이스 엔진들은 자체적으로 커널보다 훨씬 복잡하고 최적화된 내부 버퍼 풀 메커니즘을 운영합니다. 이러한 애플리케이션에게 범용 운영체제의 페이지 캐시 레이어는 동일한 데이터 블록을 메모리에 두 번 중복 적재하게 만드는 비효율의 원흉이자, CPU가 개입하는 메모리 간 복사(User ↔ Kernel) 낭비를 초래하는 병목 지점입니다. 이러한 성능 저하를 우회하여 하드웨어 스토리지와 유저 메모리 사이에 직접 고속도로를 뚫어주는 아키텍처가 바로 Direct I/O (O_DIRECT)입니다.