오늘은 리눅스 파일시스템에서 볼 수 있는 개념 중 하나인 Inode에 대해서 알아보자
inode가 궁금해진 이유는 일을 하면서 모니터링쪽을 보는데 inode 값을 모니터링 하길래 뭐하는 놈이길래 모니터링까지 할까? 싶어서 찾아보게 되었다
Inode
Inode 는 파일, 디렉터리 등 파일 시스템에 관한 정보를 가지고 있고, 파일도 각자 한 개의 Inode를 가지고 있다
소유자 그룹, 접근 모드, 파일 형태 등 해당 파일에 대한 정보를 가짐
파일에 대한 식별 정보를 담고 있음
실제 파일의 내용은 Inode 가 아닌 디스크의 다른 영역에 저장되는데, Inode는 이 위치 정보를 통해 OS가 실제 데이터에 접근할 수 있도록 해준다고 한다
디스크는 한정된 수의 Inode를 가진다
대부분의 경우에서 Inode 영역이 소진될 일이 거의 없겠지만, 작은 파일들이 수도 없이 생성되면 모든 Inode가 소진되어, 실제 디스크에는 여유 공간이 100G가 남아있어도, Inode의 부족으로 인하여 파일 생성이 제한될 수도 있다

- 크기, 소유자, 퍼미션, 수정 시간 등의 메타데이터를 담고 있음
- 실제 파일의 내용은 디스크의 다른 영역에 저장
- Inode 는 이 위치 정보를 가지고 있어서 OS가 실제 데이터에 접근할 수 있도록 해줌
- 파일은 Inode 고유 값과 자료구조에 의해 주요 정보를 관리
- 컴퓨터를 사용하는 사람은 파일 이름으로만 인식하지만, 실제 컴퓨터는 파일이름:inode 로 파일과 Inode 번호를 배치시켜 인식
개념을 알아보니 파일이 실제로 저장되어있는 주소값을 가지고 있다는 것은 알겠다
그렇다면 왜 이런 방식을 채택한걸까?
파일 자체를 저장하고 있다가 탐색할 경우 문제가 생기는 부분이 있는걸까
Inode 사용 이유
성능상의 이유도 있겠지만 파일 이름, 정보, 데이터를 분리해서 관리하기 위해 사용한다고 한다
리눅스에서 Inode 방식을 쓴다고 해서 파일을 검색할 때 디스크 전체를 탐색하는것은 아니다
| 파일 이름 | inode 번호 |
| test.txt | 1234 |
| image.jpg | 2345 |
| ... | ... |
위와 같은 방식으로 목록을 가지고 있다가 특정 파일에 대한 요청이 들어오면 Inode 번호를 따라가서 해당 파일에 대한 처리를 진행한다고 한다
그럼 모든 정보를 파일 안에 넣으면 어떻게 될까?
- 파일을 열기 전에는 파일 위치를 알 수 없는 문제가 생기게 된다
- 파일을 찾기 위해서는 파일 이름을 알아야 하는데, 파일 이름이 내부에 들어 있다면 해당 파일을 먼저 읽고 찾아야 한다
- 권한을 확인하기 위해서 파일 내용을 까봐야 한다
- Inode 방식은 Inode 정보만 확인하면 되는데, 사용하지 않을 경우 파일을 열고 그 안에 있는 권한정보까지 열어봐야 한다
그럼 윈도우에서는 Inode를 사용하지 않는데 어떻게 파일을 탐색하는건지 궁금해졌다
보통의 윈도우의 파일 시스템인 NTFS 기준으로는 MFT 레코드가 Inode 와 비슷한 역할을 한다고 한다
- MFT(Master File Table)
- 파일과 디렉터리마다 최소 하나의 MFT 레코드가 만들어지고 이 레코드에 파일을 찾고 관리하는데 필요한 정보 저장
- Inode와 세부 구현은 다르지만 역할을 비슷
깊게 알아보지는 않겠다
Inode 파일 처리 과정
그렇다면 Inode 를 통해서 어떻게 파일을 탐색하는걸까?
1. 파일이 생성되자마자 Inode 번호 부여
2. 사용 가능한 Inode가 할당되어 상세 정보 메타데이터 기입
3. 기입된 정보들을 바탕으로 파일 접근
파일 이름으로 직접 디스크의 데이터를 찾는 것이 아닌, 디렉터리를 따라가며 해당 파일의 Inode 번호를 찾고, Inode 를 통해 실제 데이터 위치에 접근한다
예시를 한 번 살펴보자
- cat /home/user/test.txt 라는 명령어를 실행했다고 가정한다
- 경로는 /home/user/test.txt
- 각 디렉터리에서 이름을 검색한다
- / > home > user > test.txt
- test.txt의 Inode 번호를 확인
- Inode 정보를 읽음
- Inode가 가리키는 데이터 블록을 확인
- 해당 데이터 블록에 존재하는 파일 내용 읽기
이런식의 흐름을 가진다
Inode 모니터링은 왜?
글의 처음으로 돌아가보자
그래서 Inode 값에 대한 모니터링은 왜 할까?
그건 사실 Inode 설명을 할 때 눈치챌 수 있다
Inode를 저장할 수 있는 용량도 할당이 되고, 대부분의 경우 해당 용량을 다 채우기 전에 디스크의 용량이 먼저 차서 상관이 없다
하지만 PHP 같은 경우는 세션을 파일로 저장해서 수많은 파일이 생성이 되어 Inode를 개수가 소진되고, 이로 인해 디스크 용량이 널널해도 새로운 파일 생성이 되지 않을 수도 있다
이를 방지하기 위해서, Inode 에 대한 모니터링을 진행하며 공간이 부족해지지 않도록 관찰하는 것이다
진짜 Inode
그럼 진짜 Inode를 한 번 보자
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 1982396 614 1981782 1% /dev
tmpfs 1993284 2 1993282 1% /dev/shm
tmpfs 819200 1029 818171 1% /run
efivarfs 0 0 0 - /sys/firmware/efi/efivars
/dev/sda3 26214400 125359 26089041 1% /
/dev/sda6 63636096 10585 63625511 1% /home
/dev/sda1 524288 31 524257 1% /boot
/dev/sda4 26214400 2108 26212292 1% /var
/dev/sda2 0 0 0 - /boot/efi
/dev/sdb1 488380736 3 488380733 1% /data
tmpfs 398656 26 398630 1% /run/user/0
내 노트북 서버의 Inode 를 살펴봤는데 남아있는 개수로 봐서는 웬만해서는 다 사용할 일이 없을것 같다
# ls -i test.txt
100665831 test.txt
# stat test.txt
File: test.txt
Size: 3 Blocks: 8 IO Block: 4096 regular file
Device: 803h/2051d Inode: 100665831 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2026-06-28 00:35:30.183197776 +0900
Modify: 2026-06-28 00:35:30.183197776 +0900
Change: 2026-06-28 00:35:30.183197776 +0900
Birth: 2026-06-28 00:35:30.183197776 +0900
이렇게 특정 파일의 Inode 번호를 살펴볼 수도 있다
마무리
이렇게 Inode에 대해서 알아봤다
다음은 뭘 알아볼까
'시스템, 인프라' 카테고리의 다른 글
| Linux (GNU ~ 부팅) (2) | 2026.07.18 |
|---|---|
| Apache (0) | 2026.07.13 |
| IP (Internet Protocol) (0) | 2026.06.14 |
| fstab (1) | 2026.06.03 |
| RAID (2) | 2026.05.31 |