아이노드
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
아이노드는 파일 시스템에서 파일에 대한 메타데이터를 저장하는 자료 구조이다. 각 파일은 고유한 아이노드 번호(i-number)를 가지며, 아이노드는 파일 소유자, 접근 권한, 파일 종류, 링크 수, 파일 크기, 타임스탬프 등의 정보를 포함한다. 아이노드는 파일 시스템 내 아이노드 테이블의 인덱스 역할을 하며, 파일 시스템 드라이버가 파일의 실제 위치 등 필요한 정보에 접근할 수 있도록 한다. POSIX 표준에서는 아이노드를 "파일 일련 번호"로 표현하며, 파일 시스템 권한과 파일 속성을 정의한다. 아이노드 기반 파일 시스템은 파일에 여러 이름을 부여하고, 링크가 없는 파일의 삭제를 처리하는 등의 특징을 가지며, 아이노드 고갈 문제를 해결하기 위해 동적 아이노드 할당을 지원하는 파일 시스템도 존재한다.
더 읽어볼만한 페이지
| 아이노드 |
|---|
2. 어원
'아이노드'의 'i'가 무엇을 의미하는지는 명확하지 않다. 유닉스 개발자 데니스 리치는 이 질문에 대해 "사실, 저도 모릅니다. 그냥 우리가 사용하기 시작한 용어입니다. '인덱스'가 제 추측으로는 가장 근접합니다."라고 답했다.[4]
파일 시스템은 파일 내용 자체와는 별개로, 파일에 대한 메타데이터를 아이노드에 저장한다. 각 파일은 고유한 아이노드 번호(i-number)로 식별된다. 아이노드는 파일 소유자, 접근 권한(읽기, 쓰기, 실행), 파일 종류, 링크 수, 파일 크기, 타임스탬프 등의 정보를 포함하며, `stat` 시스템 호출을 통해 확인할 수 있다.[7] 아이노드 번호는 파일 시스템 내 아이노드 테이블의 인덱스 역할을 하며, 이를 통해 파일 시스템 드라이버는 파일의 실제 위치 등 필요한 정보에 접근할 수 있다. `ls -i` 명령으로 파일의 아이노드 번호를 확인할 수 있다.
이는 파일 시스템이 파일 접근 정보를 디스크의 평면 배열(아이노드 테이블)에 저장하고, 모든 계층적 디렉토리 정보는 이와 별도로 유지하는 약간 특이한 구조에서 유래한 것으로 보인다. 따라서 i-번호는 이 배열의 인덱스이고, i-노드는 배열의 선택된 요소이다.[4]
데니스 리치와 켄 톰슨의 1978년 논문에는 다음과 같은 내용이 있다.[5]
> […] 디렉토리 항목에는 관련된 파일의 이름과 파일 자체에 대한 포인터만 포함됩니다. 이 포인터는 파일의 ''i-번호'' (인덱스 번호)라고 불리는 정수입니다. 파일에 접근할 때, 해당 i-번호는 디렉토리가 존재하는 장치의 알려진 부분에 저장된 시스템 테이블 (''i-list'')에 대한 인덱스로 사용됩니다. 여기서 발견된 항목 (파일의 ''i-노드'')은 파일의 설명을 포함합니다.
모리스 J. 바흐는 ''아이노드''라는 단어가 "인덱스 노드"라는 용어의 축약이며, 유닉스 시스템에 대한 문헌에서 일반적으로 사용된다고 썼다.[6]
3. 상세
전통적인 파일 시스템에서는 아이노드 수가 파일 시스템 생성 시 고정되었지만, JFS, XFS, ZFS, OpenZFS, ReiserFS, btrfs, APFS 등 최신 파일 시스템은 동적 아이노드 할당을 지원하여 이러한 제약을 완화했다.[8]
아이노드는 파일의 하드 링크 이름을 포함하지 않고, 다른 파일 메타데이터만 포함한다. 유닉스 디렉토리는 파일 이름과 아이노드 번호를 포함하는 연결 구조 목록이다. 파일 시스템 드라이버는 파일 이름을 검색하여 해당 아이노드 번호로 변환한다.
리눅스에서 아이노드의 커널 내 표현은 `struct inode`라고 불린다. BSD 계열 시스템에서는 `vnode`라고 부르는데, ''vnode''의 ''v''는 커널 내의 가상 파일 시스템 계층에서 유래한다.
"아이노드"의 "i"에 대한 기원은 리눅스 커널 메일링 리스트에서 논의된 적이 있다. 2002년에 이 질문은 유닉스 선구자인 데니스 리치에게 전달되었고, 그는 "인덱스"가 가장 근접한 추측이라고 답했다.[4] 켄 톰슨과의 1978년 논문에서도 "인덱스"가 아이노드의 어원적 기원임을 뒷받침한다.[5] 모리스 J. 바흐는 ''아이노드''가 "인덱스 노드"의 축약어라고 썼다.[6]
UNIX운영 체제의 시스템 관리자가 사용하는 프로그램 중에는 파일을 특정하기 위해 아이노드 번호를 표시하는 경우가 있다. 하드 디스크 상태 검사 유틸리티인 fsck나 pfiles가 그 예이다. find(의 -inum 옵션)이나 ls 명령어(대부분 -i)를 통해 파일 경로명과 아이노드 번호를 상호 변환할 수 있다.
파일이 삭제되어도 해당 파일을 사용 중인 프로세스가 있으면 접근이 계속될 수 있다는 특징은 보안상 문제가 될 수 있다. 예를 들어, 라이브러리 보안 업데이트 후에도 이전 버전 라이브러리에 계속 접근하는 프로세스가 있을 수 있어, 취약점이 완전히 해결되지 않을 수 있다. 따라서 시스템 핵심 라이브러리 업데이트 시에는 시스템 재부팅 등의 대책이 필요할 수 있다.
파일 모드는 파일과 관계된 접근 및 실행 권한을 저장하는 16비트 플래그이다.비트 내용 12-15 파일 형식 (일반, 디렉터리, 문자 또는 블록 특별, 선입선출 파이프) 11 SetUID 비트 10 SetGID 비트 9 Sticky 비트 8 소유자 읽기 허가 7 소유자 쓰기 허가 6 소유자 실행 허가 5 그룹 읽기 허가 4 그룹 쓰기 허가 3 그룹 실행 허가 2 다른 사용자 읽기 허가 1 다른 사용자 쓰기 허가 0 다른 사용자 실행 허가 
3. 1. POSIX 아이노드 설명
POSIX 표준은 전통적인 유닉스 파일 시스템의 영향을 크게 받은 파일 시스템 동작을 규정한다. 아이노드는 파일에 대한 ''파일 시스템별'' 고유 식별자인 "파일 일련 번호"라는 구문으로 표시된다.[9] 해당 파일 일련 번호는 파일을 포함하는 장치의 장치 ID와 함께 전체 시스템 내에서 파일을 고유하게 식별한다.[10]
POSIX 시스템 내에서 파일은 `stat` 시스템 호출을 통해 검색할 수 있는 다음 속성[10]을 갖는다.
파일 모드는 파일과 관계된 접근과 실행 권한을 저장하는 16비트 플래그이다. 내용은 다음과 같다.
| 비트 | 내용 |
|---|---|
| 12-15 | 파일 형식(일반, 디렉터리, 문자 또는 블록 특별, 선입선출 파이프) |
| 11 | SetUID 비트 |
| 10 | SetGID 비트 |
| 9 | Sticky 비트 |
| 8 | 소유자 읽기 허가 |
| 7 | 소유자 쓰기 허가 |
| 6 | 소유자 실행 허가 |
| 5 | 그룹 읽기 허가 |
| 4 | 그룹 쓰기 허가 |
| 3 | 그룹 실행 허가 |
| 2 | 다른 사용자 읽기 허가 |
| 1 | 다른 사용자 쓰기 허가 |
| 0 | 다른 사용자 실행 허가 |
4. 아이노드의 특징 및 영향
파일은 여러 개의 이름을 가질 수 있는데, 여러 이름이 동일한 아이노드를 하드 링크하는 경우, 해당 이름들은 모두 동일하게 취급된다. 즉, 처음 생성된 이름에 특별한 의미가 부여되지 않는다. 이는 아이노드 번호가 아닌 원래 이름에 의존하는 심볼릭 링크와는 다른 특징이다.[7]
아이노드는 링크가 없을 수도 있다. 링크가 없는 아이노드는 파일 시스템 내에서 남은 디렉터리 항목이나 해당 파일로 이어지는 경로가 없는 파일을 의미한다. 이러한 파일은 삭제되었거나 더 이상 디렉터리에서 참조되지 않는 파일이지만, 해당 파일을 사용 중인 프로세스가 있으면 완전히 삭제되지 않고 접근 가능한 상태로 유지된다. 링크가 없는 아이노드는 링크 해제된 파일에 의해 해제된 자원(디스크 공간 및 블록)이 할당 해제되거나 파일 시스템이 수정될 때까지 파일 시스템에 남아 있는다.[7]
일반적으로 열린 파일에서 해당 파일을 여는 데 사용된 파일 이름을 알아내는 것은 불가능하다. 프로그램이 파일을 열면 운영 체제는 파일 이름을 아이노드 번호로 변환한 다음 파일 이름을 폐기하기 때문이다. 따라서 프로세스의 현재 작업 디렉터리를 검색하는 함수는 파일 이름에 직접 접근할 수 없다.[7]
과거에는 하드 링크를 사용하여 디렉터리를 연결하는 것이 가능했으나, 현대 시스템에서는 디렉터리 구조의 복잡성 증가를 막기 위해 대부분 금지하고 있다. 다만 예외적으로 '''루트''' 디렉터리의 상위 디렉터리는 여전히 루트로 정의된다. 이러한 금지에 대한 가장 주목할 만한 예외는 Mac OS X(10.5 버전 이상)에서 발견되며, 이는 슈퍼유저가 디렉토리의 하드 링크를 생성하는 것을 허용한다.[13]
파일이 동일한 파일 시스템 내의 다른 디렉토리로 이동하거나, 디스크 조각 모음으로 인해 물리적 위치가 변경되더라도 파일의 아이노드 번호는 변경되지 않는다. 이러한 특징은 FAT 등 일부 파일 시스템에서는 불가능하다.[7]
아이노드 기반 파일 시스템에서는 실행 중인 프로세스가 사용하는 라이브러리 파일을 안전하게 교체할 수 있다. 새로운 라이브러리는 새로운 아이노드를 할당받고, 이전 버전은 사용 중인 프로세스가 종료될 때까지 유지되기 때문이다. 운영 체제가 파일을 교체할 때 아이노드[15]와 포함된 디렉터리[16]에 잠금[14]을 설정하여 업데이트 작업 중에 다른 프로세스가 파일(아이노드)[17]을 읽거나 쓰지 못하게 하여 데이터 불일치 또는 손상을 방지한다.[18]
5. 아이노드 고갈 가능성 및 해결책
일부 파일 시스템은 생성 시 고정된 수의 아이노드를 할당한다.[19] 따라서 파일 시스템에 여유 공간이 남아 있어도 아이노드가 고갈될 수 있다. 이러한 상황은 각 파일이 아무리 작더라도 자체 아이노드가 필요하기 때문에 이메일 메시지를 저장하는 서버와 같이 작고 많은 파일이 있는 경우 자주 발생한다.
다른 파일 시스템은 동적 아이노드 할당을 사용하여 이러한 제한을 피한다.[20] 동적 아이노드 할당을 사용하면 파일 시스템 생성 시 생성된 고정된 수에 의존하는 대신 필요에 따라 더 많은 아이노드를 생성할 수 있다.[21] 이는 새 파일 및 디렉터리에 사용할 수 있는 아이노드 수를 늘려 파일 시스템을 "확장"하여 아이노드 고갈 문제를 피할 수 있게 한다.[22]
6. 인라이닝 (Inlining)
Ext4 파일 시스템에는 생성 시 `inline_data` 옵션을 활성화하면 인라이닝(inlining)을 수행할 수 있다.[24] 아이노드의 크기는 제한되어 있기 때문에, 이는 매우 작은 파일에만 적용된다.[24] 매우 작은 파일의 경우, 아이노드 자체에 데이터를 저장하여 공간(데이터 블록 필요 없음)과 조회 시간(추가 디스크 접근 필요 없음)을 절약하는 것이 합리적일 수 있다. 이러한 파일 시스템 기능을 인라이닝이라고 한다. 따라서 현대 파일 시스템을 사용할 때는 아이노드와 파일 데이터의 엄격한 분리를 더 이상 가정할 수 없다.
파일 데이터가 포인터에 할당된 공간에 맞는 경우, 이 공간을 활용하는 것이 편리하다. 예를 들어, ext2와 그 후속 버전은 데이터가 60바이트 이하인 심볼릭 링크(일반적으로 파일 이름)의 데이터를 "빠른 심볼릭 링크" 방식으로 저장한다.[23]
7. 비-유닉스 시스템에서의 아이노드
NTFS는 B-트리에 파일을 저장하는 마스터 파일 테이블(MFT)을 가지고 있다. 각 항목에는 아이노드 번호와 유사한 "fileID"가 있어 이 항목을 고유하게 참조한다.[25] 세 개의 타임스탬프, 장치 ID, 속성, 참조 횟수 및 파일 크기는 이 항목에서 찾을 수 있지만, POSIX와 달리 권한은 다른 API를 통해 표현된다.[26] 디스크상의 레이아웃은 더 복잡하다.[27] 이전의 FAT 파일 시스템에는 이러한 테이블이 없었으며 하드 링크를 만들 수 없었다. NTFS는 또한 작은 파일을 MFT 항목에 인라인하는 개념을 가지고 있다.[28]
파생된 ReFS는 상동하는 MFT를 가지고 있다. ReFS는 128비트 파일 ID를 가지고 있다. 이 확장은 원래 64비트 파일 ID를 가지고 있던 NTFS에도 역이식되었다.[26]
클러스터 공유 볼륨 및 SMB 3.0에서도 동일한 stat과 유사한 GetFileInformationByHandle API를 사용할 수 있으므로 이러한 시스템도 파일 ID와 유사한 개념을 가지고 있는 것으로 추정된다.[26]
8. 관련 내용
리눅스에서는 파일 시스템의 데이터의 커널 내 메모리상 표현을 `struct inode`라고 부른다. BSD 계열 시스템에서는 `vnode`라고 부르는데, ''vnode''의 ''v''는 커널 내의 가상 파일 시스템 계층에서 유래한다.
POSIX 표준에서 규정하는 파일 시스템의 동작은 전통적인 UNIX 파일 시스템에 큰 영향을 받았다. 일반 파일은 다음과 같은 속성을 갖는 것이 요구된다.
- 파일의 길이 (바이트 수)
- 장치 ID (파일을 저장하고 있는 장치를 식별)
- 파일 소유자의 사용자 ID
- 파일의 그룹 ID
- 파일 시스템 내에서 파일을 식별하는 inode 번호
- 파일 모드 (파일 권한)
- 최종 inode 갱신 시(ctime), 최종 파일 갱신 시(mtime), 최종 참조 시(atime)를 나타내는 타임 스탬프 그룹
- 해당 inode를 가리키는 하드 링크가 몇 개 있는지 나타내는 참조 카운트
''inode''라는 용어는 블록 장치상의 inode도 의미하며, 일반 파일, 디렉토리, 경우에 따라 심볼릭 링크에도 대응한다. 이 개념은 손상된 파일 시스템의 복구에서 특히 중요하다.
inode 번호는 해당 inode가 기록된 장치에서 고유한 정수 값이다. 모든 파일은 inode에 물리적으로 연결되어 있다. 프로그램이 파일을 파일 이름으로 참조할 때, 시스템은 해당 파일 이름에 해당하는 inode를 검색한다.
`stat` 시스템 호출은 파일의 inode 번호와 기타 inode 내 정보의 일부를 얻는 기능이다.
''inode''의 ''i''가 무엇을 의미하는지는 불확실하다. UNIX의 개발자 데니스 리치는, 그 질문을 받았을 때 다음과 같이 말했다.
사실, 저도 잘 모르겠습니다. 저희가 사용하기 시작했을 때는 단순한 용어였습니다. 아마 "index"가 원본이 아닐까 생각합니다. 좀 특이한 파일 시스템 구조가 있었는데, 디렉토리를 사용한 계층 구조가 있는데도 모든 파일의 접근 정보를 디스크 내의 평평한 배열에 저장했었거든요. 그래서 i-number는 그 배열의 인덱스였고, i-node는 그 배열의 요소였죠. ("i-"라는 표기는 초판 매뉴얼에서 사용되었지만, 점차 하이픈이 없어졌습니다).영어
파일 시스템에 익숙하지 않은 많은 사용자는 아이노드의 개념을 활용하는 파일 시스템의 특성에 놀란다.
- 여러 이름이 동일한 아이노드에 링크되어 있으면 (하드 링크), 어떤 이름도 동일하다고 할 수 있다. 파일을 처음 생성했을 때의 이름은 특별한 의미를 갖지 않는다. 이는 심볼릭 링크가 원본 이름에 의존하는 것과는 전혀 다르다.
- 링크를 전혀 갖지 않는 아이노드도 있을 수 있다. 일반적으로 그러한 파일은 디스크에서 삭제되고, 그 리소스(디스크 블록)는 파일 삭제 처리 과정에서 재사용을 위해 해제되지만, 어떤 프로세스가 해당 파일을 사용 중이라면 계속 접근할 수 있으며, 마지막으로 닫힐 때 삭제 처리가 실행된다. 이 때문에 프로그램을 개정(리컴파일)할 때는 이전의 실행 파일을 먼저 삭제하고, 새로운 버전의 실행 파일은 새로운 아이노드로 생성되도록 하는 것이 권장된다. 이렇게 하면 이전 버전이 실행 중이더라도 아무 문제 없이 처리를 계속할 수 있다.
- 종래에는 열린 파일(파일 디스크립터)에서 열린 파일 이름을 얻을 수 없었다. 운영 체제는 일단 파일 이름을 아이노드 번호로 변환하면 파일 이름 쪽을 잊어버린다. 따라서 `getcwd()`나 `getwd()`와 같은 라이브러리 함수는 "." 디렉토리에 해당하는 아이노드 번호에서 해당 부모 디렉토리를 찾아, 최종적으로 "/" 디렉토리까지 거슬러 올라가 전체 경로 이름을 얻는다. 이러한 불필요한 처리를 생략하기 위해 SVR4 및 Linux 시스템은 추가 정보를 보존하고 있다.
- 디렉토리의 하드 링크는 오래전부터 가능했다. 이를 통해 디렉토리 구조는 트리 구조가 아닌 임의의 유향 그래프가 된다. 어떤 디렉토리를 자신의 부모 디렉토리로 만드는 것도 가능하다. 최근 시스템에서는 그러한 혼란의 원인이 되는 상태를 방지하도록 하고 있다.
참조
[1]
서적
Modern Operating Systems
[2]
웹사이트
Difference between mtime, ctime and atime - Linux Howtos and FAQs
http://www.linux-faq[...]
[3]
웹사이트
Anatomy of the Linux virtual file system switch
http://www.ibm.com/d[...]
[4]
간행물
Fwd: Re: What does the "i" in inode stand for? Dennis Ritchie doesn't know either.
http://lkml.indiana.[...]
2011-01-12
[5]
학술지
The UNIX Time-Sharing System
https://archive.org/[...]
2015-12-19
[6]
서적
The Design of the UNIX Operating System
Prentice Hall
1986
[7]
서적
The Design of the UNIX Operating System
Prentice Hall
1986
[8]
웹사이트
linfo
http://www.linfo.org[...]
2020-03-11
[9]
웹사이트
Definitions - 3.176 File Serial Number
http://pubs.opengrou[...]
2018-01-10
[10]
웹사이트
[11]
웹사이트
Overview of the Linux Virtual File System
https://www.kernel.o[...]
2023-05-20
[12]
웹사이트
Directory Entry Cache (dcache)
https://www.kernel.o[...]
2023-05-20
[13]
웹사이트
What is the Unix command to create a hardlink to a directory in OS X?
https://stackoverflo[...]
2020-01-05
[14]
웹사이트
Locking
https://www.kernel.o[...]
2023-05-21
[15]
웹사이트
struct inode_operations
https://www.kernel.o[...]
2023-05-21
[16]
웹사이트
Directory Locking
https://www.kernel.o[...]
2023-05-21
[17]
웹사이트
Lock types and their rules
https://www.kernel.o[...]
2023-05-21
[18]
웹사이트
Runtime locking correctness validator
https://www.kernel.o[...]
2023-05-21
[19]
웹사이트
2. High Level Design
https://www.kernel.o[...]
2023-05-21
[20]
웹사이트
XFS Self Describing Metadata
https://www.kernel.o[...]
2023-05-21
[21]
웹사이트
2.7. Block and Inode Allocation Policy
https://www.kernel.o[...]
2023-05-21
[22]
서적
Managing RAID on Linux
O'Reilly Media, Inc.
[23]
웹사이트
The Linux kernel: Filesystems
http://www.win.tue.n[...]
[24]
웹사이트
Ext4 Disk Layout
https://ext4.wiki.ke[...]
2013-08-18
[25]
웹사이트
Does Windows have Inode Numbers like Linux?
https://stackoverflo[...]
[26]
웹사이트
GetFileInformationByHandle function (fileapi.h) - Win32 apps
https://docs.microso[...]
2022-07-27
[27]
웹사이트
'[MS-FSCC]: NTFS Attribute Types'
https://docs.microso[...]
2023-09-20
[28]
웹사이트
Windows - Maximum size of file that can be stored entirely in NTFS Master File Table (MFT)
https://superuser.co[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com