[운영체제] 파일 시스템 + 하드링크 / 소프트링크

파일 시스템

 

파일 시스템이란 파일과 디렉토리를 보조 기억 장치에 저장하고 접근할 수 있게 하는 운영체제 내부의 프로그램이다.

 

운영 체제는 파일을 블록이라는 작은 단위로 쪼개고, 이 블록 단위로 읽고 쓴다. 즉 하나의 파일은 하나 이상의 블록에 걸쳐 저장되며, 크기가 클 수록 블록의 갯수도 많아진다. 만약 보조 기억 장치에 연속적으로 블록 파일이 할당되어 있으면 외부 단편화 문제가 발생할 수 있다.

 

 

파일 A

빈공간 (3K)

파일 B

파일 C

빈 공간(7K)

 

보조 기억 장치의 현재 상황이 위와 같다고 해보자. 이때 10K의 파일을 저장할 수 있을까? 분명 빈 공간은 3K + 7K = 10K이지만 연속되어 있지 않기 때문에 10K의 파일은 저장할 수 없다. 이것이 외부 단편화 문제이다. 그래서 현재는 불연속적으로 블록 파일을 저장하는 방법을 활용한다.

 

 

 

불연속 할당의 첫 번째 방법은 연결 할당(linked allocation)이다. LinkedList처럼 각 블록마다 다음 블록의 주소를 저장하여 관리하는 것이다. 이 방법은 현재는 주로 저용량 저장 장치 등에서 사용하는 FAT 파일 시스템으로 구현되고 있다.

 

두 번째는 색인 할당(indexed allocation)이다. 파일의 모든 블록 주소를 색인 블록(index block) 이라는 하나의 블록에 모아서 관리하는 방식이다. 예를 들어 파일a의 데이터가 7번, 13번, 11번 블록에 저장되어 있다면 파일a의 색인 블록에 7, 13, 11을 저장해두는 것이다. 이 색인 할당을 기반으로 만든 파일 시스템이 유닉스 파일 시스템이다.

 

 

 

 

 

i-node

 

유닉스 파일 시스템에서는 파일의 모든 블록 주소를 저장해둔 색인 블록을 i-node(index-node)라고 부른다. 그리고 모든 파일은 이러한 i-node를 각자 가지고 있다. i-node의 사이즈는 파일 시스템마다 조금씩 다르지만, 일반적으로 1~4kb정도의 작은 용량을 가지고 있다.

 

 

 

 

파일 A
블록 1	블록 2	블록 3	블록 4	블록 5
블록 6	블록 7	블록 8	블록 9	블록 10
블록 11	블록 12	블록 13	블록 13	블록 15

 

15개의 블록으로 이루어진 파일 A가 있다고 생각해보자. 이때 i-node는 각블록의 주소를 어떻게 저장해둘까?

 

 

 

i-node의 구조

meta data

direct block

single indirect block

double indirect block

triple indirect block

 

meta data에는 파일 크기, 생성 시간, 마지막 접근 시간, 마지막 수정 시간, 소유자 등 파일A의 속성 정보가 저장되어 있다. 그리고 아래의 direct block, single indirect block, double indirect block, triple indirect block 이 블록의 주소를 저장하는 공간이다.

 

 

 

 

 

먼저 direct block에는 파일 블록의 주소를 직접적으로 저장해둔다. 예를 들어 블록1이 100이라는 주소에 저장되어 있으면, direct block에도 100이라는 주소가 저장되어 있다.

 

이 direct block에는 12개의 블록 주소를 저장해둘 수 있다. 즉, 블록 1부터 블록 12까지의 주소가 direct block에 저장되어 있다. 그런데 아직도 파일A는 3개의 블록을 더 가지고 있다. 이 블록들의 주소는 어떻게 저장할까?

 

 

 

 

단일 간접블록

블록13 주소

블록14 주소

블록15 주소

 

이럴 경우, 단일 간접 블록이라는 새로운 블록을 활용하게 된다. 이 블록에는 블록들의 주소가 저장되어 있다. 블록의 주소를 확인하려면 단일 간접 블록으로 이동한 후 단일 간접 블록에 저장된 파일 데이터 블록의 주소를 확인하면 되는 것이다. 그렇기 때문에 i-node 상의 single indirect block은 이 간접 블록의 주소를 가리키고 있다. 

 

 

 

