[OS] 디렉토리

📁 디렉토리

📌 디렉토리(directory)란 파일에 대한 정보를 담고 있는 특수 파일을 말한다.

 

즉, 파일에 대한 정보를 담고 있는 것도 파일이라고 할 수 있는 것이다.

 

파일에 대한 정보는 파일 속성(File attribute)라고 한다.

파일의 이름, 타입, 파일 크기, 만들어진 시기, 파일 소유주, 접근 권한 등의 정보를 포함한다.

 

위와 같은 파일 속성은 File Control Block이라는 자료구조의 형태로 디스크에 저장된다.

 

 

위와 같은 논리로 보았을 때, 파일 속성은 FCB라는 자료구조와 디렉토리, 총 두 군데에 저장된다.

 

하지만 이러한 방법은 효율적이지 않다. 파일 속성이 변경된다면 두 군데 모두 동시에 수정이 되어야하기 때문에 처리 속도가 느려진다.

 

그러므로 디렉토리가 파일 속성을 저장하고 있는 것처럼 보이지만, 물리적으로는 파일 이름과, 그 파일에 해당하는 FCB의 식별자만 저장하도록 하는 것이 일반적이다.

 

 

위 그림은 Unix 및 리눅스에서의 디렉토리이다.

파일 이름과 그 파일에 해당되는 FCB의 식별자를 갖고 있는 것을 볼 수 있다.

 

 

즉, 실제로 파일 속성 값은 디렉토리 파일에 넣는 것이 아니라, 디렉토리 안의 FCB 식별자에 해당되는 FCB를 찾아가 저장하는 것이다.

 

위와 같이 구현하면 디렉토리 자체가 직접 속성 정보를 내부에 저장하는 것처럼 보일 수 있다.

 

 

 

📁 디렉토리의 구조

일반적으로 사용하는 디렉토리의 구조는 계층 구조의 디렉토리이다.

 

📌 계층 구조란, 최상위 디렉토리가 있고, 그 밑에 디렉토리 혹은 파일이 속해있고, 또 그 밑에 디렉토리 밑 파일들이 속해있는 구조를 말한다.

 

계층 구조의 디렉토리는 트리 구조라고도 불린다.

 

 

아래 그림과 같다.

 

📌 루트(root), 혹은 마스터 디렉토리(master directory) : 최상위 노드를 말한다.

📌 current directory (working directory) : 계층구조에 있는 개념으로, 현재 작업중인 디렉토리를 말한다.

 

current directory 개념이 없다면, 경로를 지정할 때마다 path name을 매번 써주어야한다.

current directory 개념을 이용해 현재 디렉토리에서부터의 상대적인 경로를 지정할 수 있어 훨씬 간편해진다.

 

이때 path name이란, 루트에서부터 현재 디렉토리 및 파일까지의 경로를 글로 나타낸 것을 말한다.

 

 

🔎 그래프

최근 일반적으로 사용되는 구조로, 트리 구조를 확장한 모습이다.

 

 

 

 

📁 디렉토리 내부

디렉토리 내부의 내용은 일반적인 파일의 출력 명령(cat)으로는 볼 수 없다.

 

 

운영체제가 Unix 혹은 Linux라고 가정해보자.

 

Unix 혹은 Linux에서 디렉토리 내부는 다음과 같다.

 

byte offset, inode number, 파일 이름이 한 줄씩 저장되어 있다.

 

 

📌 byte offset은 각 줄의 상대적인 위치를 나타내는 주소 정보이다.

한 줄이 16바이트씩 이루어져있음을 나타낸다.

 

 

inode란 Unix나 Linux 운영체제에서 FCB를 부르는 이름이다.

📌 inode number는 FCB number, 즉 FCB의 고유 식별자를 뜻한다.

 

 

📌 file names은 파일 이름들의 목록이다.

