유닉스와 리눅스 시스템은 모두 inode를 사용하며, inode는 유닉스 운영체제에서 사용하는 자료 구조로, 파일 시스템 내부에 파일을 유지하는 중요한 정보를 담고 있다. 유닉스에서 파일 시스템을 생성할 때, 수 많은 inode 집합을 생성한다. 일반적으로 전체 파일 시스템 디스크 용량의 대략 1% 정도가 inode 테이블에 할당된다.
ext2파일시스템에서 inode는 block과 더불어 가장 기본이 되는 단위이다. 파일시스템의 모든 파일이나 디렉토리는 각기 하나의 inode가 할당되어 있다. 각 블록 그룹을 위한 ext2 inode는 어떤 inode가 할당되었는지 아닌지를 확인하기 위한 inode bitmap과 함께 inode table에 저장된다.

우리는 여기서 Ext2 디스크 자료구조에서 inode를 살펴보자.

ext2 inode

<inode의 구조>


한가지 알아둘 점은 inode 구조는 유닉스 구현 버전에 따라 다르다.
위 그림으로 간단하게 설명하겠다.

mode : 파일의 유형 및 접근 모드
owners : 파일의 소유주 및 그룹 접근 식별자
timestamps : 파일 생성시간, 가장 최근에 읽히거나 쓰인 시간, 그리고 inode가 시스템에 의해 가장 최근에 갱신된 시간
size block : 파일크기(바이트 단위), 4byte
count : 파일을 가리키는 디렉토리 항목의 수
direct blocks : 12개의 직접 지절 블록, i_block[0]~i_block[11]
single indirect : 단일 간접 지정 블록, i_block[12]
double indirect : 이중 간접 지정 블록, i_block[13]
triple indirect : 삼중 간접 지정 블록, i_block[14]
직간접 데이터 블록을 가리키는 포인터 배열, int형 15개 4x15=60byte

블록 크기 값은 통상 파일 시스템의 블록 크기와 동일하지만 때때로 그보다 클수 있다.
보통 4096바이트(4 KB)이다. 블록 크기는 4096바이트 보다 크거나 같은 임의의 2의 멱승 값을 사용할 수 있다. 일반적인 파일 시스템의 경우, 블록 크기로 8 KB 또는 16 KB가 선정된다.


파일할당
파일 할당은 블록 단위로 이루어진다. 동적으로 이루어지며 블록들이 인접할 필요는 없다.

i_block 배열은 파일 데이터가 있는 실제 블록을 가리키기도 하며, 파일 데이터를 가리키는 위치 블록을 가리키기도 해서 직,간접적으로 파일 블록을 가리킨다. 즉 커널이 파일을 저장장치에 기록할때 i_block 배열에는 파일의 데이터가 기록되어 있는 블록의 번호가 저장된다.

i_block 배열의 크기가 15이므로 배열만으로는 15개의 블록밖에 가리킬 수 없다.
만약 파일 크기가 block size x 15 보다 크다면?
block size를 4kb로 가정하자. 60kb의 용량을 가진 파일이 있다면 i_block[0]~i_block[11]까지는 실제 파일 데이터가 있는 블록을 가리킨다. 그리고 48kb가 넘어가는 데이터부터는 데이터의 블록 위치를 i_block[12]에서 가리키는 것이 아니라 i_block[12]가 가리키는 블록의 데이터가 바로 실제 데이터를 가리키는 포인터 배열이 된다. 즉 13번째 블록에 들어갈 데이터의 주소는 i_block[12]가 가리키는 블록의 첫 4byte가 되는 것이다. 마찬가지로 14번째 블록에 들어갈 데이터 주소는 i_block[12]가 가리키는 블록의 5~8번째 byte가 된다.

위 그림을 보면 i_block[12]가 가리키고 있는 블록은 파일 블록이 아닌 파일 블록을 가리키고 있는 위치 블록이다. 앞서 블록의 크기를 4kb로 가정하였으므로 위치블록은 1024개의 파일 블록을 가리킬 수 있다. 그러므로 i_block[12]를 통해 기록할 수 있는 데이터의 크기는 4096kb가 된다. 따라서 크기가 60kb인 파일을 읽어오는 경우에는 i_block[0]~i_block[11]까지 48kb를 읽어 들이고, 나머지 12kb는 i_block[12]가 가리키는 위치 블록 내의 상위 12byte(3개)의 블록 번호가 가리키는 파일 블록을 찾아가면 된다.

그렇다면 i_block의 상위 13개의 배열을 통해 1072kb가 넘는 파일은 어떻게 저장될 수 있을까? i_block[13]과 i_block[14]를 이용하여 위치블록을 더 늘이면 된다.
i_block[13]에서는 위치 블록의 개수가 늘어난 만큼 1024의 제곱의 크기로 파일 블록을 가리킬 수 있기 때문에 그만큼 기록할 수 있는 파일의 크기가 커지는 것이다.
i_block[13]의 경우 파일의 최대 크기는 1024kb x 1024kb가 되고, 총 1gb를 저장할수 있으며, i_block[14]의 경우 1gb x 1024kb 이므로 1tb를 저장할수 있다. 따라서 블록의 크기가 4kb인 경우 하나의 inode에서 저장할 수 있는 파일의 크기는 '48kb + 1024kb + 1gb + 1tb'가 되는 것이다.

이런 메커니즘은 작은 파일에 더 유리하다. 파일이 데이터 블록을 12개 이상 요구하지 않고 디스크에 두 번만 접근하면 모든 데이터를 얻을 수 있다. 한 번은 inode의 i_block 배열의 요소를 읽기 위해, 다른 한번은 요청한 데이터 블록을 읽기 위해서 이다. 더 큰 파일일 경우 요청한 블록을 읽으려면 연속적인 디스크 접근이 세 번 또는 네 번 정도 필요하다.

