운영체제 10장 File System Mounting

10.2 Access Methods

파일 정보 접근 방법

10.2.1 Sequential Access

순서대로 읽는다.

 

10.2.2 Direct Access

파일은 logical records로 이루어져 있고 번호를 이용해 프로그램을 빠르게 읽고 쓸수 있도록 한다. 순서에 제한이 없다. 이 방법은 많은 양의 즉각적인 접근에 유용하다.(예> db)

이 방법에서는 파일 오퍼레이션에 block number가 파라미터로 들어가야 한다.

일반적으로 os에서 사용자에게 제공되는 block number는 relative block number이다. 파일의 시작에서부터 상대적 위치이다.

모든 시스템이 sequential과 direct access를 허용하는 것은 아니다.

 

10.2.3 Other Access Methods

다른 접근법은 Direct Access mode 위에 만들어진다. 이 방법은 파일에 대한 인덱스의 construction을 포함한다. index는 다양한 block들에 대해 포인터를 가진다. 파일 접근을 위해서는 index를 찾고 포인터를 이용한다.

큰 파일에서는 인덱스 파일 자체로도 메모리에 넣어 놓기에 매우 커진다. 한가지 해결법은 인덱스의 인덱스를 만드는 것이다.

 

 

10.3 Directory and Disk Structure

어떻게 파일을 저장할 것인가를 고려한다. 파일 시스템 1개를 위해 전부 사용될 수도 있고 미세하게 나누어질 수도 있다. 예를들어 디스크는 파디션될 수 있다.

파티셔닝은 각각의 파일 시스템의 크기를 제한하는데 유용하다. 그리고 일부분을 다른 용도나 swap space 또는 raw disk space로 남겨 놓을 수 있다. 파티션은 slice, minidisk로도 불린다.

파일 시스템을 가지고 있는 엔티티를 volume이라고 한다. 한 volume은 한개의 디바이스일 수도 있고 여러개의 디바이스(RAID)일 수도 있다. 파일 시스템을 가지고 있는 volume은 반드시 시스템의 파일들에 대한 정보를 가지고 있어야 한다. 이 정보들은 device directory(volume table of contents)에 저장된다.

 

10.3.1 Storage Structure

파일 시스템은 can be extensive하다. 그룹별로 분리되고 관리될 수도 있다

 

10.3.2 Directory Overview

디렉토리는 파일 이름들을 디렉토리 엔트리로 변환해 주는 symbol table 이다. 엔트리를 insert, delete, search, list 할 수 있다.

꼭 있어야 하는 오퍼레이션들은 다음과 같다.

-Search

-Create

-Delete

-List

-Rename

-Traverse the file system

 

10.3.3 Single Level Directory

가장 간단한 구조이며 모든 파일들이 한 디렉토리에 저장되어 있다.

파일의 숫자가 늘어나고 시스템이 여러 유저에 의해 사용되면 모든 파일들은 같은 디렉토리에 있으므로 unique name을 가져야 한다. 파일이 엄청 늘어나면 이름을 기억하기도 힘들어 질 것이다.

 

10.3.4 Two-Level Directory

여러 유저들간 파일 이름의 혼란을 해결하는 것이 two-level이다. 각 유저별로 분리된 디렉토리를 가진다.

각 유저는 user file directory(UFD)를 가진다. 사용자가 시작하거나 로그인 하면 시스템의 master file directory(MFD)를 검색한다. MFD는 사용자 이름이나 account number에 의해 index되며 사용자의 UFD의 entry point를 가리킨다.

사용자가 파일 접근 할 때는 오직 자신의 UFD만 검색한다. 그러므로 다른 파일 이름을 가질 수 있다.

사용자 디렉토리들도 생섣되고 삭제되어야 하므로 특수한 시스템 프로그램이 적절한 사용자 이름과 계정 정보를 가지고 운영된다.

이 구조의 단점은 한 사용자를 다른 사용자로부터 고립시킨다는 것이다. 이것은 장점이 될 수도 있지만 태스크를 공유하고 싶을때는 단점이 된다.

Two-Level directory는 2단계의 트리 구조로 볼 수 있으며 level 1이 MFD이고 level2가 UFD이다. 그리고 파일들이 leave가 된다.

이 경우에 시스템 파일이 문제가 될 수 있다. 파일 이름은 현재의 UFD에서만 검색되기 때문이다. 한가지 해결책은 각 UFD에 시스템 파일들을 복사하는 것인데 엄청난 공간 낭비를 가져올 수 잇다.

일반적인 해결법은 search 프로시저를 약간 복잡하게 하는 것이다. 특수한 사용자 디렉토리를 만들고 시스템 파일을 저장시킨다. 로드될 파일 이름이 주어지면 os는 먼저 local UFD를 찾는다. 파일이 없으면 시스템은 특수 디렉토리를 찾는다. 이 디렉토리의 순서를 search path라 한다.

 

10.3.5 Tree-Structured Directories

트리 구조의 디렉토리에서는 사용자가 그들의 서브디렉토리를 만들 수 있고 파일들을 구성할 수 있다. 트리는 가장 일반적인 디렉토리 구조이다. 트리는 루트 디렉토리를 가지고 모든 파일은 유일한 path를 가진다.

