[ccibomb@CRG]# _bykim

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 (할당되었으나 사용되지 않는 공간)이 발생하게 된다.