UNIX 파일 입출력과 파일 디스크립터

파일 디스크립터란

UNIX는 일반 파일뿐 아니라 디렉터리, 터미널, 파이프, 소켓, 장치까지 파일이라는 하나의 인터페이스로 다룬다. 프로세스가 이런 대상을 열면 커널은 파일 디스크립터(file descriptor, fd) 라는 작은 음이 아닌 정수를 돌려준다. 이후 읽기·쓰기·닫기는 모두 이 정수로 한다.

• 새로 연 fd는 비어 있는 가장 작은 번호를 받는다.
• 셸이 프로그램을 실행할 때 0(표준 입력, 키보드)·1(표준 출력, 화면)·2(표준 오류, 화면)를 터미널에 연결해 미리 열어 둔다. 코드에서는 STDIN_FILENO·STDOUT_FILENO·STDERR_FILENO 상수를 쓴다.
• 프로세스당 열 수 있는 개수에는 한도가 있다(ulimit -n, RLIMIT_NOFILE).

커널의 세 테이블

fd는 커널 자료구조를 가리키는 인덱스일 뿐이다. 실제 상태는 세 단계 테이블에 나뉘어 있다.

flowchart LR
  subgraph pa["프로세스 A (PCB) · fd 테이블"]
    a0["0"]
    a1["1"]
    a3["3"]
  end
  subgraph pb["프로세스 B"]
    b3["3"]
  end
  subgraph kern["커널 전역 · 열린 파일 테이블"]
    oft["플래그(O_RDONLY…)<br/>오프셋, refcnt"]
  end
  subgraph perfile["파일마다 하나 · v-node / i-node"]
    vn["소유자·권한<br/>크기·블록 위치"]
  end
  a0 --> oft
  a1 --> oft
  a3 --> oft
  b3 -->|"fork·dup이면 같은 항목을 공유"| oft
  oft --> vn

v-node는 여러 파일 시스템(로컬 디스크, NFS 등)을 한 인터페이스로 다루려고 i-node에서 파일 시스템 독립적인 부분을 떼어 낸 것이다. Linux는 v-node 대신 VFS의 inode 객체로 같은 역할을 한다. 디스크 위 i-node 구조는 파일 시스템 구현에서 다룬다.

• 오프셋이 열린 파일 항목에 있으므로 fork()한 부모·자식, dup()으로 복제한 fd는 같은 열린 파일 항목을 가리킨다. 오프셋을 공유하므로 한쪽의 read·lseek가 다른 쪽에 영향을 준다. 항목은 refcnt가 0이 될 때 사라진다.
• 같은 파일을 open()을 두 번 하면 항목이 두 개 생겨 오프셋이 독립적이다.

기본 시스템 콜

실패하면 -1을 반환하고 errno에 원인을 남긴다.

read의 반환값

read는 요청한 만큼 읽는다는 보장이 없다. 반환값으로 상황을 가른다.

블로킹 모드에서 데이터가 아직 없으면(빈 파이프, 입력을 기다리는 터미널) read는 0이 아니라 잠든다. "데이터 없음"과 "끝"은 다르다. 정확히 n바이트가 필요하면 루프를 돈다. write도 같은 식으로 반환값을 보고 반복한다. 반환형이 ssize_t인 이유는 C의 정수 자료형과 형 변환에 있다.

ssize_t read_all(int fd, char *buf, size_t len)
{
    size_t done = 0;
    while (done < len) {
        ssize_t n = read(fd, buf + done, len - done);
        if (n == 0) break;                    /* EOF */
        if (n == -1 && errno == EINTR) continue;  /* 다시 시도 */
        if (n == -1) return -1;
        done += n;
    }
    return done;
}

파일 메타데이터와 디렉터리 읽기

파일의 내용이 아니라 inode에 든 정보(종류, 권한, 크기, 시각)는 stat 계열로 읽는다. 셸의 ls -l, stat 명령이 이 시스템 콜을 부른다.

struct stat의 주요 필드는 st_ino(inode 번호), st_mode(종류 + 권한), st_nlink(하드 링크 수), st_uid·st_gid, st_size(바이트), st_blocks(할당된 512바이트 블록 수), st_atime·st_mtime·st_ctime(마지막 접근·내용 수정·inode 변경 시각)이다. st_ctime은 생성 시각이 아니다. 권한을 바꿔도 갱신된다.

st_mode 하나에 종류와 권한이 함께 들어 있다.

디렉터리는 read로 읽지 않고 <dirent.h>의 함수로 엔트리를 하나씩 꺼낸다.

DIR *dp = opendir(".");                  /* 실패하면 NULL */
struct dirent *e;
while ((e = readdir(dp)) != NULL)        /* 호출할 때마다 다음 엔트리. 끝이면 NULL */
    printf("%lu %s\n", (unsigned long)e->d_ino, e->d_name);
rewinddir(dp);                           /* 처음 엔트리로 되돌린다 */
closedir(dp);

struct dirent가 보장하는 것은 이름(d_name)과 inode 번호(d_ino)뿐이다. 디렉터리 엔트리가 원래 이 두 가지만 담기 때문이다(파일 시스템). 크기나 권한이 필요하면 이름으로 다시 stat(또는 fstatat)을 부른다. .과 ..도 엔트리로 나오며, 순서는 정렬되어 있지 않다.

dup2와 리다이렉션

dup2(oldfd, newfd)는 newfd를 닫고 oldfd와 같은 열린 파일 항목을 가리키게 만든다. 셸의 리다이렉션은 모두 이 한 줄로 구현된다.