디렉토리는 파일들과 서브디렉토리를 포함한다. 디렉토리는 간단히 말해 파일이지만 특수하게 취급된다. 모든 디렉토리는 같은 내부 포맷을 가지고 잇다. 각각의 디렉토리 엔트리는 파일인지 서브디렉토리인지 정의한다.

보통 각 프로세스는 currect directory를 가진다. 프로세스가 현재 관심있는 파일들이 있다. 프로세스에서 파일에 접근하면 현재 디렉토리를 찾고 다른 디렉토리를 접근하려면 path name을 명시하거나 current directory를 바꿔야 한다.

최초 current directory는 사용자가 지정 가능하며 account file이 포인팅 하고 있다. 어떠한 프로세스에서 프로세스를 spawn하게 되어도 디렉토리는 동일하다.

Path name은 두 가지가 있다. absolute/relative 이다.

사용자에게 스스로의 subdirectories를 정의하도록 함으로써 파일들의 structure를 가질 수 있다.

트리구조에서 intereting policy decision은 어떻게 디렉토리 삭제를 다룰 것인가에 관한 것이다. 디렉토리가 비어있으면 그냥 지우면 되지만 안비어 있으면 2가지중 하나를 선택해야 한다. 첫째는 지우지 못하도록 하는 것이고 둘째는 옵션을 주는 것이다. 내용들을 날리거나 지우지 않거나 선택하게 한다. 두번째가 편리하지만 위험할 수 있다.

트리 구조에서는 다른 사용자의 파일도 접근할 수 있다.

어떠한 파일로의 path는 2 level구조보다 길어질 수 있다.

 

10.3.6 Acyclic-Graph Directories

파일이나 디렉토리의 공유가 가능하다. tree 구조에서는 불가능하다. 같은 파일이나 디렉토리가 다른 디렉토리에 있을 수 있다. 이 공유되는 파일은 복사본이 아니다. 실제 파일은 하나인 것이고 한쪽에서 바뀌면 다른 쪽에서도 바로 보인다.

여러가지 방법으로 구현 가능한데 link를 이용할 수 있다. 또는 모든 정보를 복제하는 것도 방법이 될 수 있다. 링크는 원래 것과 링크가 다른 것이지만 두 번째 방법은 파일 두개를 구분할 수 없다.

acyclic 방법은 유연하지만 복잡하다. 한 파일은 여러 절대 경로를 가지고 다른 파일 이름은 같은 파일을 접근할 수 있다. 이 문제는 프로그램 언어에서 aliasing problem과 유사하다. 우리가 파일 시스템 전체를 traverse할 때 문제가 중요해 질 수 있다. 우리는 공유 구조를 한번 이상 traverse하기를 원하지 않기 때문이다.

또다른 문제는 deletion문제다. 파일을 지우면 다른 파일에 의해 dangling pointer가 발생할 수 있고 그 공간이 다른 파일에 의해 사용되면 엉뚱한 곳을 가리킬 수 있다.

심볼릭 링크에 의해 sharing이 구현되는 시스템에서는 이 상황은 다루기 쉽다. 링크 삭제라면 그냥 지우면 되고 파일 엔트리가 삭제되면 링크를 dangling한 상태로 둔다. 그리고 만약 링크에 의해 그 공간이 사용되면 이 접근을 illegal file name을 접근했을때와 같이 다루면 된다.

또다른 deletion 해결법은 파일을 레퍼런스들이 다 삭제될 때 까지 보존하는 것이다. 이 방법에서는 마지막 레퍼런스가 삭제된다는 것을 결정할 수 있는 메커니즘을 가져야 한다. 파일 레퍼런스 리스트를 가질 수 있다. 이 경우에 파일 레퍼런스 리스트가 길어지면 문제가 심각해 질 수 있다. 필요한 것은 count이기 때문에 count만 유지하면 된다.

 

10.3.7 General Graph Directory

디렉토리 구조에 사이클이 있다면 어떠한 컴포넌트를 두 번 이상 search하면 안될 것이다. 성능과 정확성 등의 문제때문이다. 대충 알고리즘을 설계하면 무한 루프에 빠질 수 있다. 한 해결책은 서치 동안 접근될 수 있는 디렉토리의 수를 제한하는 것이다.

파일을 삭제하려고 할때도 유사한 문제가 있다. 사이클이 있다면 더이상 사용되지 않더라도 ref 카운트가 0이 아닐 수 있다. 이 이상현상은 사이클 디렉토리 구조에서의 self 레퍼런싱의 가능성 때문이다. 이 경우에는 마지막 레퍼런스가 삭제되었고 디스크 공간이 재 할당 되어야할 때를 결정하는 방법인 가비지 컬렉션이 필요하다. 가비지 컬렉션은 전체 파일 시스템을 traverse하고 접근되는 모든것을 mark한다. 그리고 마크되지 않은 것을 모두 모은다. 하지만 가비지 컬렉션은 디스크 기반 파일 시스템에서는 엄청나게 시간이 들어서 거의 사용되지 않는다. 어떻게 사이클을 피할 것인가가 중요하다.

 

 

10.4 File System Mounting

이어서