[ccibomb@CRG]# _bykim

2-4-5. EXT2 파일 시스템에서 파일 찾기

     리눅스 파일 이름은 다른 유닉스의 파일 이름과 같은 형식으로 되어 있다. 이름은 앞에 슬래시('/')가 붙은 디렉토리 이름이 이어지고 마지막에 파일 이름이 오는 형태이다. 예를 들어, 파일 이름이 /home/rusling/.cshrc이라면, /home과 /rusling은 디렉토리 이름이고 파일 이름은 .cshrc이다. 다른 모든 유닉스 시스템과 마찬가지로 리눅스는 파일 이름 자체의 형식은 신경쓰지 않는다. 길이 제한도 없고, 인쇄 가능한 아무런 문자로 구성된다. 이 파일을 나타내는 inode를 EXT2 파일 시스템 안에서 찾기 위해, 시스템은 파일 이름을 해석해서 한 디렉토리씩 처리하여 파일 자체를 얻게 된다.

     처음 필요한 inode는 파일 시스템의 루트의 inode로, 그 inode 숫자값은 파일 시스템의 수퍼 블럭에서 얻는다. EXT2 inode를 읽기 위해서는 해당하는 블럭 그룹의 inode 테이블에서 찾아야 한다. 예를 들어 루트 inode의 번호가 42라면 우리는 블럭 그룹 0의 inode 테이블의 42번 째 inode가 필요한 것이다. 루트 inode는 EXT2 디렉토리를 위한 것이다. 다시 말해서 루트 inode의 모드는 루트 inode가 디렉토리임을 나타내며 데이터 블럭에는 EXT2 디렉토리 엔트리가 들어 있다.

     home은 여러 디렉토리 엔트리 중의 하나일 뿐 이며 /home 디렉토리를 나타내는 inode의 번호를 알려준다. 이 디렉토리를 읽어서 (디렉토리를 읽으려면 우선 inode를 읽고 그 inode 가 가리키는 데이터 블럭으로부터 디렉토리 엔트리를 읽어야 한다.) rusling 엔트리를 찾으면 그 엔트리는 /home/rusling 디렉토리를 나타내는 inode의 번호를 알려줄 것이다. 마침내 우리는 /home/rusling 디렉토리를 나타내는 inode가 가리키는 디렉토리 엔트리를 읽어서 .cshrc 파일의 inode 번호를 찾은 다음, 이 번호를 이용하여 파일의 내용을 갖고 있는 데이터 블럭을 가져오게 된다.

 

※ “ /dir/file.txt “ 를 inode를 이용해 찾아가기!

1 루트 디렉토리의 inode 번호는 2번 (ext)

2 루트 inode의 index block을 통해 Dir inode를 알아냄

3 dir inode의 index block을 통해 file inode를 알아냄

4 file inode의 index block을 통해 DATA를 찾음!

2-4-1. EXT2 inode

EXT2 파일 시스템에서 inode는 가장 기본이 되는 단위이다. 파일 시스템의 모든 파일이나 디렉토리는 각기 단 하나의 inode에 의하여 표현된다. 각 블럭 그룹을 위한 EXT2 inode는 어떤 inode가 할당되었는지 아닌지를 추적하기 위한 비트맵과 함께 inode 테이블에 저장된다. <그림 2. EXT2 inode>는 EXT2 inode의 형태를 보여준다. 저장되는 정보에는 다음과 같은 항목이 있다.
 

• 모드(mode) 여기에는 이 inode가 어느 파일에 해당하는지를 나타내는 정보와, 접근권한을 나타내는 정보가 저장된다. EXT2에서 하나의 inode는 하나의 파일, 디렉토리, 심볼릭 링크, 블럭 장치, 문자 장치 또는 FIFO를 나타낸다.
• 소유자 정보(Owner Information) 이 파일 또는 디렉토리에 대한 사용자와 그룹 식별자이다. 이 정보를 이용하여 파일 시스템은 접근권한을 제대로 관리할 수 있게 된다.
• 크기(Size) 파일의 크기를 바이트 단위로 가지고 있다.
• 타임스탬프(Timestamps) inode가 만들어진 시간과 최종적으로 수정된 시간을 기록한다.
• 데이터블럭(Datablocks) 이 inode가 표현하고 있는 데이터가 저장된 블럭에 대한 포인터. 맨 앞의 열두개의 포인터는 이 inode가 표현하고 있는 데이터를 저장한 실제 블럭에 대한 포인터이며 마지막 세개의 포인터는 점점 더 높은 수준의 간접적인 연결을 갖고 있다. 예를 들어, 이중 간접 블럭 포인터(double indirect block pointer)는 데이터 블럭에 대한 포인 터들의 블럭에 대한 포인터들의 블럭을 가리키고 있다. 따라서, 길이가 12개 데이터 블럭 이하인 파일은 그 보다 큰 파일보다 훨씬 빨리 액세스 된다. Data Block 사이사이에 Directory Block 존재한다. 

