파일 이름 뒤에 숨겨진 inode의 본질

리눅스 서버 운영하다 보면 한 번쯤 이런 기괴한 상황을 마주한다.

"용량(df -h)은 남았는데 파일 생성이 안 된다."
"로그 파일을 지웠는데 디스크 여유 공간이 안 늘어난다."
"파일 이름을 바꿨는데 서비스는 왜 안 터지고 잘 돌아가나?"

이유는 간단하다. 리눅스는 파일 이름 따위 신경 안 쓰기 때문이다. 커널이 파일을 식별하는 진짜 기준은 inode(아이노드)라는 숫자다.

1. inode: 이름 없는 주민등록번호

우리가 보는 config.conf는 인간용 라벨일 뿐이다. 시스템 내부에서 파일의 실체는 inode 번호로 관리된다.

• inode에 들어있는 것: 권한, 소유자, 파일 크기, 시간 정보, 그리고 데이터가 박힌 물리적 주소(Pointer).
• inode에 없는 것: 파일 이름. (이름은 디렉토리 파일이 따로 들고 있다.)

2. 실전 확인: 데이터로 증명하기

엔지니어라면 눈으로 확인해라.

① 아이노드 번호 뽑기

$ ls -li
1234567 -rw-r--r-- 1 root root 0  3월 10 21:00 test.txt

맨 앞의 1234567이 이 파일의 고유 식별자다.

② 아이노드 잔량 체크

$ df -i

IUse%가 100%면 용량이 테라바이트 단위로 남아있어도 파일 생성은 끝이다. 작은 파일이 수백만 개 쌓이는 세션 폴더나 임시 디렉토리에서 주로 터지는 사고다.

3. 하드 링크: 몸은 하나, 이름은 여럿

이 개념이 리눅스 파일 시스템 계층의 핵심이다.

• 상황: A 파일에 대해 하드 링크 B를 만든다.
• 결과: 둘의 inode 번호는 같다.
• 리스크: A를 지워도 B가 남아있으면 데이터는 삭제되지 않는다. inode에 연결된 'Link Count'가 0이 되어야 커널은 비로소 데이터 블록을 비운다.

4. 실무 트러블슈팅 패턴

패턴 1: 유령 용량 문제
대용량 로그를 rm으로 지웠는데 용량이 안 확보된다면?
→ 특정 프로세스가 그 파일을 열고(Open) 있기 때문이다. 이름은 지워졌지만 프로세스가 inode를 붙잡고 있어 데이터 블록이 해제되지 않는 상태다. lsof | grep deleted로 범인을 찾아 프로세스를 쏘든가 재시작해라.

패턴 2: inode 고갈
df -h는 정상인데 "No space left"가 뜬다면?
→ 바로 df -i 쳐라. 찌꺼기 파일(Tiny files)이 inode 리소스를 다 먹어치운 거다.

5. 요약

1. 리눅스 파일의 본질은 이름이 아니라 inode 번호다.
2. df -h(용량)만 보지 말고 df -i(inode)도 관리해라.
3. 링크 카운트가 0이 되어야 진짜 삭제다.