파일 시스템은 두 부분으로 구분됩니다.
- 관련된 정보 자료를 저장하는 실제적인 파일의 집합체
- 시스템 내의 모든 파일에 관한 정보를 제공하는 디렉터리 구조
파일 시스템은 저장장치상에 구현됩니다.
1. 파일 개념
파일은 다음과 같이 정의를 내릴 수 있습니다.
저장된 정보에 대한 일관된 논리적 관점을 제공하고 저장장치의 물리적 특성을 추상화하여 논리적 저장 단위로 정의한다.
사용자 관점에서 볼 때 파일은 논리적 보조저장장치의 가장 작은 할당 요소입니다.
일반적으로 파일은 프로그램이나 자료로 나타내며, 다양한 형식으로 표현할 수 있습니다.
파일은 유형에 따라서 다음과 같이 구분할 수 있습니다.
- 텍스트 파일
- 소스 파일
- 실행 파일
1.1 파일 속성
파일은 운영체제마다 다른 속성을 갖지만 전형적으로 다음과 같은 속성들을 가집니다.
- 이름: 기호형 파일의 이름은 사람이 읽을 수 있는 형태로 유지된 유일한 정보
- 식별자(identifier): 이 고유의 꼬리표는 통상 하나의 숫자로 파일 시스템 내에서 파일을 확인
- 유형: 여러 유형을 제공하는 시스템을 위해 필요
- 위치: 파일이 존재하는 장치와 그 장치 내의 위치에 대한 포인터
- 크기: 파일의 현재 크기와 최대 허용 가능한 크기
- 보호: 접근 제어 정보는 누가 읽기, 쓰기, 실행 등을 할 수 있는가를 제어
- 타임스탬프와 사용자 식별: 생성, 최근 변경, 최근 사용 등을 유지하고, 이들 자료는 보호, 보안 및 사용자 감시를 위해 사용
모든 파일에 대한 정보는 파일 자신과 같은 장치에 상주하는 디렉터리 구조에 의해서 유지됩니다.
전형적으로, 디렉터리 항목은 파일의 이름과 고유의 식별자로 구성됩니다.
디렉터리는 파일의 휘발성과 일치해야 하므로 같이 장치에 저장되어야 하고, 필요할 때마다 메모리로 조금씩 반입됩니다.
1.2 파일 연산
파일의 기본 연산은 다음과 같은 것들이 구현되어 있습니다.
- 파일 생성: 파일을 생성하기 위해서는 2단계가 필요
- 파일을 저장할 수 있도록 공간 확보 및 할당
- 새로 생성된 파일에 대한 항목이 디렉터리에 구현
- 파일 열기: 생성과 삭제를 제외한 모든 연산을 하기 전에 반드시 파일을
open()해야 합니다. 성공하면 open 콜은 다른 콜의 인자로 사용되는 파일 핸들을 반환합니다. - 파일 쓰기: 열린 파일 핸들과 기록될 정보를 사용(시스템 콜)합니다. 시스템은 파일 내의 다음 순차적 쓰기가 일어날 위치를 가리키는 쓰기 포인터(write pointer)를 유지하고 있어야 합니다.
- 파일 읽기: 파일 핸들과 읽어야 할 블록의 위치를 사용합니다. 읽기 포인터(read pointer)를 유지하며, 대부분의 시스템은 하나의 현재 파일 위치 포인터(current file position pointer)를 가집니다.
- 파일 안에서의 위치 재설정(reposition): 열린 파일의 현재 파일 위치를 주어진 값으로 설정
- 파일 삭제: 파일을 삭제하기 위해서는 다음과 같은 동작이 요구됩니다.
- 지정된 파일을 디렉터리에서 찾는다.
- 디렉터리 항목을 찾으면 모든 파일 공간을 해제하고 디렉터리 항목을 지우거나 사용 가능으로 표시합니다.
- 만약 하드 링크로 되어 있을 경우 마지막 링크가 삭제될 때까지 삭제되지 않습니다.
- 파일 절단: 사용자가 파일의 내용은 지우고 다만 그 파일의 속성은 그대로 남기기를 원할 때 사용, 파일의 길이를 제외한 모든 속성은 그대로 유지됩니다.
여기서 하드 링크는 동일한 파일에 대해 여러 개의 이름(디렉터리 항목)이 존재하는 것을 의미합니다.
운영체제는 모든 열린 파일에 대한 정보를 갖는 열린 파일 테이블(open-file table)을 유지함으로써, 반복적인 탐색을 피합니다.
open() 시스템 콜이 발생했을 때의 동작을 살펴봅시다.
- 파일 이름 조회:
open() 호출 시 제공된 파일 이름을 사용하여 파일 시스템의 디렉터리 구조를 탐색합니다. 이 과정에서 파일 시스템은 파일의 메타데이터를 포함하고 있는 디렉터리 엔트리를 찾습니다.
- 열린 파일 테이블로 복사:
시스템은 파일의 메타데이터를 사용하여 열린 파일 테이블(또는 파일 디스크립터 테이블)에 항목을 생성합니다.
이 테이블은 운영체제가 현재 열려 있는 모든 파일을 추적하는 데 사용됩니다. 각 항목은 파일의 현재 상태를 나타냅니다.
여기서, 현재 상태로는 읽기/쓰기 포인터의 위치, 열린 모드, 파일의 접근 권한 등이 있습니다.
- 접근 모드 검사:
open()에 전달된 접근 모드가 파일의 접근 권한과 호환되는지 검사합니다. 이 과정에서 사용자 권한도 확인합니다.
- 파일 열기:
요구된 모드가 파일의 접근 권한과 일치하면, 시스템은 파일을 열고 프로세스가 사용할 수 있도록 합니다.
이때, open()은 열린 파일 테이블에서 해당 파일 항목을 가리키는 파일 디스크립터(또는 핸들)을 반환합니다.
파일 디스크립터는 프로세스가 나중에 read(), write(), close() 등의 다른 시스템을 사용하여 해당 파일과 상호작용하는 데 사용됩니다.
만약 여러 개의 프로세스가 동시에 파일을 열 수 있는 환경이라면 보통 운영체제는 두 단계 내부 테이블을 사용합니다.
- 프로세스 별 테이블
- 범 시스템 테이블
프로세스 별 테이블은 각 프로세스가 연 모든 파일을 기록합니다. 이 테이블에 저장된 내용은 프로세스가 파일을 어떻게 사용하는 가에 관한 정보입니다.
프로세스별 테이블의 각 항목(entry)은 다시 범 시스템 열린 테이블들을 가리킵니다.
범 시스템 테이블은 프로세스에 독립적인 정보 즉, 디스크상의 파일 위치, 접근 날짜, 그리고 파일 크기와 같은 정보들을 갖고 있습니다.
파일이 하나의 프로세스에 의해 열리면, open() 호출을 실행하는 다른 프로세스는 단순히 범 시스템 테이블들 내에 있는 적절한 항목을 가리키는 새로운 항목이 프로세스의 열린 파일 테이블에 더해집니다. 이때, 열린 계수(open counter)에 연관됩니다.
여러 프로세스가 파일을 공유해서 사용할 때 락킹 기법이 필요할 수 있는데, 이러한 파일 락은 두 가지 다른 기능을 제공합니다.
- 공유 락(shared lock): 여러 프로세스가 동시에 락을 획득할 수 있다는 점에서 읽기 락과 비슷
- 배타적인 락(exclusive lock): 한 번에 한 프로세스만 락을 획득할 수 있다는 점에서 쓰기 락과 비슷
또한 운영체제는 두 가지 다른 방법을 제공합니다.
- 강제적(mandatory) 파일 락: 어떠한 프로세스가 배타적 락을 획득하면 운영체제는 다른 프로세스 잠겨진 파일에 접근하는 것을 막는다.
- 권고적(advisory) 파일 락: 접근하기 전에 락을 획득할 수만 있다면 접근을 막지 않는다.
1.3 파일 유형
운영체제가 파일 유형을 지원한다면, 운영체제는 파일에 대해 합리적인 연산을 수행할 수 있습니다.
만약, 텍스트 파일과 목적 코드 파일을 구분할 수 있다면 이진 목적 코드를 출력하려는 시도를 막을 수 있을 것입니다.
이에 잘 알려진 방법은 파일 이름의 한 부분이 파일 유형을 나타내도록 하는 것입니다.
파일 이름이 마침표로 구분되는 이름과 확장자(extension) 두 부분으로 나뉘게 됩니다. 대부분 운영체제에서 사용자는 마침표와 추가적인 확장자의 파일 이름을 사용할 수 있습니다.
시스템은 파일 유형에 따라 파일 연산 명령을 결정홥니다.
예를 들면, .com, .exe 파일은 이진 형태의 수행 파일이고, .sh 파일은 운영체제에 전달되는 명령을 ASCII 형식으로 저장하고 있는 셸 스크립트입니다.
또한, .java 확장자를 가지고 있는 파일은 JAVA 컴파일러가 실행을 할 것이고, Microsoft Word는 .doc 또는 .docx 확장자를 가져야 합니다.
1.4 파일 구조
파일의 유형을 사용하여 파일의 내부 구조 형태를 짐작할 수 있습니다.
각각의 파일들은 그 파일을 다루는 프로그램에 의해 인식 가능한 내부 구조를 일정한 형태로 가지게 됩니다. 어떤 파일들의 경우에는 운영체제가 인식할 수 있도록 미리 정해진 구조를 따라야 할 때도 있습니다.
예를 들어, 운영체제는 실행 파일에 대하여 다음과 같은 것을 요구합니다.
- 실행 파일이 메모리 상의 어느 위치에 적재되는지
- 초기에 실행 가능한 명령어의 위치를 파악할 수 있는 특별한 구조
운영체제가 여러 파일 구조를 지원하는 경우에 발생 가능한 단점의 하나는 운영체제의 크기가 커지고 관리하기가 힘들어진다는 점입니다.
운영체제가 지원하는 파일 유형 중 하나로 정의해야되는 문제로 인해 확장성에 문제가 생길 수도 있습니다.
이로 인해 몇몇 운영체제들은 파일 형태, 구조에 대하여 제한을 거의 두지 않는 경우도 있습니다.
이렇게 되면 시스템은 어떠한 목적으로도 자유롭게 파일을 사용할 수 있게 되며, 유연성은 극대화됩니다.
그 대신 시스템 차원에서의 파일 유형 지원은 상대적으로 적습니다.
1.5 파일의 내부 구조
디스크 시스템은 보통 섹터의 크기에 의해 결정되는 블록 크기를 가진다고 했습니다.
모든 디스크 I/O는 한 블록 단위로 수행되며 모든 디스크 블록들은 동일한 크기를 가집니다. 논리 레코드의 길이는 매우 다양하며 여러 논리 레코드를 하나의 물리 레코드에 팩킹(packing)하는 것이 일반적입니다.
논리 레코드의 크기, 물리 블록 크기 그리고 팩킹 기술은 각 물리 블록 내에 몇 개의 논리 블록이 들어갈지 결정합니다. 어떤 경우든 파일은 일련의 블록으로 간주되고, 모든 기본 I/O 기능은 블록 단위로 수행됩니다.
디스크 공간이 항상 블록 단위로 할당되기 떄문에 각 파일의 마지막 블록의 일부는 낭비되는 내부 단편화(internal fragmentaion)이 생길 수 있다는 것을 기억하자.
2. 접근 방법
위에서 파일을 저장할 때 논리 블록을 사용한다고 했고, 이러한 논리 블록들은 물리 블록들에 팩킹된다고 했습니다.
파일을 읽어오기 위해서는 역순으로 물리 블록을 읽어와야 하는데, 이를 위해 몇 가지 방법이 존재합니다.
- 순차 접근
- 직접 접근
- 기타 접근 방법
아래에서 다뤄봅시다.
2.1 순차 접근
순차 접근은 가장 간단한 접근 방법입니다.
이것은 디스크에 있는 파일을 마치 오디오의 카세트테이프를 재생하는 방식처럼 접근합니다. 즉, 여기에서 접근 방법은 저장되어 있는 레코드 순서로 접근합니다.
이 접근 모드는 가장 일반적이며 예를 들면, 편집기나 컴파일러는 보통 이러한 형식으로 파일에 접근합니다.
이 방식은 순차적으로 읽고 쓰는 속도가 빠르지만, 임의의 위치에 저장되어 있는 파일을 읽어오는데 많은 시간이 소모된다는 단점이 있습니다.
2.2 직접 접근
직접 접근을 위해서 파일은 고정 길이의 논리 레코드의 집합으로 정의되고 직접 접근 파일은 어떠한 블록이라도 직접 액세스할 수 있습니다.
직접 접근 방법은 파일의 디스크 모델에 기반하며 이는 디스크가 임의의 파일 블록에 임의의 접근을 허용하기 때문입니다.
직접 접근 파일은 대규모의 정보를 다루는 데 아주 유용하며, 대규모 데이터베이스가 이러한 유형일 수 있습니다. 어떠한 질의(query)가 들어오면 그 답을 수록하고 있는 블록을 알아내어 직접 그 정보를 읽습니다.
직접 접근 방법을 위해서는 파일 연산이 블록 번호 파라미터를 포함할 수 있도록 수정되어야 합니다.
여기서 사용하는 블록 번호 파라미터는 상대 블록 번호(relative block number)이고, 이것을 사용하기 위해서는 운영체제가 파일을 어디에 저장되어야 하는지를 결정해야만 하고, 사용자가 자신의 파일이 아닌 부분에 접근하는 것을 막을 수 있게 하빈다.
2.3 기타 접근 방법
직접 접근 파일이 있으면 그것을 기반으로 여러 가지 다른 파일 접근 방법을 제공할 수 있습니다.
그런데 이들은 대부분 파일에 대한 색인(index)을 사용합니다.
색인을 이용하여 그에 대응하는 포인터를 얻고, 이를 사용하여 파일을 직접 접근하고 원하는 레코드를 찾습니다.
파일이 아주 클 경우 색인 자체도 매우 커 메모리에 다 들어가지 못할 수 있으므로 그것 자체를 파일로 만들어 주어야 합니다.
색인 파일이 너무 커지면 그것에 대한 또 색인을 만들 수 있고, 이렇게 계층적으로 색인 파일을 활용할 수 있습니다.
3. 디렉터리 구조
디렉터리는 파일 이름을 상응하는 파일 제어 블록으로 바꾸어 주는 심볼 테이블(symbol table)로 볼 수 있습니다.
디렉터리에 대한 연산은 다음과 같습니다.
- 파일 찾기
- 파일 생성
- 파일 삭제
- 디렉터리 나열
- 파일의 재명명
- 파일 시스템의 순회
파일 시스템 순회의 경우, 파일 시스템의 여러 디렉터리를 순회해 다니며 파일을 볼 수 있게 해주는 기능으로 매우 유용합니다.
신뢰성 측면을 고려하면 파일 시스템 구조와 관련된 정보를 주기적으로 자기 테이프, 다른 보조저장장치 또는 네트워크를 통해 다른 시스템에 또는 클라우드에 저장해두는 것이 좋습니다. 이 기법은 시스템 장애 시 백업 사본을 제공합니다.
3.1 1단계 디렉터리
가장 간단한 디렉터리 구조가 1단계 디렉터리(single-level directory)입니다.
여기서는 모든 파일이 다 같이 한 개의 디렉터리 밑에 있으므로 개념이 간단합니다.
그러나, 1단계 디렉터리 구조는 파일이 많아지거나 다수의 사용자가 사용하는 시스템에서는 심각한 제약을 가지게 됩니다.
같은 디렉터리에 있는 모든 파일이 존재함으로 각 파일들은 유일한 이름을 가져야 합니다.
3.2 2단계 디렉터리
2단계 디렉터리(two-level directory) 구조에서는, 각 사용자는 자신만의 UFD 디렉터리(user file directory, UFD)를 가지고, UFD는 비슷한 구조로 되어 있지만, 각 디렉터리에는 오직 한 사람의 파일만을 저장합니다.
사용자 작업이 시작되거나, 시스템에 사용자가 로그인 등을 통해 접속하게 되면 시스템은 마스터 파일 디렉터리(master file directory, MFD)를 먼저 탐색합니다.
MFD는 사용자 이름이나 계정 번호로 색인되어 있고, 각 엔트리는 그 사용자의 UFD를 가리키고 있습니다.
2단계 디렉터리 구조는 파일 이름이 충돌하는 문제는 어느 정도 해결하였으나 다른 문제를 새로 제기합니다.
이 구조에서는 한 사용자의 UFD를 다른 사용자가 액세스할 수 없으므로 장점이 되지만 두 사용자가 한 파일을 공유해서 사용해야 하는 경우는 문제가 발생합니다.
서로가 자신의 UFD 접근을 허용하지 않으면 공유는 불가능할 것입니다.
접근이 허용된다면, 한 사용자가 다른 사용자의 디렉터리에 있는 파일을 지칭할 수 있어야 합니다.
이때, MFD와 다른 사용자의 UFD로부터 특정 파일(leaf)까지의 경로를 정의합니다. 따라서 사용자 이름과 파일 이름은 모든 파일이 가지고 있는 경로명(path name)이 됩니다.
운영체제가 탐색하는 방식이 중요한데, 만약 현재 UFD에서 파일을 찾지 못했을 경우 자동으로 다른 UFD를 탐색할 수 있도록 설정함으로써 해당 설계는 충족됩니다.
3.3 트리 구조 디렉터리
2단계 디렉터리 구조를 2단계 트리로 보는 방법처럼 여러 단계로 확장하는 일반적인 방법이 잎의의 높이를 갖는 트리(tree) 구조입니다.
이것은 일반 사용자들에게 자신의 서브디렉터리(subdirectory)를 얼마든지 만들 수 있도록 해줍니다.
트리 구조이므로 최상위에 하나의 루트(root) 디렉터리가 존재하게 됩니다. 시스템 내의 모든 파일은 고유한 경로명을 가집니다.
디렉터리의 각 항목는 한 비트를 사용하여 그 항목이 나타내는 파일이 일반 파일(0)인지 디렉터리 파일(1)인지를 구분합니다.
통상적으로 각 프로세스는 현재 디렉터리(current directory)를 가지고 있습니다.
파일의 참조가 일어나면 현재 디렉터리를 먼저 검색하고, 현재 디렉터리에 없다면 탐색 경로를 사용하거나 그 파일이 있는 디렉터리로 먼저 가야 합니다.
현재 디렉터리를 다른 디렉터리로 바꾸기 위해서는 change directory 시스템 콜을 하는데 이 호출은 새로 가고자 하는 디렉터리 이름을 매개변수로 사용해야 합니다.
이때 사용할 수 있는 경로명은 두 가지가 있습니다.
- 절대 경로명(absolute path name)
- 상대 경로명(relative path name)
트리 구조에서 생기는 문제는 디렉터리의 삭제 문제입니다.
만약 디렉터리가 비어 있다면 문제는 간단합니다. 그러나 제거 대상 디렉터리가 파일들이나 서브디렉터리들로 아직 채워져 있다면 고려해야 되는 점이 생깁니다.
디렉터리를 지우기 위해 우선 디렉터리에 있는 모든 파일을 삭제해야 하는데 이때 일일히 확인해가며 삭제할 수 있고, 아니면 강제적으로 삭제하는 방법이 있을 수 있습니다.
3.4 비순환 그래프 디렉터리
트리 구조는 파일 또는 디렉터리의 공유를 허용하지 않습니다.
비순환 그래프(acyclic graph)는 디렉터리들이 서브디렉터리들과 파일들을 공유할 수 있도록 허용하는 구조로 똑같은 파일이나 서브디렉터리가 서로 다른 서브디렉터리에 있을 수 있습니다.
비순환 그래프(즉, 사이클이 없는 그래프)는 트리 구조 디렉터리 방식을 일반화한 것입니다.
공유를 위해 디렉터리나 파일을 복사하하면 안되고, 공유 파일(혹은, 디렉터리)은 두 개의 복사본과는 다릅니다.
공유 파일(공유 디렉터리)은 여러 가지 방법으로 구현합니다.
일반적인 방법은 링크(link)라 불리는 새로운 디렉터리 항목을 만드는 것으로 링크는 다른 파일이나 서브디렉터리를 가리키는 포인터입니다.
실제 파일에 대한 경로 이름을 사용함으로써 우리는 링크를 해석(resolve)합니다.
파일을 공유하는 또 다른 방법은 디렉터리들이 동일한 항목 내용을 복사해서 가지고 있는 방법입니다.
이 방법과 링크를 생성하는 방법과의 차이를 보자면,
링크는 원래의 디렉터리와는 완연히 다른 것이므로 그 두개는 같은 것이 아닙니다. 그러나 디렉터리 항목을 복사하는 것은 복사본과 원래 것이 구분이 안됩니다.
디렉터리 항목을 복사하는데 또 하나의 디렉터리를 변경하면 다른 동일한 복사본 항목도 함께 바뀌어야 하는 일관성(consistency) 문제가 발생합니다.
비순환 그래프 디렉터리는 트리 구조보다는 융통성 있는 대신 더 복잡합니다.
파일이 여러 개의 절대 경로명을 가질 수 있고, 다른 파일 이름이 같은 파일을 가리킬 수 있는 가명(aliasing) 문제가 발생하여 중복 탐색의 문제가 발생할 수 있습니다.
또 다른 문제로는 삭제 연산에서 공유 파일에 할당된 공간을 언제 반납하고 재사용하는 가에서 생깁니다.
만일 누구든지 삭제 연산을 수행할 경우 그 파일이 제거되게 한다면, 존재하지 않는 파일을 가리키는 포인터들이 존재하게 됩니다.
이러한 문제는 링크에서도 발생하며 설계에 따라 달라집니다. 중요한 것은 파일이 삭제되었거나 바뀌었을 때 적절히 처리가 되어야 되는 것입니다.
3.5 일반 그래프 디렉터리
비순환 그래프의 장점은 파일을 검색하고 파일에 대한 참조의 존재 여부를 결정하는 알고리즘이 비교적 간단하다는 것입니다.
중요한 것은 디렉터리에서 순환이 발생하든 안하든, 성능상의 이유로 중복 탐색을 방지하는 것입니다.
한 가지 해결책은 한 번에 검색할 수 있는 디렉터리의 숫자를 임의로 제한하는 것입니다.
이러한 문제는 파일을 삭제할 경우에도 발생하는데, 일반적으로 참조 계수를 활용하여 이 값이 0이 될 때 파일을 삭제합니다.
하지만, 디렉터리 구조에서 자기 참조(self-referencing)로 인하여 비정상적인 결과를 가져오기도 합니다.
이 경우, 마지막 참조가 제거되고 디스크 공간이 재 할당될 수 있을 때를 결정하기 위해서 가비지 수집(gargage-collection) 기법을 사용해야 합니다.
가비지 컬렉현은 전체 파일 시스템을 검색하고, 접근 가능한 모든 것을 표시합니다.
그 후 두 번째 탐색에서 표시되지 않은 것들을 수집하고 사용 가능한 공간 리스트에 추가합니다.
보호에는 ACL(Access Control List)를 이용하여 각 파일과 디렉터리들의 접근을 관리하고, 이를 위해 그룹을 이용하는 방법이 제시되고 있습니다.
4. 메모리 사상 파일
open(), read(), write() 시스템 콜을 사용하여 디스크에 있는 파일을 순차적으로 읽는다고 생각해 봅시다.
이러한 방식을 사용하면 매번 액세스 될 때마다 시스템 콜을 해야하고 디스크에 접근해야 합니다.
이처럼 하는 대신 디스크 입출력을 메모리 참조 방식으로 대신할 수도 있습니다.
이러한 메모리 사상(memory mapping)이라고 불리는 접근 방식은 프로세스의 가상 주소 공간 중 일부를 관련된 파일에 할애하는 것을 말합니다.
4.1 기본 기법
파일의 메모리 사상은 프로세스의 페이지 중 일부분을 디스크에 있는 파일의 블록에 사상함으로써 이루어집니다.
첫 번째 접근은 페이지 크기만큼의 해당 부분이 파일 시스템으로부터 메모리 페이지로 읽혀 들어오게 됩니다.
그 이후의 파일 read/write는 일반적인 메모리 액세스와 같이 처리됩니다.
메모리에 매핑된 파일에 대한 쓰기가 반드시 보조저장장치의 파일에 즉각적(동기식)으로 써지지는 않는다는 것을 주의하자.
일반적으로 시스템은 파일을 닫을 때만 메모리 이미지의 변경 사항에 따라 파일을 업데이트 합니다.
여러 프로세스가 데이터 공유를 위해 파일을 공유한다면, 이전에 가상 메모리에서 다루었던 것처럼 공유 메모리를 이용하여 동작하게 될 것임을 짐작할 수 있습니다.
참고한 자료
- 운영체제[공룡책]