위 그림에서 '.'(period)는 현재 디렉토리를 뜻하며, 두개가 모여 '..'이 되면 부모 디렉토리를 뜻한다.

 

 

 

📁 디렉토리가 동작하는 방법

 

아래 그림을 다시 살펴보자.

 

루트 디렉토리(inode 2) 밑에 usr라는 디렉토리(inode 4)가 있고, 그 밑에 member라는 디렉토리(inode 23)이 있고, 그 밑에 list.txt 파일이 있다.

 

위 list.txt 파일을 오픈한다고 가정하자.

 

오픈 시, 가장 먼저 요청하는 파일이 실제로 존재하는 파일인지 체크하는 과정을 거친다.

 

만약 존재한다면, 보조기억장치의 파일 시스템에 있는 list.txt의 FCB를 커널 메모리에 읽어 들여온다.

 

만약 존재하지 않다면, 이 때는 요청한 파일의 이름을 갖는 새 파일을 만들고, FCB를 새로 생성한 후 생성된 FCB를 커널 메모리로 읽어 들여온다.

파일을 지우고자 할때 없는 파일을 요청하면 오류를 띄우는 것과 다르게 동작이 정의되어있다.

 

파일이 있는지 없는지 확인하고 싶을때.

먼저 root부터 시작한다. 루트 밑에 usr가 있는지 확인해야한다.

그러려먼 루트라는 디렉토리 파일의 내용을 조사해야한다.

위에서 디렉토리 내부에 file names가 있다고 했으므로, usr라는 이름이 있는지 확인해보면 된다.

 

그런데 루트라는 디렉토리 파일의 내용을 조사하기 위해서는 이 내용의 주소, 즉 블록 번호를 알아야한다.

하지만 컴퓨터 시스템에는 수많은 블록들이 있기 때문에, 그 중 어떤 블록이 루트의 내용인지 알기 위해서는, 블록 번호를 FCB에 저장해두어야한다.

FCB는 파일에 대한 정보를 담고 있기 때문에, 파일의 내용이 들어있는 블록의 주소를 저장하는 필드가 있다.

 

즉 root파일의 내용을 보려면 내용이 담긴 블록의 주소를 알아야하고, 주소를 알기 위해서는 FCB를 읽어야한다.

 

이때 FCB를 읽기 위해서는, Unix나 Linux의 경우 inode number를 알아야한다.

 

Unix 운영체제의 경우 루트노드의 inode number는 2번으로 지정되어있다.

 

아래 그림을 보자.

 

위 그림은 루트 디렉토리의 inode를 커널 메모리에서 읽어온 것이다.

140이라는 숫자는 루트 디렉토리의 내용이 들어있는 데이터 블록 번호이다.

 

파일 시스템에는 데이터 블록들만 모아놓은 영역이 있는데, 그 영역에서 140번째 블록을 읽어온 것이다.

위 그림은 편의상 byte offset은 생략하고 inode number와 files names만 보여주고 있다.

 

위 그림은 루트 노드의 디렉토리 내부인데, 루트 노드의 부모 노드는 없기 때문에 '..' 부분의 inode number가 2로 자기 자신을 가리키는 것을 볼 수 있다.

 

 

위와 같은 과정을 통해 디렉토리 내부 내용의 file names에 usr가 있는지 확인이 되었다.

 

이후 같은 방식으로 usr 밑에 member가 있는지 확인하면 된다.

usr 디렉토리 내용을 읽기 위해 내용이 저장된 블록 주소를 알아야하고, 이를 알기 위해 usr의 FCB를 알아야하고, 이를 찾기 위해 파일시스템에 가서 inode 4번 FCB를 읽어온다.

 

마지막으로 같은 방식으로 member 밑에 list.txt가 있는지 조사하면 된다.

 

위 과정으로 찾은 usr와 member 디렉토리의 내부 내용은 다음 그림과 같다.

 

끝으로 inode 42번의 FCB를 메인메모리로 가져오면 list.txt 파일 오픈이 끝난다.

 

 

