[ccibomb@CRG]# _bykim

 2-3-3. 유닉스 시스템(ext2)에서 inode를 이용한 File Addressing 

유닉스에서 디스크는 일정한 크기의 블록으로 나누어져 있으며, 각 파일이 디스크의 공간에 할당될 때도 정해진 크기의 블록으로 할당되어 사용된다. inode는 파일의 구성 블럭에 대한 물리적 위치가 포함되어 있다. 블록들의 물리적 위치를 기록하기 위하여 직접 어드레싱(Direct Addsressing) 및 간접 어드레싱(Indirect Addressing)이 사용 되고 있다.

inode에 있는 블록위치에 대한 정보는 13개의 필드로 되어 있다. 필드 0부터 필드 9까지는 직접 블록을 어드레싱하는 부분이다. 즉, 각 필드 내에 있는 내용은 디스크의 주소를 포함한다. 처음 10개의 블록은 이러한 방식으로 어드레싱 되며, 유닉스 내에 있는 파일의 크기는 대부분 작기 때문에 10개의 블록으로도 충분하지만, 방대한 파일인 경우에는 필드 10(Indirect Bolocks), 11(Double Indirect) 또는 12(Triple Indirect)가 사용된다. 각각은 1, 2, 3차 간접 어드레싱 방법을 사용하게 된다. 필드 10은 실제의 어드레스가 있는 블록의 어드레스 즉, 주소의 주소를 가지고 있으며 어드레스 수를 통산 256개의 주소를 기록할 수 있다. 그러므로 필드 10은 실제주소가 있는 곳을 가리키고, 필드 11은 이중간접어드레스 필드를, 12는 삼중 어드레스를 각각 저장하고 있다. 이러한 방법에 의해 어떠한 크기의 파일이라도 유닉스에서 모두 다루어 질 수 있다.

 

 2-3-4. inode 와 파일 크기, 파일 개수

한 inode의 크기는 64byte이며, 파일은 블럭들로 구성되어 있다.

한 블록의 크기가 1K이고 블록의 주소가 4바이트로 표현 가능하다면 한 블록은 256개의 블록 주소를 포함한다. 따라서 inode의 Indirect, Double Indirect, Triple Indirect Addressing 을 이용하면, 16 gigabyte 크기의 파일까지 표현 가능하다.

1K 블록을 표현할 수 있는 10개의 direct 블록(10K)   256개의 direct 블록을 가리키는 1개의 indirect 블록(256K)   256개의 indirect 블록을 가리키는 1개의 double indirect 블록(64M)   256개의 double indirect 블록을 가리키는 1개의 triple indirect 블록   (16G = 1K * 256 * 256 * 256)

c.f) inode의 파일 크기 필드가 32비트인 경우 실제 파일 크기는 4 gigabytes로 제한된다.(2^32)

따라서 파일 시스템에서 “inode의 개수 = 파일의 개수”라고 볼 수 있다.
    (inode table의 size 는 파일 시스템 생성시 설정 가능하다.)

 

2-3. “inode”에 대하여 더 알아보자

2-3-1. inode, i-list, inumber 의 개념 구분

파일이나 디렉토리는 그에 해당하는 하나의 inode를 가지고 있으며, 이 inode는 그 파일에 대한 모든 정보를 가지고 있다. (inode size = 64byte)
또한 이 inode를 가지고 잇는 표를 시스템 inodeTable라고 한다.
어떤 한 파일이나 디렉토리가 생성되면 하나의 inode가 만들어지고
그 inode가 inodeTable에 등록되며, 등록되는 entry-number를 그 inode에 대한 inumber라 핚다.



2-3-2. inode의 내용

inode는 파일이나 디렉토리의 모든 정보를 가지고 있는 자료구조를 말하며, 64byte로 구성되는 표로서 유닉스 시스템은 각 파일에 대한 하나의 inode를 할당한다. 기본적으로 inode는 파읷의 실제 이름과 파일의 실제 내용을 제외한 파일에 대한 모든 정보를 담고 있다. 이런 정보 없이는 파일이 손상당하거나 사용 불가능한 상황에 놓인다.

디렉터리와 파일은 다른 운영체제와 비교해서 유닉스 시스템에서 조금 다르게 보일지도 모르겠지만 그렇지 않다. 유닉스에서 디렉터리는 실제로 inode에 몇 가지 추가 설정이 가해진 파일이다. 디렉터리는 기본적으로 다른 파일을 담고 잇는 파일이다. 또한 모드 정보는 파일이 실제로 디렉터리라는 사실을 시스템에 알리는 플래그 집합을 포함한다.

-> 파일소유권과 이용가능 여부
    파일 내용이 들어있는 디스크 내의 물리적 주소
    파일의 링크수
    파일의 형태
    파일의 크기
    파일의 만들어진 시각, 최근 사용시각, 최근 수정시각
    inode의 최근 수정시각

2-2. 파일 시스템의 FILE 관리 by “inode” !!

파일 시스템은 "데이터"와 "메타데이터"를 관리해야 한다. 참고로 ext2의 경우에는 메타데이터 영역이 데이터 영역의 1% 정도만을 차지하는데, 메타데이터는 작은 편이 여러모로 좋다. replication에도 유리하고, disk pointer corruption 같은 문제에도 비교적 견고해질 수 있기 때문이다.
따라서 파일 시스템은 "데이터"와 "메타데이터" 영역을 분리해서 관리하는 경우가 많으며, ext2의 경우에는 완전히 두 영역을 나누어서 관리하고 있다.

(참고 : 파일 시스템이 특정 파일을 접근하기 위해서는 "데이터" 영역과 "메타데이터 영역"을 동시에 접근하는 경우가 많은데, 여기서의 disk seek을 줄이고자 전체 주소 영역을 block group 단위로 나누어서 이 안을 다시 데이터와 메타데이터 영역으로 나누는데, 이것이 FFS의 cylinder group 아이디어이다. ext2는 FFS의 후계자 정도 된다.)

즉, 한 파일의 정보가 두 영역에 나누어 존재하게 된다. 데이터는 "데이터 영역", 메타데이터는 "메타데이터 영역". 이 둘을 연결해주는 역할을 하는 것이 바로 "inode(아이노드)" 이다.

inode는 ext2 파일 시스템에서 한 파일의 메타데이터 정보를 담아주는 데이터 구조이며, 메타데이터 영역에 저장된다. 이 inode에는 데이터 영역을 가리키는 일종의 포인터가 저장되어 있어, 특정 파일의 "inode" 만 찾게 된다면, 해당 파일의 메타데이터와, 파일의 데이터까지도 모두 찾을 수가 있게 디자인되어 있다.