CPU는 명령어를 나노초 단위로 처리합니다. 반면, 하드디스크는 데이터를 읽기 위해 물리적으로 헤드를 움직이고 원하는 위치를 찾아가야 하므로 밀리초 단위의 시간이 소모됩니다. 이 장의 핵심은 바로 '디스크가 매우 느리다'는 근본적인 한계에서 출발합니다.

CPU 및 버스의 속도와 디스크 하드웨어의 접근 시간 사이에는 엄청난 간극이 존재합니다. 디스크는 한 번 정확한 위치를 찾으면 빠르게 데이터를 전송할 수 있지만, 탐색 자체에 드는 비용이 막대하므로 이를 보완하기 위한 커널의 I/O 구조 역시 정교하고 복잡해질 수밖에 없습니다. 따라서 커널은 발생한 요청을 즉시 처리하지 않고 잠시 큐(Queue)에 모아둔 뒤, 순서를 재배치하고 병합하여 드라이버에 넘겨줍니다.

이번 학습을 통해 다음 세 가지 핵심 질문에 답할 수 있어야 합니다. 첫째, 사용자의 파일 읽기 요청이 어떻게 디스크의 특정 섹터 요청으로 변환되는가? 둘째, 커널은 왜 요청을 즉시 처리하지 않고 큐에 쌓아두는가? 셋째, 블록 디바이스 드라이버는 정확히 어느 시점에 물리적 하드웨어에 접근하는가?

이 장의 목적은 단순히 "개별 디스크 드라이버 코드를 짜는 법"을 배우는 것이 아닙니다. 리눅스 커널이 드라이버 구현을 쉽게 하도록 제공하는 bio, request, request_queue, gendisk, block_device와 같은 공통 자료구조들이 어떻게 유기적으로 맞물려 돌아가는지 그 생태계를 이해하는 것이 더 중요합니다.

어떤 프로세스가 파일 내부의 데이터를 가져오기 위해 read() 시스템 콜을 호출했다고 가정해 봅시다. 마치 우리가 온라인으로 물건을 주문할 때 단순히 '결제' 버튼만 누르면 되는 것 같지만, 이면에서는 재고 파악, 창고 분류, 배송 경로 최적화, 기사 배정 등 복잡한 물류 시스템이 가동되는 것과 동일한 이치입니다.

섹터, 블록, 페이지, 세그먼트 — 이들은 모두 커널이 다루는 '데이터의 조각'을 뜻하지만, 처리하는 주체에 따라 기준이 다릅니다. 이 용어들의 미묘한 차이를 명확하게 정립해 두어야 이후 I/O 흐름을 이해하기 수월해집니다.

Figure 14-2를 상기해 보면, 동일한 RAM 영역일지라도 계층에 따라 어떻게 해석되는지 잘 알 수 있습니다. 4KB 페이지 하나가 파일시스템 관점에서는 1KB 블록 버퍼 네 개로 나뉘어 보이지만, 그중 뒤쪽 3KB 영역이 단일 세그먼트로 묶여 컨트롤러 관점에서는 512바이트 크기의 섹터 여섯 개로 다뤄지게 됩니다.

대부분의 디스크 I/O 작업은 '디스크상의 인접한 섹터 영역'과 '메모리(RAM)상의 특정 영역' 간의 데이터 교환으로 이루어집니다. 이때 CPU가 일일이 바이트 단위로 데이터를 옮긴다면 막대한 시스템 오버헤드가 발생하므로, 컨트롤러가 메모리에 직접 접근하여 전송을 대신 처리하는 DMA (Direct Memory Access) 기술이 필수적으로 쓰입니다.

여기서 짚고 넘어가야 할 또 다른 중요 개념이 세그먼트 병합(Segment Merging)입니다. 만약 RAM의 특정 페이지 프레임들이 물리적으로 연속되어 있고, 대응하는 디스크의 대상 영역도 인접해 있다면, Generic Block Layer는 잘게 나뉜 세그먼트들을 하나의 더 큰 물리적 세그먼트(physical segment)로 통합해 전송 효율을 극대화합니다.

커널 내부에서 수많은 I/O 요청이 이리저리 이동할 때 단순히 구두로 "이거 읽어줘"라고 지시할 수는 없습니다. 택배 화물에 도착지 주소와 내용물 정보를 명시한 표준 송장이 부착되듯이, 블록 I/O 요청 역시 처리 규격에 맞춘 단일화된 포장지가 필요합니다. 그 핵심 구조체가 바로 bio입니다.

중요한 점은 하나의 bio 요청이 반드시 한 번의 하드웨어 전송으로 곧장 완료되지는 않는다는 것입니다. 전송이 쪼개어 일어날 경우 bi_idx 필드가 다음 전송 타깃을 가리키며 갱신되고, 드라이버는 bio_for_each_segment 같은 매크로를 이용해 남은 세그먼트 조각들을 하나씩 성실하게 처리합니다.

