파일 시스템 - 운영체제

파일 시스템이란 파일을 다루는 시스템을 의미한다.

파일 시스템이 무엇인지에 대해 설명하기에 앞서 파일이 무엇인지 알아보는게 좋을 듯 싶다.

파일이란

파일이란? 데이터나 프로그램을 담는 그릇입니다( 파일시스템은 그 그릇들을 관리하는 것이다). 정확히 말하자면 데이터나 프로그램을 저장하는 연속적인 논리적 공간입니다.

 파일의 젤 앞부분을 offset 0 라고 하며, 여기서부터 데이터가 연속적으로 담기게 된다. 데이터의 타입은 바이너리일수도, 일반 정수일수도 Char타입일수도 있습니다.

 

파일의 구조는 어떨까?

파일의 구조는 OS나 프로그램이 정합니다.

• None: 연속적인 바이트 구조
• Simple Record: 레코드의 한줄이 구조가 되는 것이다. 길이는 가변적일수도 고정적일수도 있습니다.
• Complex: Docs, Dll

이러한 파일을 파일시스템이 다루기 위해선, 단순 파일의 내용뿐 아니라 파일의 특성에 대해서도 알아야합니다. 이를 메타데이터라고 합니다.

• 이름
• 타입
• 위치
• 용량
• 권한 등등

디렉토리

디렉토리가 존재하는 이유는 파일을 관리하기 위해서입니다. 비슷한 종류의 파일은 그룹핑을 하고 싶어서 입니다. 

위에서는 컴퓨터 입장이였고, 사용자 입장에선 체계적으로 관리하기 위해서 디렉토리가 필요합니다.

 

시스템입장에선 파일의 이름을 관리하기 편해집니다. 사용자가 모든 파일의 이름을 서로 다르게 하기 힘들므로 디렉토리를 이용하여 파일의 이름이 같더래도 디렉토리까지 identifier로 사용할 수 있으며, 서로다른이름을 갖는것처럼 간주하게 됩니다. 

 

파일의 특정데이타 아이템이 어디있는지에 대한 정보가 hdd에 어디있는가 가 아닌 이 디렉토리 어디에 있다 라고 말하기 편해집니다. 이를통해 관리하기 쉬워집니다.

상대적인 위치도 specify할수있게 되고, 절대 위치 또한 루트에서 출발하여 쉽게 찾을수 있게됩니다.

 

메타데이터는 어떻게 저장이 될까

파일의 메타데이타는 디렉토리에 저장이 됩니다.

내부적으로 디렉토리는 여러개의 파일을 갖고있고 메타데이타의 개수가 파일의 갯수만큼 존재할 것 입니다. 메타데이타을 저장하는데 적합한 자료구조를 만든다. (이를 ㄴdirectory entry라고 한다.) 이 entry는 파일의 갯수만큼 디렉토리에 저장된다. 

 

파일과 디렉토리는 동일하게 취급하나 파일은 데이타가 들어간거고 디렉토리는 파일에 대한 메타데이타가 들어간것이다. 

Sub direcotory도 entry에 저장된다. (이는 os가 지정한거여서 entry의 형식을바꿀순없음.)

 

메타데이타의 위치를 알아야 data의 위치를 알아야한다. 이를 담고있는 directory을 찾아내면 다 찾아낼수있다. 그 디렉토리의 위치는 그 디렉토리의 상위 디렉토리가 갖고있다. (파일과 동일하게 취급)

 

파일의 첫번째 데이타를 읽고싶음. Fscanf으로 읽고싶으면 그 파일이 저장되어있는 디렉토리를 읽어서 메타데이타(entry)을 읽어서 첫번째 datablock의 위치를 알아내서 그 위치에 있는 데이타를 읽는다. 2번재 위치도 동일하게 반복한다.(이는 모두 시스템콜을 통해 일어난다.)

 

그렇다면 메타데이터의 물리적 위치는 어디에 있을까요?
결과적으로 말하자면 메모리에 있어야 합니다. 데이터에 접근하기 위해 entry에 접속하면 hdd에 접근하여 io가 발생하는건 너무 느립니다. 따라서 메모리에 저장하게 되고, 파일을 open(시스템콜)한다는 의미는 메타데이터를 메모리에 올려놓는 것 입니다. 

또한 한번 올린 파일은 메모리에 올려놓아야 합니다. 다시 접근할려면 Root부터 찾아가야 하기 때문에, close 시스템콜을 호출하였더래도, 메모리에 그대로 유지하는것이 좋습니다. 

