반응형

 

 개요

 리눅스 시스템에서, 파일 시스템을 처리할 때, 리눅스 전용 특수한 index를 사용합니다. 바로 아이노드(i-node)입니다. 이 아이노드는 이름에서도 볼 수 있듯이, index-node의 줄임말입니다. 인덱스(index)라는 말은, 무언가를 쉽고 빠르게 찾기 위해서 쓰는 용어죠. (데이터베이스 배우신 분이면 한번 쯤은 들어보셨을 겁니다.)

 

 즉, 이름에서도 유추할 수 있듯이, 무언가를 빠르게 찾기 위한 노드입니다. 그 무언가는 바로, 리눅스 시스템에서 파일입니다.  쉽게 이해하면, 아이노드는 리눅스의 모든 파일에 일종의 번호를 부여한겁니다. 

 그리고, 번호말고도, 아이노드는 해당 파일에 대한 정보도 가지고 있습니다.

 

 아래의 문장으로 요약할 수 있습니다.

-> 리눅스 시스템에서 아이노드란, 파일에 대한 정보(메타데이터)를 가진, 일종의 데이터이다.

 

1. 아이노드(i-node)

 아이노드는 리눅스 시스템에서, 파일을 빠르게 찾기 위한 데이터입니다.

 그림으로 한번 살펴볼까요?

 

 