단순한 bio 구조체 하나만으로는 온전한 블록 I/O 처리가 불가능합니다. 시스템에는 여러 디스크가 존재하므로 "이 요청이 정확히 어느 장치로 가야 하는가?", "이 디스크의 주(major) 번호는 무엇인가?", "요청을 쌓아둘 전용 큐는 어디에 있는가?" 같은 전반적인 메타데이터가 필요합니다. 디스크 전체의 거시적 정보를 대변하는 객체가 바로 gendisk입니다.

하나의 통짜 하드디스크는 보통 여러 논리 파티션으로 분할되어 사용됩니다. 통상 디스크 전체와 각 파티션은 같은 major 번호를 공유하되 minor 번호를 연속적으로 할당받아 구분됩니다. hd_struct 구조체 안에는 파티션이 시작되는 절대 섹터 번호(start_sect)와 총 크기(nr_sects), 그리고 통계 수치 등이 포함됩니다.

새로운 물리적 장치가 연결되어 커널이 이를 감지하면, 드라이버는 alloc_disk() 함수를 호출해 gendisk 공간을 확보하고 파티션 배열도 초기화합니다. 모든 세팅이 끝나면 마지막으로 add_disk()를 호출함으로써 비로소 이 장치가 시스템 블록 I/O 생태계에 정식 등록됩니다.

매핑 계층이 "필요한 파일 데이터가 디스크 물리 공간 어디에 존재하는지"를 정확히 계산해 냈다면, 커널은 본격적으로 Generic Block Layer에 해당 작업을 발주해야 합니다. 이 발주 프로세스를 관장하는 중추적인 진입 함수가 바로 generic_make_request()입니다.

커널은 기껏 전달받은 디스크 I/O 요청들을 즉시 하드웨어 컨트롤러로 쏘아 보내지 않는 경우가 허다합니다. 이는 시스템이 처리할 능력이 없어서 밀리는 것이 아니라, 오히려 전체적인 처리량을 극대화하기 위해 다분히 의도적으로 요청들을 대기시키는 것입니다.

자기 디스크(HDD)의 특성상 목표한 섹터로 물리적 헤드를 이동시키는 작업(Seek)은 어마어마한 시간이 소모됩니다. 무작위 순서로 A, Z, B, Y 구역의 요청이 차례로 들어올 때 이를 곧이곧대로 처리하면 헤드가 디스크 전체를 정신없이 왕복해야 합니다. 그러나 잠시 큐에 담아두고 기다리면 커널이 이를 A, B, Y, Z와 같이 물리적으로 가까운 동선 순으로 매끄럽게 재배열할 수 있습니다.

또한 스케줄러는 단순히 순서만 바꾸는 데 그치지 않고, 새로 유입된 요청의 대상 영역이 기존 대기 중인 요청 영역과 연속되어 있다면 두 요청을 아예 커다란 하나의 덩어리로 합쳐(Merge) 버립니다. 이렇게 하면 추가적인 탐색(Seek) 비용 없이 한 번의 큰 전송만으로 여러 개의 요청을 동시에 소화해낼 수 있습니다. 실무 I/O 패턴은 순차적 접근이 주를 이루기 때문에 이 병합 전략은 극적인 성능 향상을 가져옵니다.

I/O 스케줄러가 실제로 어떤 그릇을 가지고 작업을 조율하는지 살펴보겠습니다. 핵심적인 커널 구조체는 두 개입니다. 요청들이 담기는 거대한 통인 request_queue, 그리고 그 큐 안에서 개별 작업 단위를 형성하는 request 디스크립터입니다.

요청 큐는 요술 주머니가 아닙니다. 물리 메모리 기반의 유한한 공간이므로 무한정 I/O 요청을 수용할 수는 없습니다. 시스템에 과부하가 걸려 디스크 I/O 작업이 폭주하면, 새로운 요청을 큐에 삽입하려는 상위 프로세스들은 빈 슬롯을 얻지 못한 채 블록(Block) 상태에 빠지게 됩니다. 커널은 기본적으로 하나의 큐에 대해 Read와 Write 각각 최대 128개까지의 대기열(pending request)을 허용하며, 이 임계치를 초과하면 해당 큐는 포화 상태(full)로 간주되어 더 이상 요청을 받지 않습니다.

또한 큐가 가득 차기 직전까지 가면 커널은 큐가 혼잡(congested) 상태에 진입했다고 판단하여 상위 계층의 페이지 캐시나 VFS 단에서 새로운 I/O 요청의 생성 자체를 조절하도록 간접적인 브레이크 신호를 보냅니다. 통상적으로 대기열이 113개를 넘어서면 혼잡 상태로 표기하고, 다시 111개 이하로 안정화되면 해제 신호를 발생시킵니다.

리눅스 2.6 기반 커널 환경에서는 워크로드 특성에 맞춰 선택할 수 있는 네 가지 종류의 스케줄러(Elevator)를 제공합니다. '엘리베이터'라는 명칭은 디스크 헤드가 마치 건물 승강기처럼 안쪽 트랙과 바깥쪽 트랙을 유연하게 오가며 대기열을 처리하는 모습에서 유래했습니다. 알고리즘마다 공정성을 중시할지, 대기 지연을 중시할지 그 철학이 확연히 다릅니다.