EXT2 inode는 특별 장치 파일을 표현할 수도 있다는 점에 주목하여야 한다. 이들 파일은 실제 파일은 아니지만 장치를 액세스하는데 사용되는 프로그램을 다룬다. /dev 디렉토리 아래 의 모든 장치 파일은 프로그램이 리눅스 장치를 액세스할 수 있도록 하기 위하여 거기에 있는 것이다. 예를 들어 마운트 프로그램은 마운트하려는 장치 파일을 인자로 사용한다.

    2-4-2. EXT2 수퍼블럭(Superblock)

    수퍼블럭에는 그 파일 시스템의 정보(기본적인 크기나 모양에 대한 설명)가 들어 있다. 이를 이용하여 파일 시스템 관리자는 파일 시스템을 활용하고 유지한다. 보통 파일 시스템이 마운트 될 때에는 블럭 그룹 0에 들어 있는 수퍼블럭을 읽어들인다. 하지만, 모든 블럭 그룹에는 똑같은 복사본이 있어서 파일 시스템이 깨지는 경우를 대비하고 있다. 여기에 들어 있는 정보에는 다음과 같은 것들이 있다.
 

• 매직 넘버(Magic Number) 이 값은 마운트하는 소프트웨어로 하여금 이것이 진짜 EXT2 파일 시스템의 수퍼블럭이라는 것을 확인케한다. 현재 버전의 EXT2에서는 0xEF53으로 되어 있다.
• 개정 레벨(Revision Level) 메이저 개정 레벨과 마이너 개정 레벨로 구성되며, 마운트 프로그램이 어떤 특정한 버전에서만 지원되는 기능이 이 파일 시스템에서 지원되는지 아닌지를 확인하는데 사용된다. 또한 기능 호환성 항목라는 것이 있어서 마운트 프로그램이 이 파일 시스템에서 안전하게 사용할 수 있는 기능이 무엇인지를 판단할 수 있도록 해준다.
• 마운트 횟수(Mount Count)와 최대 마운트 횟수(Maximum Mount Count) 이 두 개의 값을 이용하여 시스템은 파일 시스템 전부를 검사할 필요가 있는지를 확인할 수 있다. 마운트 횟수는 파일 시스템이 마운트될 때 마다 1씩 증가하며, 그 값이 최대 마운트 횟수와 같아지면 "최대 마운트 횟수에 도달하였습니다, e2fsck를 실행하는 것이 좋습니다"라는 메시지가 표시된다.
• 블럭 그룹 번호(Block Group Number) 현재 보고 있는 수퍼블럭 복제본을 갖고 있는 블럭 그룹의 번호.
• 블럭 크기(Block Size) 이 파일 시스템의 블럭 크기를 바이트 단위로 (예를 들어, 1024 바이 트) 표시한다. 1회 I/O 가 이루어지는 양을 의미한다.
• 그룹당 블럭수(Blocks per Group) 하나의 그룹에 속하는 블럭의 수. 블럭 크기와 마찬가지로 파일 시스템을 만들때 정해진다.
• 프리 블럭(Free Blocks) 파일 시스템내의 프리 블럭의 수.
• 프리 Inode(Free Inode) 파일 시스템내의 프리 inode의 수.
• 첫번째 Inode(First Inode) 파일 시스템내의 첫번째 inode의 inode 번호. EXT2 루트 파일 시스템에서 첫번째 inode는 "/" 디렉토리에 대한 디렉토리 엔트리이다.

 

2-4-3 EXT2 그룹 기술자(Group Descriptor)

    각 블럭 그룹은 자신을 기술하는 자료구조를 가지고 있다. 수퍼블럭과 마찬가지로 모든 블럭 그룹을 위한 그룹 기술자는 각 블럭 그룹에 복제되어 파일 시스템이 파괴되는 경우를 대비한다. 그룹 기술자는 잇달아 나타나서 전체적으로는 하나의 그룹 기술자 테이블을 형성한다. 각 블럭 그룹에는 수퍼블럭 바로 뒤에 그룹 기술자 테이블 전체가 놓여있다. EXT2 파일 시스템 에서 실제로 사용되는 것은 (블럭 그룹 0에 있는) 첫번째 복사본 뿐이다. 다른 복사본들은, 수퍼블럭의 복사본들과 마찬가지로, 원본이 깨질 경우를 대비하고 있다.

 

