파일 시스템
파일
파일은 논리적인 저장 단위로, 관련된 정보 자료들의 집합에 이름을 붙인 것이다. 하드 디스크나 SSD같은 비휘발성 보조기억장치에 저장된 정보의 집합이다. 논리적으로는 Byte 단위로 저장되어 있다고 볼 수 있지만, 실제 물리적으로는 Block 단위로 Disk에 저장되어 있는 것이다. 이러한 Block들이 Disk 여러곳에 흩어져 있는데 파일은 흩어진 관련된 Block들을 모아놓은 것이라고 할 수 있다. 모든 파일에는 이름과 파일 실행을 위한 부가정보가 있고, 이 부가정보를 속성, 메타데이터라고 한다.
메타 영역에는 데이터 영역에 기록된 파일의 이름, 위치, 크기, 시간정보, 삭제유무 등 파일의 정보가 들어있고, 데이터 영역에는 실제 파일의 데이터가 들어있다.
파일 시스템
운영체제와 모든 데이터, 프로그램의 저장과 접근을 위한 기법을 제공한다. 시스템 내의 모든 파일에 관한 정보를 제공하는 계층적 디렉터리 구조이다. 파일 및 파일의 메타데이터, 디렉터리 정보 등을 관리한다. 또한 파이르이 저장 방법을 결정하고 파일을 보호해준다.
파일 접근 방법
1. 순차 접근
가장 단순한 방법으로 파일의 정보가 레코드 순서대로 처리된다. 편집기나 컴파일러는 보통 이러한 방식으로 파일에 접근한다.
카세트테이프를 사용하는 방식과 동일하다. 현재 위치에서 읽거나 쓰면 offset이 자동으로 증가하고, 뒤로 돌아가기 위해선 되감기가 필요하다.
읽기와 쓰기가 파일 연산의 대부분을 차지하고 있으며 자동으로 입출력 위치를 추적하는 파일 포인터를 증가시킨다.
2. 직접 접근
파일의 레코드를 임의의 순서로 접근할 수 있다. LP 판을 사용하는 방식과 동일하다.
3. 색인 접근
파일에서 레코드를 찾기 위해 색인을 먼저 찾고 대응되는 포인터를 얻는다. 이를 통해서 파일에 직접 접근하여 원하는 데이터를 얻을 수 있다. 대용량 파일의 경우 색인 파일 그 자체도 매우 크기가 커질 수 있기에 색인 파일에 대한 또 다른 색인을 생성하여 다루기도 한다.
디렉토리
디렉토리
디렉토리는 효율적인 파일 사용을 위해서 파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일이다. 그 디렉토리에 속한 파일 이름 및 파일 속성을 가지고 있다. 또한 search, create, delete, list, rename, traverse 등의 연산을 수행할 수 있다.
디렉토리는 파일을 빠르게 찾을 수 있도록 하는 Efficiency, 파일의 이름을 지을때 제약 조건이 없도록 해주는 Naming, 유사한 파일들을 그룹지어주는 Grouping 등의 기능을 제공해준다.
디렉토리 구조
1. Single level(Flat) Directory
- 하나의 파일에 하나의 디렉토리만 있는 구조
- 디렉토리가 없는 것과 다름 없음
- 파일 이름, 파일 보호, 파일 관리 등의 문제가 존재한다.
- 디렉토리가 하나뿐이면 모든 파일의 이름이 달라야 하기에 불편함 (Naming 문제 발생)
- 다중 사용자 시스템의 경우 서로의 파일을 구분하기 어려움(Grouping 문제 발생)
2. Two level Directory
- n명의 사용자가 있다면, 사용자별로 n개만큼 디렉토리가 있는 경우이다.
- 서브 디렉토리는 만들 수 없다.
- 사용자간의 파일 구분 문제는 해결되었으나 이 이상의 서브 디렉토리가 없기에 여전히 문제가 발생한다.
- 다른 사용자라면 Naming 문제 부분 해결, Grouping 문제 남아있음
3. Tree Structure Directory
- 트리 구조를 가지는 디렉토리이다.
- 유저들은 각자의 서브 디렉토리를 생성할 수 있다.
- 다양한 용어들이 생겼다. (home directory, current directory, absolute pathname, relative pathname 등)
- 디렉토리 생성, 제거, 변경 등을 위한 인터페이스가 제공되어야 한다.
- 논리적 Grouping 가능, 효율적 탐색 가능
4. Acyclic-graph(비순환) Directory
- 방향성이 없는 사이클 그래프를 갖게되는 구조의 디렉토리이다.
- 유닉스에서의 링크로 인해 방향이 없는 사이클이 생기게 된다.
- hard link : ln
- soft link : ln -s
- ln a b 커맨드는 a를 b로 링크 걸라는 의미이고 a 파일과 b 파일이 같은 메타데이터 즉 inode를 공유하게 된다. 이 경우 한 파일에 이름을 두 개 준 것이나 다름없다. 같은 파일 a가 접근 가능한 경로 2가지를 갖게 되기에 방향이 없는 사이클이 생기게 된다.
- 심볼릭 링크라고 표현하는 공유 서브 디렉토리나 공유 파일을 가지게 된다.
- 파일 삭제시 danding pointer(대상이 없는 포인터)를 남기지 않도록 해야한다.
5. General graph Directory
- 방향이 존재하는 사이클을 갖게 되는 구조의 디렉토리이다.
- 파일 탐색시 무한루프를 반드시 고려해야 한다.
- 파일에 대한 링크만 허용하는 등의 조치가 필요하다.
- 가비지 컬렉션을 사용하는 방법도 있다.
파일 할당
1. 연속 할당
연속 할당이란 연속된 블록에 파일을 할당하는 것이다. 예를 들어, 블록의 크기가 1KB라고 하고, 할당할 파일은 f1, f2, f3 3개가 있으며 각각의 크기를 5KB, 3KB, 4KB라고 하자.
이때 연속 할당을 수행하게 된다면, 위와 같은 사진의 형태가 될 것이다. 연속 할당의 장점은 디스크 헤더의 이동을 최소화할 수 있어 I/O 성능을 높일 수 있다는 것이다. 예전 IBM에서 사용하던 방법이고 주로 동영상, 음악, VOD에 적합하다.
또 위에서 나왔던 순차 접근과 직접 접근이 가능하다는 특징이 있다. (직접 접근이 가능한 이유는 운영체제가 파일의 정보를 디렉토리에 저장하고 이때 파일의 시작 블록 번호를 저장하기 때문이다. 따라서 이 시작 블록 번호를 이용하여 직접 접근이 가능하다!)
하지만 파일을 할당하고 삭제하고를 반복하며 hole이 생기게 되는데 연속 할당은 연속된 공간을 찾아야 하기에 외부 단편화 문제가 발생한다. 또 파일의 크기는 가변적이어서 실제 필요한 파일의 크기를 알 수 없기에 생기는 단점이 있다. 파일을 저장할 때 계속해서 사용하는 파일의 경우 크기가 계속 증가할 수 있기 때문에 연속 할당은 부적절하다고 할 수 있다.
2. 연결 할당
연결 할당은 연속 할당의 문제점을 해결하기 위해 나온 방법으로 연속적으로 할당하는 것이 아니라 링크드 리스트와 같은 방식으로 파일을 할당한다. 블록의 크기가 1B이고, 파일 f1의 크기가 5B일때 연결 할당을 수행하면 다음과 같다.
각 블록의 마지막에 주소를 저장하는 포인터 공간(4B)이 존재하며 여기서 다음 블록을 가리키고, 마지막 블록의 포인터 공간에는 끝임을 나타내는 값을 저장한다.
첫 블록은 임의로 선택하며 파일의 길이가 커질 경우 새로운 블록에 할당하고 기존의 블록과 연결만 해주면 되기에 위치에 제약이 없으며 외부 단편화 문제가 사라진다.
하지만 파일의 블록이 모두 흩어져 있어 직접 접근이 불가능하고 포인터를 저장하는 공간에 대해 손해가 발생하며 포인터가 끊기면 이후의 모든 블럭에 접근이 불가능하고 모두 흩어져 있어 디스트 헤더의 움직임이 많이 발생한다는 단점이 있다.
3. FAT(File Allocation Table) 시스템
위의 문제점을 개선하기 위해 FAT 시스템이 등장했다. FAT 시스템은 다음 블록을 가리키는 포인터들만 모아서 하나의 테이블(FAT)을 만들어 한 블록에 저장한다.
위의 연결 할당과 똑같은 파일을 저장한다고 할 때, 0번 블록의 FAT를 보면 테이블의 인덱스는 전체 디스크의 블록 번호이며 각 인덱스마다 다음 블록 번호를 저장하고 있다.
FAT는 기존 연결 할당 단점 대부분을 해결할 수 있다. FAT를 한 번만 읽으면 직접 접근이 가능하고 중간 블록에 문제가 생겨도 그 이후 블록은 여전히 FAT를 통해 읽을 수 있다. FAT는 메모리 캐싱을 사용하여 Search는 빠르지만 여전히 블록이 흩어져 있기에 디스크 헤더가 움직여야 하므로 느리다. FAT는 굉장히 중요한 정보이기에 손실 시 복구를 위해 이중 저장을 한다. FAT의 각 인덱스 크기는 전체 블록의 개수를 저장할 만큼의 크기를 가지고 있어야 하는데, 현재는 일반적으로 32bit 크기를 사용해 FAT32라고 부른다.
4. 색인 할당
색인 할당은 데이터를 랜덤한 블록 번호에 할당하지만 할당된 블록 번호(포인터)를 하나의 블록에 따로 저장한다. 이러한 블록을 인덱스 블록이라고 부르고, 파일당 하나의 인덱스 블록이 존재한다. 색인 할당은 디렉토리 정보가 시작 블록 번호를 저장하던 다른 할당과는 다르게 인덱스 블록 번호를 저장한다.
색인 할당은 직접 접근이 가능하고 외부 단편화 문제도 발생하지 않는다. 유닉스/리눅스 계열에서 주로 사용한다.
하지만 작은 크기의 파일인 경우에도 하나의 블록을 인덱스 블록으로 사용하기에 저장 공간이 손실되고 하나의 인덱스 블록으로는 크기가 큰 파일을 저장할 수 없다.
하나의 블록 크기가 512B일때 최대 저장할 수 있는 블록 인덱스 개수는 512/4(포인터 크기) = 128개이다. 즉, 파일의 최대 크기는 128 * 512B = 64KB로 아주 작은 크기이다. 블록 크기가 1KB라고 하더라도 최대 인덱스 개수는 256개이고 최대 파일의 크기는 256KB이다.
이를 해결하기 위한 3가지 방식이 존재한다.
- Linked 방식 : 인덱스 블록을 여러 개 만들어 연결 할당한다.
- Multilebel index 방식 : 계층을 두는 방식으로 하나의 인덱스 블록의 모든 포인터가 다른 인덱스 블록을 가리고 부족하면 계층을 더 만들어간다.
- Combined : Linked와 Multilebel index를 합쳐 한 인덱스 블록의 포인터들은 데이터 블록과 또 다른 인덱스 블록 둘 다를 가리킬 수 있다. (리눅스가 사용함)
참고
https://velog.io/@ur2e/OS-%ED%8C%8C%EC%9D%BC%EC%8B%9C%EC%8A%A4%ED%85%9C
https://velog.io/@thdalstn6352/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9COS-File-System
https://myvelop.tistory.com/203
https://velog.io/@dreamcomestrue/OS-File-System-Logical-Directory-Structure
https://bubble-dev.tistory.com/entry/OS-%EB%94%94%EB%A0%89%ED%84%B0%EB%A6%AC-%EA%B4%80%EB%A6%AC-%EA%B5%AC%EC%A1%B0
https://velog.io/@codemcd/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9COS-18.-%ED%8C%8C%EC%9D%BC-%ED%95%A0%EB%8B%B9