generic_make_request()가 기본적인 문지기 역할을 끝내면, 실제 큐 삽입의 뼈대 로직인 __make_request()가 바통을 넘겨받습니다. 여기서 맞닥뜨리는 핵심 과제는 단순명료합니다. "방금 도착한 이 bio를 새로운 request 트럭에 실을 것인가? 아니면 이미 대기 중인 트럭의 화물칸에 이어서 밀어 넣을 것인가?"

한 가지 특이한 케이스로, BIO_RW_AHEAD 플래그가 찍힌 미래 예측용 '미리 읽기(Read-ahead)' 요청의 경우 시스템 메모리가 넉넉하지 않은 상황이라면 커널은 미련 없이 이를 즉시 포기(Drop)하고 에러 콜백을 반환합니다. 어차피 당장 급한 데이터가 아닌 일종의 보험성 요청이므로 굳이 자원을 무리하게 소모할 필요가 없기 때문입니다.

이상적인 세계라면 하드웨어 컨트롤러가 시스템에 장착된 모든 물리 RAM 공간을 마음껏 들여다보고 데이터를 쏴줄 수 있어야 합니다. 하지만 현실에서는 버스 대역 제한(예: 구형 ISA 버스의 24비트 16MB 한계) 탓에 접근 범위가 지극히 제한된 레거시 하드웨어들이 존재합니다. 커널은 이들을 포기하지 않고 우회로인 바운스 버퍼(Bounce buffer)를 구성해 줍니다.

복제 과정을 거치며 새롭게 탄생한 바운스 bio는 자신이 진짜 원본이 아님을 잊지 않기 위해 BIO_BOUNCED 플래그를 이마에 붙이고, 사후 뒤처리를 위해 bi_private 필드 주머니 속에 몰래 원본 bio의 포인터 주소를 간직한 채 큐를 향해 흘러갑니다.

앞서 배운 gendisk가 '이런 디스크가 시스템에 장착되어 있다'를 선언하는 물리적 신분증이라면, block_device는 '커널 내 어떤 구성요소가 지금 이 블록 장치 영역을 활발하게 다루고 있다'를 추적하기 위한 동적인 논리 상태 객체에 가깝습니다. 이는 통짜 디스크 전체일 수도 있고, 특정 조각난 파티션일 수도 있습니다.

장치를 배타적으로 획득하고자 할 때는 bd_claim()을 호출하여 bd_holder 자리에 이름을 남기고, 볼 일이 끝나면 bd_release()로 소유권을 반납합니다. 계층 구조를 도식화한 Figure 14-3을 되짚어보면, 전체 디스크용 block_device, 개별 파티션용 block_device, 물리적 gendisk, hd_struct 배열들, 그리고 이를 떠받치는 단일 request_queue가 어떻게 하나의 거대한 그물망으로 엮여 있는지 확인할 수 있습니다.

단순한 C 언어 코드가 어엿한 커널의 일원인 '블록 디바이스 드라이버'로 거듭나는 일련의 의식(Initialization) 과정을 따라가 보겠습니다. 이해를 돕기 위해 foo라는 가상의 신규 드라이버를 모델로 삼았습니다. 중요한 것은 각각의 커널 객체들이 어떤 논리적 순서를 밟으며 생성되고 서로 결합되는지 파악하는 것입니다.

Strategy routine (전략 루틴)은 겹겹이 쌓인 소프트웨어 계층의 가장 깊숙한 끝자락에서 대기열의 요청 덩어리(Request)를 뽑아들어 물리적 하드웨어 컨트롤러에 직접 전기적 신호를 세팅하는 핵심 함수입니다. 우리의 가상 드라이버 예시에서는 foo_strategy()가 이 막중한 역할을 맡고 있습니다.

하드웨어 컨트롤러가 고된 DMA 전송 노동을 성공적으로(혹은 실패로) 마치면 마침내 CPU에 전기적 펄스, 즉 인터럽트(Interrupt) 신호를 날립니다. 부름을 받고 튀어나온 드라이버의 인터럽트 핸들러가 해야 할 미션은 명확합니다. "방금 끝난 하드웨어 전송으로 인해, 애당초 거대하게 뭉쳐있던 request 덩어리 중 정확히 '어느 지점'까지 작업이 클리어되었는가?"를 커널 장부에 세밀히 기록하고 다음 타자를 준비시키는 일입니다.

리눅스 환경에서 블록 디바이스를 지칭하는 특수 파일(예: /dev/sda1)이 열리는(Open) 상황은 크게 세 가지입니다. 관리자가 특정 파일시스템을 마운트(Mount)하려 할 때, 가상 메모리 확보를 위해 스왑(Swap) 파티션을 활성화시킬 때, 또는 dd나 디스크 유틸리티 같은 사용자 프로세스가 저수준 제어를 위해 명시적으로 open() 시스템 콜을 던졌을 때입니다. 이 순간 VFS 계층의 dentry_open()은 일반 파일과는 달리 객체의 연산 테이블(f_op)을 블록 장치 전용인 def_blk_fops로 탈바꿈시켜 특수한 처리 경로를 개통합니다.