inode와 fd

리눅스 시험을 준비하면서, 그리고 실무를 하면서 무심코 지나쳤던 개념들을 다시 보며, ‘내가 이걸 얼마나 설명할 수 있는가?’를 생각해보며 다시 보고 있어요. 이 글은 inode와 fd의 개념과 컨셉, 쓰임새를 제가 이해한 대로 다시 적어본 글이예요.

inode

파일의 메타데이터를 저장하는 자료 구조 입니다.

우리는 컴퓨터에서 파일 이름으로 파일에 접근하지만, 사실 파일 이름은 이 inode를 가리키는 alias에 불과 합니다.

inode에는 파일에 대한 메타 정보가 담겨 있습니다.

• 파일 사이즈
• 파일 오너
• 파일 권한
• 데이터 블록을 가리키는 포인터 리스트
  • 실제 데이터는 데이터 블록에 저장 되어 있습니다.
• [주의] inode에는 파일 이름 정보가 저장되지 않습니다.
  • 그럼 어디에 저장? -> 뒤에서 다룹니다!

디렉토리도 사실 파일이다

ls -alh로 보이는 목록에는 파일만 있는게 아니라 디렉토리도 있습니다!

사실 디렉토리도 파일 입니다. 디렉토리도 일반 파일과 동일하게 사이즈, 오너, 권한 정보가 있고, 그게 디렉토리의 inode에 기록 됩니다.

디렉토리의 데이터 블록 안에는 해당 디렉토리에 있는 파일들의 이름과 각 이름이 가리키는 inode index 값이 들어있습니다.

디렉토리 ‘파일’의 데이터 블록에 저장하는 값을 “디렉토리 엔트리”라고 합니다.

• inode
  • 파일의 메타데이터 + 데이터 블록에 대한 포인터
• directory entry
  • (filename, inode index)의 모음

inode에는 파일 이름 정보가 저장 되어 있지 않습니다. 즉, 파일 이름 변경(rename) 작업은 해당 파일의 inode가 아니라 해당 파일이 있는 디렉토리 파일의 디렉토리 엔트리에서 (filename, inode index) 쌍의 파일 이름 부분이 바뀌는 작업 입니다.

$ mv a.txt b.txt
---
(a.txt, 100) -> (b.txt, 100)

디스크 레이아웃

inode를 제대로 이해하기 위해선 디스크 레이아웃까지 알아야 합니다. 디스크 레이아웃 위에서 inode가 어떻게 관리되는지 살펴봅시다.

Superblock (파일시스템 전체 정보)

inode Table (inode들의 배열)

Data Blocks (실제 파일 데이터, 디렉토리 파일)

• 슈퍼블록이 뭔가요?
  • 파일시스템 자체에 대한 메타데이터를 저장하는 영역 입니다.
  • 파일시스템의 메타데이터라고 하면…
    • 어떤 파일 시스템 타입인지(ext4, xfs)
    • 총 블록 갯수, 사용 중인 블록 수
    • 총 inode 수, 사용 중인 inode 수
    • 블록 사이즈 (보통 4kb)
    • 파일시스템의 상태 (장상인지, 언마운트 상태인지)
  • 슈퍼블록이 손상되면, 파일시스템 전체가 고장나기 때문에, 현대의 파일시스템은 슈퍼블록에 대한 백업본을 마련해둡니다.
• 파일시스템의 inode 갯수가 고정이라구요?
  • ext 계열만 해당하는 얘기 입니다.
  • 처음 파일시스템을 세팅할 때, 저장하는 파일의 평균 크기를 기입 해야 합니다.
  • 평균적으로 파일 하나가 16kb 크기를 가질거라고 가정하고 파일시스템의 inode 총 갯수를 정합니다.
  • ext 계열은 한번 inode 총 갯수를 정하면, 총량을 늘리거나 줄일 수 없습니다.