📁 그래프 구조

기본적으로는 트리와 같은 모양이지만, 링크를 사용한다.

 

두 곳에서 하나의 파일을 가리키게 되어 원형과 같은 그래프가 된다.

 

생김새는 다음과 같다.

 

 

📁 링크의 장단점

장점 : windows의 바로가기 기능.

단점 : 댕글링포인터

 

📌 댕글링포인터란 존재하지 않는 파일을 가리키게 되는 문제이다.

링크가 만들어져있던 어떤 파일이 지워졌을 때, 파일 자체는 사라졌는데도 링크는 계속 남는 경우를 댕글링 포인터 문제가 발생했다고 말한다.

 

📝 댕글링포인터의 예시

(심화)

 

 

 

📁 파일 쉐어링

내가 만든 파일을 다른 사람이 접근 가능하게 만들 수 있다.

 

파일 쉐어링을 위해서는 두 가지 고려할 점이 있다.

1. 접근 권한(access rights)

2. 동시 접근 시 제어 관리(Management of simultaneous access)

 

위 두가지를 파일마다 일일히 지정해줘야한다.

 

 

1. 접근 권한

특정 파일에 대해 누가 무엇을 할 수 있냐를 명시하는 것이다.

 

보통의 운영체제는 접근 권한을 읽기 / 쓰기 / 실행하기 세가지로 분류한다.

 

만약 모든 유저에 대한 접근 권한을 전부 저장하면 그 정보의 양이 많아 운영체제에게 시간 부담이 생긴다.

 

위 문제를 해결하는 방법은 다음과 같다.

 

운영체제는 유저를 owner / group / public(others) 세 가지로 분류한다.

owner는 실제 파일을 만든 사람, 파일의 소유주이다. 단 한명 존재한다. 일반적으로 권한이 가장 많다.

group은 owner와 가까운 사람들이다.owner와 똑같은 권한이거나 조금 적은 권한을 갖는다.

public은 others라고 불린다. 가장 적은 권한을 가진다.

 

예를 들어, list.txt 파일에 대한 세 가지 종류의 유저가 갖는 접근 권한은 다음과 같다.

 

위 권한에서 RWX는 각각 읽기, 쓰기, 실행하기를 나타내며

1은 가능, 0은 불가능을 나타낸다.

 

RWX에 1과 0으로 표시되는 숫자를 이진수로 봤을 때, 위 그림의 RWX 왼쪽 숫자와 같이 하나의 수로 표시할 수 있다.

 

FCB마다 그 파일에 대한 접근 권한을 표시할 때 owner, group, public의 접근 권한을 일일이 표시해야 한다.

 

 

2. 동시 접근 시 제어 관리

커널은 컴퓨터 시스템 내부 리소스에 대해 동시에 사용하기 위해 접근하는 것을 엄격하게 통제하고 관리한다.

예를 들면 프로세스가 공유하는 shared data에 접근할 때 race condition이 발생하지 않도록 통제했던 것과 같다.

 

하지만 비교적 파일에는 관여하지 않고, 운영체제가 직접 개입하기 보다는 유저가 관리할 영역으로 남긴다.

1) 운영체제가 아무것도 개입하지 않는 것.

2) lock

파일의 접근에 lock을 걸어서 타인이 접근할 수 없게 할 수 있다.

그러나 특정 파일에 lock을 걸고 푸는것은 사용자가 직접 해야한다.

 

lock을 걸 때, 파일 전체에 걸 수도 있고, 레코드라고 불리는 파일 일부 단위로 lock을 걸 수도 있다.

위는 운영체제마다 다르다.

 

만약 운영체제가 lock을 제공하지 않거나, 사용자가 lock을 사용하지 않는다고 하면, 파일에 동시 접근해서 생길 수 있는 문제는 모두 사용자의 책임이고 서로 소통하며 해결해야한다.