파일의 업데이트 되어 메타데이터가 변경되는 경우는 메모리에만 반영되고, 하드디스크에 저장하는 시기는 컴퓨터의 정책에 따라 달라집니다.

디렉토리 구조

• 볼륨 : 파일 시스템을 포함하고 있는 임의의 개체, 각 볼륨을 논리적인 가상 디스크로 취급될 수 있습니다. 하나 이상의 운영체제를 저장하고 부팅, 실행시킬 수 있습니다. 섹터들의 집합으로 연속공간이 아니어도 볼륨으로 볼 수 있습니다.
• 디바이스 디렉터리(디렉터리) : 그 볼륨에 있는 모든 파일에 대한 이름, 위치, 크기, 타입과 같은 정보를 기록합니다.
• 파티션 : 연속된 저장 공간을 하나 이상의 연속되고 독립적인 영역으로 나누어서 사용할 수 있도록 정의한 규약

1단계 디렉토리

가장 간단한 디렉토리 구조이다. 파일을 루트위치에 다 넣습니다. (실제로는 절대 안쓴다.)

 

2단계 디렉토리

사용자마다 개별적인 디렉토리를 만들어줍니다. Pathname개념과 사용자간 이름충돌이 생기지 않으나, 다른 사용자의 파일에 접근하려할시 단점이 됩니다.

트리 디렉토리

장점: 

• Sub tree을 무한히 만들기가 가능합니다.
• 홈 디렉토리라는 개념도 생겼으며 그룹핑도 가능합니다.
• 절대 및 상대경로도 생김. 현재위치라는것도 생겼다는 장점이 있습니다.

단점:

• 하지만 트리구조가 되어서 디렉토리가만들어지면 어떤파일을 찾을때 모든 서브트리를 다 뒤져야 하는 문제가 생깁니다.(검색문제)(
• 우분투에서는 SearchPath라는 것을 통하여 어느정도 커버를 할수 있음)
•  하지만 삭제를 하는 경우 다음과 같은 선택지에 부딪힙니다. 서브directory을 삭제하면 그 해당 밑의 모든 subtree directory도 다 삭제해야 하는가? 
  •  해당 서브디렉토리 밑에 파일이 없을때만 삭제하자. 안정성 중시
  •  편의성을 우선, 다 삭제하기.

비순환 그래프 디렉토리

부모가 2개일수 있으며(이 경우 공유를 의미), 사이클을 허용하지 않는 디렉토리입니다.

이과정에서 복잡한 3가지 문제가 발생한다.

1. 링크를 하는 경우: 공유시키는데에도 2가지 방식이 존재. (symbolic과 hard)
2. 모든 파일을 탐색하려는 경우: 공유파일을 여러번 탐색하게 됨.
3. 삭제를 하는 경우: 파일을 삭제하는 경우, 어떻게 동작할 것인지.
4. 수정을 하는 경우: 다른 루트에서 수정을 한 경우, 다른 루트의 파일은 수정이 안될수가 있음(Hard정책을 따른 경우)

이를 막기위해 Reference Count을 따로 두는 방법이 있다.

일반 그래프

애는 순환을 허락하며 공유또한 허락합니다. 따라서 더욱 복잡해집니다.

1. 모든 파일을 탐색하는 경우: 서브 디렉토리가 부모를 또 가리킴: 무한루프 => 해결 메카니즘이 더욱 복잡해짐.
2. 하위 디렉토리가 사이클을 갖고있는 경우, reference count가 1인데 지워지지 않아, Garbage가 되는 경우가 있다. 이 경우 Garbage Collection을 돌려야 한다.

만약 사이클을 허용치 않는 os을 만든다면 link을 사용자가 만들때마다 사이클을 detect하는 알고리즘을 돌려야 합니다.

 

 

 

마운팅

하드디스크도 cd도 usb도 다 root에서 시작하는 구조를 갖고있습니다. Window의 경우는 이들에 접근하기위해선 드라이브를 변경하면 되고, 그 드라이브의 루트에서 파일을 찾게 됩니다. 유닉스에서는 마운트가 그 역할을 대신합니다.  

 

다만 윈도우와 다르게 유닉스에서는 시스템 부팅시 저장위치로 마운트를 하고, 한번 마운트하면 시스탬을 재부팅하지 않는이상, 파일의 루트를 바꿀수 없습니다.