• 파일시스템 볼륨을 확장하면, inode 총 갯수가 늘어나지 않나요?
  • 맞아요.
  • ext4와 xfs 둘다 블록 그룹과 Allocation Group 블록에 정해진 inode 총량/상한은 정해져 있어요.
  • 하지만, 블록&AG 그룹 별로 존재하는 총량/상한이기 때문에, 볼륨 확장으로 그룹이 늘어나면 inode 캐파도 함께 늘기 때문에, 파일 시스템 전체의 inode 캐파가 늘어납니다.
• 블록 사이즈(4kb)와 파일 평균 크기(16kb) 차이가 뭘까/
  • inode 총량을 지정할 때, 파일 평균 크기를 16kb로 잡았다는 건, 블록 사이즈가 4kb일 때, 한 파일이 블록 4개 크기인 16kb 수준의 평균적으로 사용할 것이라는 가정 입니다.
  • 하지만, 16kb 이하의 small file이 너무 많다면, inode가 계획 했던 것보다 빠르게 소진 될 수 있습니다.
• xfs에서는 inode 갯수가 동적이다?
  • 별도 문단에서 자세히 다룰게요!

xfs: inode dynamic allocation

ext4는 파일 시스템을 포맷하는 시점에 inode table의 영역을 정적으로 예약 합니다. 그래서 inode를 모두 소진하면, 데이터 신규 쓰기와 파일 생성이 불가능 합니다.

Superblock (파일시스템 전체 정보)

B+Tree 인덱스

Data Blocks (inode + 실제 파일 데이터)

반면에 xfs는 inode를 동적으로 할당 합니다. xfs는 레이아웃에서 고정된 inode table 영역이 존재하지 않습니다. 대신, 파일이 생성될 때, 데이터 블록 영역에서 inode chunks를 동적으로 할당합니다.

inode chunk는 64개의 inode를 묶은 단위 입니다. 파일이 많이 생기면 chunk를 추가로 할당하고, inode chunk를 사용 했던 파일이 모두 삭제 되면, chunk를 데이터 블록으로 반환 합니다.

그럼 xfs는 inode를 어떻게 추적하는가?

위에도 적었듯, xfs는 inode를 1개씩 관리하지 않고, 64개 묶음 단위로 관리합니다. 그리고 inode chunk 마다 64bit의 bitmask가 있어서 free or used 여부를 트래킹 합니다.

free mask: 1111000101000100...

파일 시스템에 아무런 데이터가 없는 클린 상태에서, 맨 첫 파일을 생성하는 상황을 가정하고 시작해봅시다.

첫 파일을 생성하기 위해서 새로은 inode chunk 할당부터 해야 합니다. 64개 슬롯이 모두 비어 있는 inode chunk를 데이터블록에서 생성 합니다.

그리고 이 inode chunk는 inobt와 finobt라는 inode chunk를 모은 공간에 추가 됩니다.