아이노드의 구조 (출처 : https://practice.geeksforgeeks.org/problems/explain-the-structure-of-inode-table)

 i-node는 일종의 자료구조인데요. 사실, i-node는 UFS(유닉스 파일 시스템)와 같은 전통적인 유닉스 계통 파일 시스템에서 사용하는 자료 구조입니다.

 여기서 중요한 건, 파일 시스템 내에서, 파일이나 디렉토리는 고유한 i-node를 가지고 있으며, i-node 번호를 통해 구분이 가능합니다.

 

 > 파일이나 디렉토리는, 고유한 i-node를 가지고 있다.

 

 이 쯤에서, 궁금해하실텐데요. "어? 그럼 내가 가진 파일에도 아이노드가 있는건가?" 맞습니다. 있습니다.

만약, 여러분들이 현재, 리눅스 환경이 이미 있다면, 아래의 명령어로 아이노드 값을 확인해볼 수 있습니다.

$ ls -i /etc/sysctl.conf
140625 /etc/sysctl.conf

$ ls -i /etc/sysctl.d/
140859 10-console-messages.conf  140862 10-link-restrictions.conf  140865 10-ptrace.conf         140868 99-sysctl.conf
140860 10-ipv6-privacy.conf      140863 10-magic-sysrq.conf        140866 10-zeropage.conf       140869 README.sysctl
140861 10-kernel-hardening.conf  140864 10-network-security.conf   140867 99-cloudimg-ipv6.conf

 위의 140625가 i-node의 값, 정확히말하면 인덱스의 값입니다.

 

 

2. 아이노드(i-node)의 구체적인 특징

 아이노드는 파일에 대한 정보(메타데이터)를 포함하고 있고, 인덱스 값도 가진 노드(데이터)입니다.

 이 아이노드가 가지고 있는 정보는 아래와 같습니다.

- 파일 모드(퍼미션)
- 링크 수
- 소유자명
- 그룹명
- 파일 크기
- 파일 주소
- 마지막 접근 정보
- 마지막 수정 정보
- 아이노드 수정 정보

 

 아이노드는 한 파일이 사용하는 모든 블록을 가리키는 포인터들을 포함하는 하나의 블록입니다. 즉, 자기가 담당하고 있는 파일이 있는데, 그 파일이 사용하는 모든 블록을 가리킵니다. 여기서 블록은 데이터를 저장하는 단위입니다.

 즉, 하나의 파일이 여러 데이터 블록(data blocks)을 가질 수 있습니다이 아이노드는 그 모든 블록의 주소를 가리키는 포인터들에 대한 정보를 포함합니다. 아이노드는 이 data block들을 연결해줍니다.

 아이노드(i-node) 안에는 오직 15개의 Block pointer(블럭 포인터)가 있습니다. Block pointer는 블록의 주소를 가리키는데요. 이 Block이라는 건, 하나의 데이터 모음 덩어리 말합니다. 보통, 표준 4KB data block을 사용하는데요.

 즉, Block은 4KB 크기 정도하고, Block Pointer는 그 Block의 주소를 담고있습니다.

 

 그럼, 15개의 Block pointer가 있고, Block의 크기는 표준 4KB니까, 파일의 최대 크기는 60KB일까요? 아닙니다.

총 4개 종류의 pointer가 있고, 이들을 합해서 15개입니다!

 1. direct pointer (1개)  :  데이터 블록을 하나만 가리킴.

 2. indriect pointer (12개)  : driect pointer를 12개 가리킴

 3. doubly indrect pointer (1개)  :  ind

 4. triply indect pointer (1개)

 

direct pointer

만약, block entry가 4B라 가정한다면, (보통, 표준은 4KB data block입니다) 이 i-node가 가리킬 수 있는 가장 큰 파일크기는 60KB입니다. 하지만, 이것은 크지 않습니다. 음악파일 하나가 3MB정도 하는데, 이 파일을 다 담지 못합니다.

-> indriect Pointer는 15개의 block pointer를 가지고 있다.

 

추후에 indriect Pointer에 대해서 업데이트하겠습니다!

 

2. 심볼릭 링크(Symbolic Link)

 심볼릭 링크 하드 링크를 이해하기 위해서는 i-node 를 먼저 이해해야 합니다.


 사용자가 파일 또는 파일과 관련된 정보에 액세스하려고 하면 파일 이름을 사용하지만 내부적으로 파일 이름은 먼저 디렉토리 테이블에 저장된 i-node 번호로 매핑됩니다. 그런 다음 해당 inode 번호를 통해 해당 i-node 에 액세스 됩니다.

 윈도우 시스템에서 제공하는 바로 가기 기능과 매우 유사합니다. 원본 파일에 대한 정보가 포함되어 있지 않으며 원본 파일 위치에 대한 포인터만 포함되므로 새로운 i-node 를 가진 링크 파일이 생성됩니다.

심볼릭 링크 만드는 명령어는 아래와 같습니다.

$ ln –s [원본 파일] [링크 파일]

 

3. 하드 링크(Hard Link)

 하드 링크는 디렉토리 구조에 대한 항목만 파일 생성되지만 원본 파일의 i-node 위치를 가리킵니다.
즉, 하드 링크에는 새로운 i-node 생성이 없습니다. 하드 링크는 일반적인 본사본과는 엄연히 다릅니다. 파일 시스템에 있는 데이터를 복사한 것이 아니라 i-node 번호만 복사했기 때문입니다. 따라서 진짜 복사했을 때와 달리 파일 시스템 내의 데이터 자체가 여전히 1개만 존재합니다.

하드 링크 만드는 명령어는 아래와 같습니다.

$ ln [원본 파일] [링크 파일]

 


4. 심볼릭 링크와 하드 링크 차이

 심볼릭 링크와 하드 링크의 큰 차이는 새로운 i-node 생성 여부입니다. 그 차이에 따라 원본 파일이 삭제할 경우 접근 가능 여부도 달라집니다. 자세한 차이는 아래 표를 참고 바랍니다.

 

구분 심볼릭 링크 하드 링크
생성 명령어 ln –s [원본 파일명] [링크 파일명] ln [원본 파일명] [링크 파일명]
생성 종류 파일과 디렉토리 모두 생성 파일만 생성
링크 기능 파일 또는 디렉토리 이름에 대한 링크를 가리킴 원본 파일에 대한 참조 또는 포인터
원본 파일 삭제할 경우 액세스 불가능 액세스 가능
inode 번호 다른 inode 번호 동일한 inode 번호
다른 파티션 링크 여부 다른 파티션에 링크 가능 다른 파티션에 링크 불가능
특징 - 데이터 접근 시, 원본 i-node를 경유한다.
- 디렉터리도 가능하다.
- i-node로 바로 데이터에 접근한다.
- 디렉터리는 지원하지 않음

 

 

 

5. 사용 시기

심볼릭 링크
  1. 파일 시스템에 링크할 경우 사용합니다.
  2. 디렉토리를 링크할 경우 사용합니다.

하드 링크
  1. 저장 공간

 하드 링크 파일은 마치 용량을 점유하고 있는 것처럼 보이지만 진짜로 데이터를 복사한 것이 아니라 이미 존재하는 데이터의 위치만 가리키고 있으며 별도의 데이터를 저장하지 않기 때문에 용량을 차지하지 않습니다. 반면 심볼릭 링크는 자신이 가리키고 있는 파일의 위치를 데이터로서 저장하기 때문에 약간의 용량(보통 4KB)을 차지합니다.


  2. 성능

 다른 파일을 거치지 않고 직접 디스크 포인터에 액세스하므로 하드 링크로 액세스하면 성능이 약간 좋아짐


  3. 파일 위치 이동

 원본 파일을 같은 파일 시스템의 다른 위치로 옮기면 하드 링크는 계속 작동하지만 소프트 링크는 실패함.


  4. 안전성

 심볼릭 링크보다 하드 링크가 데이터 안전성이 우수함.

6. 관련 명령어

시스템 내에서 모든 심볼릭 링크를 찾는 명령어

$ find /etc -type l -exec ls -li {} \; 


시스템 내에서 모든 심볼릭 링크를 찾는 명령어

$ find / -links +2 -type f -exec ls -li {} \;


하드 링크의 개수를 알아보는 명령어

$ stat [파일명]


inode 번호 확인하는 명령어

$ ls -i [파일명]

 

 

 

참고 사이트

 

https://www.slashroot.in/inode-and-its-structure-linux

 

https://hippolyte.tistory.com/entry/inode%ED%95%9C-%ED%8C%8C%EC%9D%BC%EC%9D%98-%EC%B5%9C%EB%8C%80-%ED%81%AC%EA%B8%B0%EB%A5%BC-%EA%B5%AC%ED%95%B4%EB%B4%85%EC%8B%9C%EB%8B%A4

 

https://commons.wikimedia.org/wiki/File:Ufs_structure.svg

http://www.geekride.com/understanding-unix-linux-filesystem-inodes/

https://www.crybit.com/softlink-and-hardlink/

http://www.geekride.com/hard-link-vs-soft-link/

 

 

 

============================================================

본 게시물은 KOROMOON 님께서 작성하였으며 CCL (Creative Commons License) 에서 "저작자표시-비영리-동일조건변경허락" 이용조건으로 자료를 이용하셔야 합니다.

반응형