프로그램은 자기 fd 1이 터미널인지 파일인지 모른 채 그냥 write(1, …)를 한다. 파이프와 결합한 전체 흐름은 셸이 명령을 실행하는 방식에 있다.

버퍼는 두 층이다

flowchart LR
  p["printf"] --> ub["stdio 사용자 버퍼<br/>(프로세스 메모리)"]
  ub -->|"fflush"| w["write()"]
  w --> pc["커널 페이지 캐시<br/>(모든 프로세스 공유)"]
  pc -->|"fsync"| d["디스크"]

• write()가 성공해도 디스크에 기록됐다는 뜻은 아니다. 데이터는 페이지 캐시에 있고 커널이 나중에 내려 쓴다. 정전에도 남아야 하는 데이터(DB 로그 등)는 fsync()까지 해야 한다.
• close()는 어느 버퍼도 디스크로 강제하지 않는다.

언어가 주는 파일 API도 같은 두 층 구조다. Python의 open()은 사용자 공간 버퍼를 둔 BufferedReader·BufferedWriter(텍스트 모드면 그 위에 인코딩을 맡는 TextIOWrapper)를 돌려주고, Java의 BufferedReader·BufferedWriter는 기본 8192자 버퍼에 모았다가 한 번에 read·write 시스템 콜을 부른다. 버퍼 없는 FileInputStream.read()로 한 바이트씩 읽으면 바이트마다 시스템 콜이 나간다. 어느 언어든 그 아래에서는 같은 커널 페이지 캐시를 거친다.

stdio 버퍼링 모드

• printf("loading..."); sleep(2);는 개행이 없어 2초 뒤에야 보인다. fflush(stdout)으로 즉시 내보낸다.
• printf와 write(1, …)를 섞으면 순서가 뒤바뀐다. write는 stdio 버퍼를 건너뛴다.
• ./app | cat처럼 파이프로 연결하면 stdout이 완전 버퍼링으로 바뀌어 출력 시점이 달라진다.
• fork 전에 비우지 않은 버퍼는 자식에게 복사되어 같은 내용이 두 번 출력된다.
• 모드는 setvbuf(stdout, NULL, _IONBF, 0)처럼 바꾼다. 직접 출력 함수를 만들 때는 결과를 배열에 모았다가 write를 한 번 부르면 시스템 콜 횟수가 크게 준다.

exit()와 _exit()

fork() 뒤 exec()에 실패한 자식은 _exit()로 끝낸다. exit()를 부르면 부모에게서 복사해 온 stdio 버퍼가 한 번 더 flush되어 출력이 두 번 나올 수 있다. 반대로 _exit()나 크래시로 끝나면 버퍼에 남은 내용은 사라진다. 종료 상태를 거두는 과정과 좀비 프로세스는 프로세스와 스레드를 본다.

I/O 멀티플렉싱

블로킹 read()는 데이터가 올 때까지 프로세스를 재운다. 소켓 여러 개를 한 스레드로 다루려면 "준비된 fd가 생길 때까지 한꺼번에 기다리는" 호출이 필요하다.

pselect·ppoll은 기다리는 동안 막을 시그널 마스크를 함께 받아, 검사와 대기 사이에 시그널이 끼어드는 경쟁을 없앤다.

mmap: 파일을 메모리처럼

mmap(addr, len, prot, flags, fd, offset)은 파일 영역을 프로세스 주소 공간에 매핑한다. 이후 포인터로 읽고 쓰면 커널이 페이지 폴트를 받아 필요한 페이지를 올린다.

• MAP_SHARED: 변경이 파일과 다른 프로세스에 반영된다. MAP_PRIVATE: 쓰기 시 복사(copy-on-write)로 내 사본만 바뀐다.
• offset은 페이지 크기의 배수여야 하고, 작은 파일도 최소 한 페이지를 차지한다.
• 매핑은 열린 파일을 참조하므로 mmap 뒤 close(fd)를 해도 매핑은 유효하다. munmap으로 해제한다.
• 장점: read·write의 커널↔사용자 복사가 없고, 임의 위치 접근과 프로세스 간 공유가 쉽다.

DBMS가 mmap을 피하는 이유

직관과 달리 PostgreSQL·MySQL 같은 DBMS는 버퍼 풀을 직접 관리하고 pread·pwrite로 블록 I/O를 한다.

단일 프로세스의 읽기 위주 작업(LMDB 같은 임베디드 DB, 실행 파일 로딩)에는 mmap이 여전히 좋은 선택이다. TLB shootdown의 비용은 캐시를 고려한 코드에서 다룬다.

정리

• fd는 커널 테이블의 인덱스다. 오프셋은 열린 파일 항목에 있어 fork·dup한 fd끼리 공유된다.
• read·write는 일부만 처리할 수 있으니 0(EOF)과 -1(errno)을 구분하며 루프를 돈다.
• 리다이렉션은 open + dup2, 파이프는 pipe + dup2로 만든다.
• write 성공 ≠ 디스크 기록. 사용자 버퍼는 fflush, 커널 버퍼는 fsync로 비운다. stdout은 터미널이면 줄 단위, 파이프·파일이면 버퍼가 찰 때 나간다.
• 많은 연결은 epoll·kqueue로 기다린다.
• mmap은 편하지만 쓰기 순서와 I/O 시점을 내줘야 한다. 트랜잭션이 필요한 저장소는 직접 버퍼를 관리한다.

관련 노트: 파일 시스템, 파일 시스템 구현, 셸이 명령을 실행하는 방식, UNIX 시그널, C 입력과 파일 입출력, 비동기 서버의 이벤트 루프: 다중 접속 서버에서 Reactor 패턴까지, 운영체제의 입출력 시스템