Inode(Index Node)

File Descriptor가 실행중인 프로세스가 파일을 다루는 번호표라면, inode는 디스크상에서 저장된 파일의 실체적 신분증같은 느낌인데

Inode #

우리는 파일을 파일명으로 인식한다. 그러나 운영체제 커널은 파일을 inode 번호로 관리한다.

• 추상화: 파일 시스템에서 파일 이름은 단지 인간을 위한 별칭일 뿐이고 실제 파일의 모든 메타데이터(크기, 권한 ,생성시간 등)와 데이터 블록의 위치정보는 inode에 담겨있다.
• 고유성: 하나의 파일 시스템 내 각 inode는 고유한 번호를 갖는다.

inode metadata #

• File Mode: 권한 read write execut 및 파일 타입 (일반 파일, 디렉토리, 소켓등)
• Link Count: 이 inode를 가리키는 하드 링크의 수
• Owner Info: owner uid, gid(group uid)
• File Size: 파일의 크기 (byte 단위)
• Timestamps:
  • atime: 마지막 접근 시간
  • mtile: 마지막 내용 수정 시간
  • ctime: 마지막 속성(메타데이터) 변경시간
• Data Block Pointers: 실제 데이터가 디스크에 어디에 저장되어있는지 알려주는 주소값

파일명은 inode에 저장되지 않는다. 파일명은 디렉토리 파일의 데이터 블록 내에 파일명 : inode 번호 형태로 매핑되어 저장되어있다.

inode의 구조: 데이터 블록 포인터 #

파일의 크기는 수 kb에서 수 tb까지 다양하다.

제한된 크기의 inode 내에서 이를 어떻게 가리킬까? 전통적인 Unix 파일 시스템 UFS의 Multi Level Indexing 구조를 보면 된다.

1. Direct Blocks: 처음 12개 정도의 포인터는 실제 데이터 블록을 바로 가르킨다. 작은 파일은 여기서 끝, 매우 빠르고
2. Single Indirect: 데이터 블록 대신, 다른 포인터들이 담긴 인덱스 블록을 가리킨다.
3. Double/Triple Indirect: 인덱스의 인덱스를 가리켜 테라바이트급의 대용량 파일을 지원한다.

최신 파일 시스템 Ext4, XFS는 이 방식 대신 extents라는 방식을 써서 어디서부터 어디서까지 연속된 블록이라고 기록하여 관리해 효율성을 높인다고한다.

Hard Link, Soft(Symbolic) Link #

hard link는 기존 inode 번호 그대로를 공유하는 메커니즘이고 inode 번호는 원본가 동일하며

원본 삭제시 데이터 유지 (link count가 0이될때까지) 그리고 파일크기도 원본과 동일하다

**soft link(symbolic)**는 원본의 경로명을 담고있는 새로운 inode를 생성한다.

원본가 다르고 원본 삭제시 연결이 끊긴다. 파일크기는 경로 문자열 만큼 아주 작은 크기다.

언제 쓸지 모르는데 원본을 계속 참조하고 있으면 불필요한 비효율이 있어서 소프트로 뒀다가 쓸때 하드로 바꿔서 최적화한다.

indoe exhaustion #

파일 디스크립터 고갈도 발생할 수 있지만 inode 고갈도 발생할 수 있다.

디스크 용량 (df -h)은 충분한데, 새로운 파일을 만들려하면 No space left on device 에러가 뜨는 경우다.

• 아주 작은 크기의 파일 예를들어 수백만개의 세션파일이나 로그파일을 너무 많이 생성했을때 파일 시스템 생성시 inode의 총개수는 정해져있기때문에 고갈될때가 있다.
• df -i로 확인할 수 있다.
• 파일 생성이 불가 touch, mkdir 이 실패한다거나
• 서비스 시스템이나 db 쓰기 작업 오류가 날 수 있다.

FD, inode #

1. 사용자가 open("a.txt")를 호출한다.
2. 커널은 디렉토리 엔트리에서 a.txt에 해당하는 inode 번호를 찾는다.
3. 해당 inode를 읽어 메모리에 올린다.
4. 커널은 이 inode가 가리키는 open file description을 만들고 프로세스 fd 테이블에 fd 번호를 할당한다.

결론적으로 fd는 프로세스가 지금 사용중인 입구인것이고 inode는 디스크에 존재하는 실제 방이다.