각 그룹 기술자는 다음과 같은 정보를 갖고 있다.
 

• 블럭 비트맵(Blocks Bitmap) 이 블럭 그룹에서 블럭의 할당 상태를 나타내는 비트맵으로서 블럭의 수 만큼 있다. 이것은 블럭을 할당하거나 해제할 때 사용된다.
• Inode 비트맵(Inode Bitmap) 이 블럭 그룹에서 inode의 할당 상태를 나타내는 비트맵으로서 블럭의 수 만큼 있다. 이것은 inode를 할당하거나 해제할 때 사용된다.
• Inode 테이블(Inode Table) 이 블럭 그룹의 inode 테이블의 시작 블럭으로서 블럭의 수 만큼 있다. 각 inode는 다음에 설명하는 EXT2 inode 자료구조에 의해 표현된다.
• 프리 블럭 갯수(Free Blocks Count), 프리 Inode 갯수(Free Inode Count), 사용된 디렉토리 갯수(Used Directory Count)

 c.f) 슈퍼 블록과 그룹 디스크립터 테이블은 파일 시스템 전체에 대한 정보가 들어가기 때문에 그룹마다 똑같은 내용을 갖게 된다. (복구 용이)

 

2-4-4. EXT2 디렉토리

    EXT2 파일 시스템에서 디렉토리는 파일 시스템내의 파일에 대한 접근 경로를 만들고 저장 하는 특별한 파일이다. <그림 4. EXT2 디렉토리>는 메모리 상에서의 디렉토리 엔트리의 모양을 보여준다. 디렉토리 파일은 디렉토리 엔트리의 리스트이며 각각의 디렉토리 엔트리는 다음과 같은 정보를 갖고 있다.
 

• inode 이 디렉토리 엔트리에 해당하는 inode. 이 값은 블럭 그룹의 inode 테이블에 저장되어 있는 inode 배열에 대한 인덱스이다. 그림 9.3 에서 file이라는 이름의 파일에 대한 디 렉토리 엔트리는 i1이라는 번호의 inode를 참조하고 있다.
• 이름 길이(name length) 이 디렉토리 엔트리의 길이를 바이트로 나타낸다.
• 이름(name) 이 디렉토리 엔트리의 이름.

 

c.f) 모든 디렉토리에서 처음 두 엔트리는 항상 "." 과 ".." 이다. 이는 각각 "현재 디렉토리" 와 " 부모 디렉토리" 를 의미한다.

2-4. EXT2 파일시스템 구조 분석

<그림 3>은 EXT2 파일 시스템이 블럭 구조로 된 장치에서 블럭을 어떻게 차지하고 있는지 배치 상태를 보여준다. 파일 시스템에 관한 한 블럭 장치는 그저 읽고 쓸 수 있는 일련의 블럭일 뿐이다. 파일 시스템은 실제 매체의 어느 곳에 블럭이 씌어야 하는지에 대해 신경 쓸 필요가 없다. 그것은 디바이스 드라이버가 알아서 할 일이다. 파일 시스템이 그 파일 시스템을 담고 있는 블럭 장치로부터 정보나 데이터를 읽으려고 한다면 단지 해당 디바이스 드라이버에게 몇 개의 블럭을 읽어달라고 요청하기만 하면 된다. EXT2 파일 시스템은 자신이 차지하고 있는 논리적인 파티션을 다시 블럭 그룹으로 쪼갠다. 각 블럭 그룹은 파일 시스템에서 무결성의 핵심이 되는 정보를 중복해서 갖고 있으며, 실제 파일과 디렉토리를 정보와 데이터의 블럭으로 갖고 있다. 이 중복은 파일 시스템이 깨지는 등의 재난이 발생해서 파일 시스템의 복구가 필요할 때 필수적이다.

 

 2-3-5. inode 와 파일의 생성, 링크, 삭제 (ext2)

 

i.             파일의 생성
새로운 파일이 만들어지면 그에 해당하는 inode가 i-list안에 만들어지며, 그 inode의 inumber와 파일 이름이 디렉토리에 등록된다.

 

# df -i : 사용할수 있는 inode의 값이 0이면 아무것도 생성할수 없다.