출처: https://stackoverflow.com/questions/29226587/does-the-inode-actually-point-to-an-address-in-the-disk

 

 

만약 단일 간접 블록으로도 파일A의 모든 블록을 가리킬 수 없다면 단일 간접 블록들의 주소를 모아둔 이중 간접 블록을 생성하고, double indirect block에 이중 간접 블록의 주소를 저장한다. 이것으로도 부족하다면 이중 간접 블록들의 주소를 모아둔 삼중 간접 블록의 주소를 triple indirect block에 저장한다.

 

 

 

 

 

 

링크 (하드링크, 소프트링크)

 

리눅스의 하드링크와 소프트링크는 운영체제에 해당하는 내용은 아니지만, i-node와 밀접한 관련이 있기 때문에 함께 설명하고자 한다. 이 링크는 쉽게 생각하면, 파일의 복사본을 만드는 것이다. 다만 cp 명령어를 통한 복사와는 다르게 데이터 블록을 복제하는 것이 아니라 데이터 블록의 주소만을 복사한다고 생각하면 된다.

 

하드링크란, 링크한 파일로 하여금 직접적으로 원본 파일의 i-node를 가리키게 하는 것이다. 반면 소프트링크란, 링크한 파일의 i-node를 생성하고, 링크한 파일의 i-node가 원본 파일의 i-node를 가리키게 하는 것이다.

 

 

 

 

 

 

하드 링크

 

 

[pwd : 현재 경로 확인 / ls : 현재 경로에 위치한 파일과 디렉토리 확인]

 

현재 우분투의 /home/ubuntu 디렉토리에는 text.txt라는 파일이 저장되어 있다.  이 text.txt의 i-node를 편의상 i-node1이라고 해보자.

 

 

 

[ln 원본 하드링크이름]

ln이라는 명령어를 사용해 text.txt를 하드링크한 text_hard.txt를 생성했다. 이렇게 하드 링크를 하게 되면, text.txt와 text_hard.txt는 같은 i-node1을 공유하게 된다.

 

 

 

 

[rm: 파일 삭제 / cat: 파일 데이터 확인] 

 

따라서 원본 파일인 text.txt를 지우더라도 text_hard가 여전히 i-node1을 가리키고 있기 때문에 정상적으로 데이터를 확인할 수 있다. 또한 text.txt를 수정하든, text_hard.txt를 수정하든 상관없이 데이터 수정(동기화)이 이루어진다.

 

 

 

 

 

 

 

 

소프트링크 (심볼릭 링크)

 

 

다시 이 상황으로 돌아가보자. 이번에는 text.txt 파일을 소프트링크 할 것이다.

 

 

 

[ln -s 원본 소프트링크이름]

 

ln -s 명령어를 통해 text파일을  소프트링크한 text_soft파일을 생성시켰다. 이 상태에서 text.txt를 지우면 어떻게 될까?

 

 

 

text.txt를 삭제한 후 text_soft.txt파일을 읽으려고 하니 No such file or directory라는 오류 메세지가 뜬다.

 

소프트링크를 하게 되면, text_soft는 i-node1을 공유하지 않고, 자체적인 i-node를 생성시킨다. 이 i-node2는 i-node1을 가리키고 있다. 그런데 text_txt를 삭제하면서 i-node1이 함께 삭제되었기 때문에 i-node2에 저장된 주소로는 원본 파일을 찾아갈 수가 없는 것이다.

 

쉽게 이야기하면 소프트링크는 윈도우os의 바로가기와 비슷한 기능을 한다. 원본 파일이 삭제되면 더이상 바로가기는 동작하지 않는다. 

 

 

 

 

 

정리

 

우선 ln을 통해 하드링크나 소프트링크를 하게 되면, cp로 데이터를 복제할 때보다 용량적인 부분에서 효율적이다. 새로운 데이터 블록을 위한 공간을 할당할 필요가 없기 때문이다.

 

하드 링크의 경우, 원본 파일이 사라지더라도 하드 링크를 통해 원본 파일에 접근할 수 있기 때문에 데이터를 안전하게 관리할 수 있다. 하지만 하드 링크는 디렉토리 링크가 불가능하다는 단점이 있다. 이러한 단점을 해결해주는 것이 바로 소프트링크이다.