1.파일 시스템 일반
메모리 관리기법과 파일 시스템 모두 내/외부 단편화를 최소화하기 위해 노력합니다.
쉽게 생각하면 파일 시스템은 메모리 관리 기법에 '이름'이 추가된 것으로 생각할 수 있습니다.
실제로 파일 시스템이 하드디스크에 저장하는 정보는 메타데이터(정보의 정보로 파일이름, 생성시간과 같은 부가적인 정보를 말합니다.)와
사용자 데이터로 구분할 수 있습니다.
2.디스크 구조와 블록 관리 기법
하드디스크는 plotter, arm, head 등으로 이루어져 있습니다. 이들은 디스크의 물리적 특성을 결정합니다.
plotter에는 원모양의 track이 있고, 이 track들이 모여 cylinder를 이룹니다. track은 512byte 단위의 sector로 구분됩니다.
디스크에서 데이터를 접근하는데 걸리는 시간
탐색시간 : 요청한 데이터가 존재하는 track 위치까지 이동하는데 걸린 시간
회전 지연 시간 : 요청한 sector가 head 아래로 위치 될 때까지 디스크 plotter를 회전시키는데 걸리는 시간
데이터 전송 시간 : head가 sector의 내용을 읽거나 또는 기록하는데 걸리는 시간
파일 시스템은 디스크를 물리적 구조가 아닌 논리적인 디스크 블록(sector들의 모임)의 집합으로 간주합니다.
일반적으로 디스크 블록의 크기는 페이지 프레임(물리 메모리의 최소 단위)의 크기와 같습니다.
파일 시스템 성능의 최대 병목 요소는 디스크 I/O로 디스크 블록의 크기를 크게 설정하여 이를 해결합니다.
디스크 컨트롤러(장치 드라이버)는 디스크 블록 번호와 섹터를 매핑(mapping)하여 관리합니다.
예를 들어 블록이 4KB이고 섹터 크기가 512byte라면 하나의 디스크 블록에는 8개의 섹터가 관리됩니다.(??)
디스크 블록의 할당과 회수가 어떻게 일어나는지 알아보겠습니다.
할당에는 연속과 불연속 기법 크게 두 가지로 나누어 집니다.
연속 : 읽는 속도가 빠르지만 블록이 할당되고 나서 파일의 크기가 커질 경우
불연속 : 블록체인, 인덱스블록, FAT 등이 있습니다.
블록체인 : 체인으로 연결 임의접근 불가능, 유실 시 데이터를 모두 잃음.
인덱스블록 : 인덱스블록을 따로 사용함으로 인덱스 블록 할당에 대한 문제가 존재함.
인덱스 블록 유실 시 전체 소실.
FAT : 인덱스블록을 하나로 합친 개념. FAT 유실 문제로 인해 FAT를 중복 관리.
★리눅스에서 이용하는 ext2, ext3는 인덱스 블록 기법과 유사한데 이를 inode라고 부릅니다.
3.FAT 파일시스템
FAT 파일 시스템을 이용하는 대표적인 시스템 msdos의 FAT 파일시스템에 대해 알아보겠습니다.
msdos의 FAT 시스템에선 각 파일마다 디렉터리 엔트리를 갖습니다. 이 디렉터리 엔트리가 모여 디렉터리를 구성합니다.
결국 디렉터리는 디렉터리 엔트리들이 모여서 이루어진 특수한 파일에 불과합니다.
msdos의 디렉터리 엔트리에는 파일이름과 확장자, 속성과 시간 정보, 크기, FAT 데이터 블록에서의 첫 블록과 같은 정보를 포함합니다.
이는 다른 시스템에서도 비슷합니다.
(아마 msdos가 아닌 다른 곳에서 구현된 FAT 시스템도 비슷하다는 뜻으로 생각됩니다.)
그렇다면 파일 시스템은 디렉터리 엔트리를 어떻게 찾는 것일까요?
아래의 그림은 디렉터리 엔트리를 표현한 것입니다.
한 파일의 경로를 표현하는 방법에는 절대경로와 상대경로 두 가지 방법이 있습니다.
절대경로는 파일의 경로를 root부터 표현한 것이고
상대경로란 파일의 경로를 현재 디렉터리를 기준으로 표현한 것입니다. (상대경로 이게 맞나?)
절대경로 /home/member/kjh/약속.txt 로 표현된 경로를 찾아가는 방법에 대해 알아보겠습니다.
우선 root의 디렉터리 엔트리 번호를 읽어 (root의 경우 특별히 슈퍼블록에 이 정보를 기록해 둡니다.)
(슈퍼블록에 sector 크기, sector가 모인 cluster크기, FAT 테이블 위치 크기 등등)
root가 가지고 있는 디렉터리 엔트리들을 읽습니다. 여기서 다음 경로인 home의 데이터 시작 주소 11번을 읽어
11번부터 데이터를 읽어보면 member의 데이터 시작 주소를 알 수 있게 됩니다.
이렇게 member도 읽고 kjh의 데이터 시작 주소를 알아내 이 부분의 데이터를 읽게 되면
읽고자 하는 파일의 데이터 시작 주소를 알 수 있게 됩니다.
4.inode 구조
ext2와 ext3에서 채택한 inode 구조에 대해서 알아보겠습니다.
ext2의 inode 구조 입니다.
구조체 필드 | 역할 |
i_block | 이 파일이 몇 개의 데이터 블록을 가지고 있는지 |
i_mode | 이 inode가 관리하는 파일의 속성 및 접근 제어 정보 유지 |
i_links_count | 이 inode를 가리키는 파일의 수 |
i_uid | 파일을 생성한 소유자의 user ID |
i_gid | 파일을 생성한 소유자의 group ID |
i_atime | 파일에 접근한 시간 |
i_ctime | 생성시간 |
i_mtime | 수정시간 |
i_block[15] | 12개는 직접 데이터를 가리키는 블록 나머지 3개는 간접블록으로 13번은 single index 14번은 double index 15번은 triple index |
여기서 i_mode 필드에 대해선 특별히 더 자세히 알아보겠습니다.
총 16비트로 이루어진 이 필드는 다음과 같은 구조를 갖습니다.
세로로 보시면 됩니다.
비트 이름 | 역할 |
type(4bit) | 파일의 타입 정보 |
u | set User id 파일이 수행될 때 수행시킨 태스크의 소유자 권한이 아닌 파일을 생성한 사용자의 권한으로 동작할 수 있도록 하는 것. |
g | set Group id로 위의 u비트와 같은 역할 |
s | 디렉터리 접근제어에 사용, 태스크가 메모리에서 쫓겨날 때 swap 공간에 위치되도록 할 때, stick 비트 |
r | user의 read가 가능하면 set 불가능하면 unset |
w | user의 write가 가능하면 set 불가능하면 unset |
x | user의 execute가 가능하면 set 불가능하면 unset |
r | group의 read가 가능하면 set 불가능하면 unset |
w | group의 write가 가능하면 set 불가능하면 unset |
x | group의 execute가 가능하면 set 불가능하면 unset |
r | other의 read가 가능하면 set 불가능하면 unset |
w | other의 write가 가능하면 set 불가능하면 unset |
x | other의 execute가 가능하면 set 불가능하면 unset |
'리눅스 커널 Linux kernel' 카테고리의 다른 글
5장 파일 시스템과 가상 파일 시스템 - 2 (0) | 2013.07.30 |
---|---|
우분투 vim 플러그인 설치 – nerd tree (0) | 2013.07.27 |
4장 메모리관리 - 2 (0) | 2013.07.24 |
4장 메모리 관리 -1 (0) | 2013.07.20 |
3장 태스크 관리 - 1 (0) | 2013.07.18 |