ii.            파일의 링크
이미 존재하고 있는 파일을 링크시킬 경우는 디렉토리에 그 파일에 대한 새로운 이름이 등록되고, inumber는 본래 있던 파일의 inumber가 복사된다. 이 때 복사되는 파일의 inode에서 파일의 링크수는 하나 증가하게 된다.

iii.          파일의 삭제
파일을 삭제하면 그 파일에 대한 inode의 파일 링크수가 하나 감소되고 디렉토리 entry에서는 해당 파일의 inumber가 zero로 변한다. inode의 파일링크수가 zero가 되면 파일의 디스크 블록은 free가 되며 inode는 dellocate 된다.

 

è  따라서 inode에 담긴 정보가 손상되지 않았다면, 파일은 사용 가능하다. 즉, 삭제된 파일이 복구가능한 것이다. ext2에서는 파일을 삭제 해도 inode는 파일 내용의 데이터블록들의 주소를 가지고 있으므로 새로운 파일이 삭제된 파일 위에 덮어 씌어지지 않는다면, 복구 가능하다.

 

 2-3-6. 해당 파일의 "inode"는 어떻게 찾는가

바로 "Directory Block"을 이용하는 것이다. 이 디렉토리 블럭은 데이터 영역에 존재한다. inode가 메타데이터 영역에서 데이터 영역으로의 포인터 정보를 담고 있다면, Directory Block은 반대로 데이터 영역에서 메타데이터 영역으로의 포인터 정보를 담고 있다. Directory Block의 데이터 영역은 형식이 정해져 있으며, Directory 밑에 있는 파일에 대한 inode 숫자가 담겨 있다.

c.f) EXT 파일시스템에서는 2번 inode가 루트 디렉토리를 연결시켜 주다.

 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" 만 찾게 된다면, 해당 파일의 메타데이터와, 파일의 데이터까지도 모두 찾을 수가 있게 디자인되어 있다.

1. 의의

누구나 한번씩은 중요한 자료를 실수로 삭제해 곤란해 한적이 있을 것이다. 리눅스 파일시스템의 특성상 일단 삭제한 파일을 복구한다는 건 굉장히 어려운 것으로 알려져 있다. 막상 시스템에서 중요한 파일을 자기도 모르게 삭제했을 때는 당장 쓸 수 있는 방법이 거의 없는 것이 사실이다. 본 문서에서는 이러한 상황에서 쓸 수 있는 방법을 소개하도록 한다.

더 나아가, 누군가 고의로 파일을 삭제한 경우에도 이를 활용하여 해당 파일을 복구해내는 것이 가능하다. 가령 해킹 후 로그파일이 조작된 경우, 이를 조작한 삭제된 스크립트 파일을 복구해내는 것이 가능하다. 즉, 디지털 포렌식의 분야로도 확장 가능한 것이다.



2. 이론

2-1. FILE의 개념

"File"은 파일 시스템이 생각할 수 잇는 가장 최상위의 정보라고 볼 수 있다. 일명 "a sequence of bytes" 라고 한다. 사용자가 보기에는 "연속된 바이트"에 불과한 것이지만, 파일 시스템 입장에서는 "전혀 연속되지 않지만, 그렇게 보이도록" 추상화해 줄 필요가 있다. open, read, write, close 등의 system call은 모두 "file" 을 대상으로 한 일종의 file system API 라 부를 수 있겠다.

사용자가 "a.txt" 라는 파일을 열어서, 내용을 저장했다고 하자. 그러면 사용자가 저장한 내용 "이외의 내용"이 파일 시스템에 의해 추가로 저장된다. 이것이 바로 메타데이터라는 것이다. 파일유형, 퍼미션(Permission), 소유자, MACtime(마지막 수정, 접근, 변경시각), 실제파일의 크기(size), 파일의 위치 등을 포함하고 있다. 이러한 메타데이터들은 파일시스템마다 다르게 디자인되어 있다.
 (ext2 같은 경우는 매우 간결하고 고정된 속성들을 담도록 디자인 되어 있고 NTFS같은 경우는 매우 다양한 속성들을 담을 수 잇게 되어 있다.)

실제데이터 영역은 말 그대로 실제 파일의 정보가 저장되는 공간이다. 파일시스템마다 서로 다른 할당단위를 가지고 있으며 기본적으로 블록을 이용한다. 디폴트 값은 4k 등이며, 할당단위로 인해 Internal Fragments 라는 Slack Space (할당되었으나 사용되지 않는 공간)이 발생하게 된다.