하지만 이는 파일시스템의 역량이고, 실질적으로 파일시스템을 직접 접근해서 사용하는 커널의 역량에 따라서 사용 용량의 크기가 달라지게 된다. 예를 들어 32bit 변수를 이용하여 주소 지정을 하는 경우 최대 4gb까지만 사용이 가능하며, 이것도 부호지정이 가능한 변수(signed)라면 반으로 줄어 들어 2gb까지만 사용이 가능하다.




참고자료
리눅스 커널의 이해, O'REILLY
임베디드 개발자를 위한 파일시스템의 원리와 실습, IT EXPERT
파일시스템 ,http://www.nortul.com/linux/kernel/kernel9.html
http://www.ibm.com/developerworks/kr/library/au-speakingunix14/index.html

'컴퓨터공학' 카테고리의 다른 글

텍스트큐브 백업, 복원하기  (3) 2010.01.07
하루는 내가 쓴 글이 피드가 안된다는 사실을 깨닫고 고치기 시작했다.
이런 저런 방법을 해보다가 업글을 하든지 새로 엎으면 된다고 해서
우선 데이터를 백업하고 (xml 파일 40메가정도) 새로 엎었다.
원래 쓰던 버전은 1.7.7이었는데 1.8.1로 업글을 했는데
설치 과정중에 PHP버전이 낮다고 안되는 것 이었다. (1.8.1은 5.2이상 버전 설치)
우리 서버는 분명 5.2.5인데 5.1.6으로 설치 되어있다고 다음으로 안넘어 갔다.
왜 이렇지 하는 생각도 잠시! 다시 1.7.7 버전으로 깔았다.
하지만 CHECKUP이 안되면서 1.8.1 버전에서 1.7.7 버전으로 한다고
에러가 나는 상황이었고, 결국 특단의 조치로
다 지우고 DB도 지우고 1.7.8버전으로 새로 설치했다.
------------------------------------------------------------------------
문제는 여기서 부터
++

새로 초기 블로그가 설치가 되었다.
이제 백업해놨던 XML파일을 복원만하면 끝나는 문제.
하지만 복원이 제대로 안되는 것이었다.
우선 16MB이상의 파일은 바로 올려지지 않았고,
다음이나 네이버의 대용량 메일의 주소를 링크해서 하여도 제대로 되지 않았다.
(복원파일 업로드시 에러가 나고, 파일이 잘못되었다는 다수의 메시지)
몇번이나 삽질을 한 끝에 한가지 꽁수로 복원에 성공하였다.

++
(나는 여기서 텍스트큐브에서 완전히 새로 설치 하지 않고
기존의 자료는 그대로 두고 새로 core만 바꿀려고 하였다.)

우선 데이터 백업을 첨부파일 포함하여 다운로드하면
Textcube-Backup-20100106.xml 같은 파일이 만들어 진다.
서버에 저장하면 /tc/cache/backup/1.xml 이라는 파일이 만들어진다.
사용자 삽입 이미지

관리자 모드로 들어가서 (설정-데이터관리에 가보면 백업과 복원 메뉴가 있다)
전에 다운로드 받아놓은 Textcube-Backup-20100106.xml 파일이 있을것이다.
하지만 용량이 40mb가 넘기 때문에 백업파일 올리기로는 올릴 수가 없다.
그리고 웹에서 백업파일 가져오기 하면 이상하게 에러가 나고 제대로 되지 않았다.

그래서 고민고민하던중.

사용자 삽입 이미지

/tc폴더를 그냥 다 지워버리고 db테이블도 모조리 다 지웠다.
(db테이블을 놔두고 재설정을 하면 설치가 제대로 되지 않는다.)
그리고 새로 설치하였다. (처음에 설치했던 그대로... 환영메시지가 나오고..)

++
서버에 저장된 백업파일 메뉴가 현재 설치한 상태에서는 없다.
생기게 할려면 (데이터백업-첨부파일포함-서버에 저장)을 한다.(초기상태에서)
그러면 /tc/cache/backup/1.xml 파일이 생긴다 (약 3mb 용량)
그럼 위에 서버에 저장된 백업파일이라는 메뉴가 생기는데
ftp로 /tc/cache/backup/ 폴더에 Textcube-Backup-20100106.xml 파일을
1.xml로 바꾸어서 ftp에 올려 덮어 쓴다.
그리고 서버에 저장된 백업파일을 복원하기 실행하면
약 1~2초에 깔끔하게 복원이 된다.

++
정리

기존에 xml파일을 백업해놓고 이래저래 에러가 많이 났다면
그냥 다 지우고 블로그를 새로 설치한 다음 위와 같은 방법으로 하면
별다른 에러없이 간단하게 복원이 된다.

++

6시간 넘도록 검색을 하며 원인을 찾아봤는데
혹시나 비슷한 이유였다면 이 글을 보고 잘 고치길 바랍니다. ^^

'컴퓨터공학' 카테고리의 다른 글

inode에 대해서 알아보자  (1) 2010.02.11
BLOG main image
안녕하세요! 천재호랑이입니다 @.@ by 천재호랑이

카테고리

천재호랑이 (33)
opinion (15)
computer (0)
여행 (1)
책소개 (8)
영화 (0)
컴퓨터공학 (2)
건강과운동 (7)
SNS (0)
갤럭시S (0)
untoC (0)
자격증 (0)
어학 (0)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

Total :
Today : Yesterday :