inobt: [#0, free=1111....1111] <- 추가됨
finobt: [#0, free=1111....1111] <- 추가됨 (빈 슬롯 상태로 시작하니까)

inobt는 모든 inode chunk를 모아두는 배열이고, finobt는 inode chunk 중 빈 공간이 있는 것들만 모아두는 배열 입니다.

이제 chunk 생성 후, 실제로 파일이 생성 되어 inode 하나가 할당 되면, 해당 inode chunk의 슬롯에 파일 하나를 사용 했다고 표시합니다.

inobt: [#0, free=1111....1110] <- free mask 갱신
finobt: [#0, free=1111....1110] <- free mask 갱신 (아직 빈 슬롯이 있음)

이 표시는 inobt와 finobt 양쪽 모둥 해야 합니다.

이렇게 파일 쓰기와 생성이 반복 되면서 최초 할당한 inode chunk의 64개 슬롯을 모두 사용 했다고 합시다.

inobt: [#0, free=0000....0000] <- free mask 갱신
finobt: (비어있음) <- finobt에서 #0는 제거.

inobt에 모든 슬롯을 사용했다고 표시하고, finobt에는 해당 inode chunk를 제거 합니다.

만약, 이 상태에서 파일이 하나 삭제 되어 #0 chunk에 다시 빈 슬롯이 생기면, 해당 chunk는 다시 finobt에 추가 됩니다.

inobt: [#0, free=1000....0000] <- free mask 갱신
finobt: [#0, free=1000....0000] <- 빈 슬롯이 생겨서 다시 추가

만약 모든 파일을 삭제 해서, chunk의 64개 슬롯이 모두 해제 된다면,

inobt: (empty)
finobt: (empty)

inobt와 finobt 둘다에서 chunk를 삭제하고, inode chunk의 자원을 해제해 데이터 블록에 반환 합니다.

finobt는 왜 있는가?

xfs에서 finobt로 왜 빈 슬롯이 있는 chunk를 따로 관리할까?

이유는 빈 슬롯을 빠르게 찾아 빠르게 파일 생성과 쓰기 위해서 입니다.

• 만약 finobt가 없었다면
  • 파일 생성 때, 빈 슬롯이 있는 chunk를 찾기 위해 inobt 전체를 탐색 해야 합니다.
  • 이미 생성된 inode chunk가 많을수록 탐색 시간이 길어집니다.
• finobt가 있으면
  • 파일 생성 때, finobt에서 탐색 하면 됩니다.

inobt, finobt에서 B+Tree의 역할

inobt와 finobt는 chunk들을 inode 번호 기준 정렬된 트리로 관리합니다.

그래서 inode 번호로 chunk를 찾을 때, O(log n)으로 탐색 할 수 있습니다.

a.txt 파일을 열어서 해당 파일의 데이터를 읽기 위해서 inode #130번에 접근 해야 한다면, inobt에서 #130번을 O(log N) 속도로 탐색하고, 디스크에서 해당 inode 정보와 파일 데이터를 읽을 수 있습니다.

결국 B+Tree는 inode를 빠르게 탐색하기 위한 인덱스 역할 입니다.

xfs에서 inode가 고갈 될 수 있나?

xfs는 inode를 필요할 때만 할당하는 동적 할당 방식이지만, inode를 무한히 만들 수는 없습니다.

inode를 데이터 블록에서 할당해서 사용하기 때문에, inode가 너무 많아지면 그만큼 디스크 사용량이 늘어납니다.

결국 xfs에서 inode 고갈을 만났다면, 디스크에서 데이터 블록 공간을 모두 소진한 상황이나 마찬가지 입니다.

하드 링크와 심 링크

하드 링크

• ln a.txt b.txt
• 원본과 복사본 개념이 없는 링킹
• 둘다 완전 동일한 inode를 가리킵니다.
• rm a.txt로 하나를 삭제하면, b.txt만 해당 inode를 가리키는 유일한 파일이 됩니다.
• 하지만, 실제 데이터 삭제가 이뤄지지는 않는데, 왜냐면 inode에서 해당 inode를 가리키는 link count가 1 이상이면 데이터 블록 삭제가 이뤄지지 않기 때문입니다.

심볼릭 링크

• ln -s a.txt c.txt
• 심링크는 자기만의 inode를 가집니다.
• 그래서 ls -li로 확인하면, 두 파일의 inode 값이 다릅니다.
• 심링크 inode는 내부에 데이터 파일 대신, 어떤 파일을 가리키는지 경로 문자열이 저장 됩니다.
• rm a.txt로 심링크의 원본 파일을 삭제하면
  • 그걸 가리키던 c.txt -> a.txt (삭제됨) 상태가 되기 때문에, c.txt 파일에 접근하면 Broken Link 오류가 발생합니다.

fd (file descriptor)

이번 포스트의 두번재 주제인 fd 입니다.

fd는 File Descriptor의 약어로 프로세스가 파일에 접근하기 위해 발급 받은 프로세스 내의 고유 번호 입니다.

파일와 프로세스를 도서관 대출 시스템이라고 생각해볼 수 있는데,

파일	책
커널	도서관
프로세스	사용자
FD	대출 번호

프로세스가 fd = open("a.txt");로 파일을 오픈 하면, 커널이 해당 파일에 대해 4번 번호를 발급 해줍니다. 그럼 프로세스는 그 파일에 접근하기 위해 4번 번호를 사용하면 됩니다.

read(4, ...);
write(4, ...);
close(4);

이렇게 파일명 "a.txt"를 쓰는게 아니라, 파일 번호 값을 사용합니다.

왜 파일명이 아니라 FD 번호를 발급 하게 되었을까?

파일을 관리할 때, 이름 대신 숫자 번호가 더 편하니까? -> ❌

파일을 열었다(open)는 상태를 유지하고, 쉽게 접근하기 위해서.

만약 파일명을 사용 했다면,

read("a.txt", ...);
write("a.txt", ...);

이렇게 매 호출마다 커널이 경로 탐색, inode 찾기, 파일 상태 생성, 읽기 수행을 반복 해야 함.

open()은 파일 읽기를 위한 준비 작업 입니다. 프로세스에서 파일 접근을 위한 fd = open() 작업을 1회만 수행하고, 그 뒤부터는 이미 로딩한 path lookup, perm check, 커널 파일 객체를 모두 재사용합니다.

그리고 파일명이 바귀더라도, 계속 그 파일로 접근이 가능합니다. fd = opne("a.txt")로 오픈한 파일이 다른 곳에서 mv a.txt b.txt로 이름이 바뀌더라도, read(fd, ...)를 하게 되면 해당 파일에 계속, 이어서 접근할 수 있습니다. 이건 파일명에 매핑되는 inode를 미리 찾아두었기 때문입니다.

fd는 사실상 배열 인덱스임.

FD 정수값은 fdtable[]라는 배열 구조체에 접근하는 인덱스 입니다.

물론 테이블을 HashMap<>으로 구현했다면, 파일명 문자열로 룩업 할 수 있겠지만, 정수에 비해 룩업 연산 코스트가 더 들게 됩니다.

그리고 fdtable[]은 같은 파일에 대해 서로 다른 fd 할당이 이뤄질 수 있습니다.

fd1 = open("a.txt");
fd2 = open("a.txt");

이 경우, 같은 파일을 서로 다른 fd로 발급 한 것이고, 두 fd는 서로 다른 offset pointer를 가지고 관리 됩니다.

이렇게 하는 이유는 같은 파일의 서로 다른 영역에서 읽기/쓰기 작업을 할 수도 있기 대문입니다. 그래서 각 fd 마다 어디까지 읽었는지에 대한 offset을 별도로 관리해야 합니다.

또, 프로세스는 오픈 소켓(socket)도 fd로 관리합니다. 그런데, 소켓은 경로(path)라는 개념이 없습니다.

s1 = socket();
s2 = socket();

만약 fdtable[]이 경로 기반 설계 였다면, socket들의 경로는 뭐로 정해야 할까요? 정말 수가 없습니다.

그래서 리눅스 시스템 전체 구조를 생각 했을 때, 파일/소켓/파이프라인/터미널을 모두 추상화 해서, 모든 I/O Object를 오픈 할 때는 모두 fdtable[]에 기록하고 fd 번호를 발급 하는 식으로 동작 합니다.

reserved FD

위에서도 말했듯 FD는 오픈 파일 뿐만 아니라, 소켓, 파이프라인, 터미널에도 번호를 매깁니다.

이때, 0/1/2번 FD는 아래로 예약 되어 있습니다.

0 = stdin
1 = stdout
2 = stderr

왜 File Descriptor라는 이름이 붙었나?

컴퓨터 세계에서는 식별자를 “Descriptor”라고 부릅니다.

Memory Descriptor
Segment Descriptor
Window Descriptor
Socket Descriptor

FD도 이 관례를 따라 오픈 파일 식별자를 File Descriptor라고 부릅니다.

물론 이름은 file Descriptor 이지만, 현대에는 커널이 관리하는 모든 I/O 객체들(소켓, 파이프 등등)을 참조 하는 용도로 사용합니다.

즉, 현대에는 File Descriptor 라는 이름보다 I/O Object Descriptor라는 표현이 더 정확 합니다.

StarRocks는 CN 노드의 FD 갯수를 추적함

사실 FD가 뭔지 각 잡고 알아보게 된 진짜 이유는 StarRocks 운영 하면서 FD 관련된 지표를 봤기 때문입니다.

스타락스는 BE/CN 프로세스가 얼만큼의 FD를 열어서 사용 중인지를 Prometheus 지표로 수집하고 있습니다.

프로세스에서 관리할 수 있는 FD 갯수는 상한이 있습니다. 이게 fd_num_limit 지표인데, 이것 이상 사용할 수 없고, fd_num_used / fd_num_limit 비율이 높게 되면, BE/CN 프로세스가 더이상 소켓 통신이나 데이터 읽기/쓰기 작업을 하지 못하게 될 수 있습니다.

Linux에서 FD 한계에 도달해 FD 할당을 더 못 받게 되면, EMFILE(Too many open files) 에러가 발생합니다.

그리고 CN 기능들이 영향을 받게 되는데,

• CN은 Query를 실행하기 위해 FE-CN, CN-CN과 brpc 소켓 통신을 하게 됩니다. FD가 모자라면, socket(), connect(), accept() 같은 소켓 통신이 실패합니다.
• FE가 고갈되면, Remote에 있는 Object Storage Scan도 실패합니다.
• 그리고 Spill도 실패하게 됩니다.
• 가장 무서운 건, heartbeat socket 조차 할당이 안 되어서 노드가 시스템에서 축출되는 상황 입니다.
• 심지어 로그 파일 작성도 못하게 되어 로그도 못 남기게 될 수도 있습니다.

그래서 스타락스 클러스터를 운영할 때, FD 사용 비율도 유심히 봐야 하는 지표 중 하나 입니다.

스타락스에 FD 상한이 있을까?

스타락스 BE conf에 min_file_descriptor_number = 60000가 있습니다. 시스템의 FD 상한이 이것보다 낮다면 프로세스가 기동하지 못하도록 하는 장치 입니다.

저는 따로 설정하진 않았지만, 아래와 같은 스펙으로 FD limit이 잡혀 있습니다. 아마 EKS 노드에서 잡아준 것 같습니다.

• fd soft limit = 65536
• fd hart limit = 1048567

두 값은 스타락스 노드가 노출하는 Prometheus metric에서도 확인할 수 있습니다.

왜 soft limit과 hard limit이 있을까?

이건 스타락스의 개념이 아니고 Linux의 리소스 제한 방식 입니다.

• hard limit
  • 최대 허용치 입니다.
  • 필요하면 soft limit을 이 hard limit까지만 늘릴 수 있습니다.
• soft limit
  • 프로세스가 실제로 가질 수 있는 FD의 상한선 입니다.
  • 이걸 넘게 되면, Too many open files 에러가 발생 합니다.

그래서 실질적으로는 fd_num_used / fd_soft_limit 비율만 잘 모니터링 해주면 됩니다.

스타락스 성능에 fd 튜닝이 중요할까?

놉 ❌ 중요하지 않습니다.

fd 사용 튜닝은 성능 보다는 안정성 지표에 가깝습니다. fd soft limit을 늘린다고 해서 쿼리가 빨라지는 것도 아닙니다.

inode vs fd

처음 이 글을 작성하게 된 계기는 LFCS 시험을 준비하고, 회사 일을 하면서 이 둘을 만났을 때, 저 자신이 둘을 제대로 구분하고 설명할 수 없다는 사실을 발견 해서 입니다.

이제 와서 돌아보면… 둘이 컨셉을 비교할 수 있을 만큼 헷갈리는 영역도 아니었구요… ㅋㅋ 그냥 제가 잘 몰라서 헷갈렸던거 같아요… ㅋㅋ

그래도 이번 기회에 각각을 제대로 살펴보고, 어떤 영역에서 저와 마주칠 수 있는지 확실히 확인한 것 같아 후련 합니다 ㅎㅎ

그래서 둘의 차이는 뭐라구요?

• inode는 파일의 메타데이터와 데이터 포인트 리스트를 저장한 메타 데이터 객체다.
• fd는 프로세스가 오픈한 파일에 대해 부여한 식별자 정수 번호다.