Chapter 3. 디렉토리 트리의 개괄
- Table of Contents
- 배경
- 루트 파일시스템
- /etc 디렉토리
- /dev 디렉토리
- /usr 파일시스템
- /var 파일시스템
- /proc 파일시스템
" Two days later, there was Pooh, sitting on his branch, dangling his legs, and there, beside him, were four pots of honey..." (A.A. Milne)
" 이틀 후에, 푸우가 나타났는데, 그는 나뭇가지 위에 앉아, 다리를 흔들고 있었다, 그리고 거기, 그 옆에는, 네통의 꿀단지가 있었다... " (A.A. Milne의 아기곰 푸우 중에서)
디렉토리는 마치 나뭇가지와도 같은 계층구조를 이루고 있는데, 이를 가리켜 트리(tree) 구조라고 한다. 이번 장에서는 표준 리눅스 디렉토리 트리 구조의 주요 부분을 FSSTND 파일시스템 표준에 근거하여 살펴 볼 것이다. 또한 여기서는 여러가지 목적에 알맞게 디렉토리 구조를 분할하는 일반적인 방법에 대해 개괄적으로 알아 볼 것이며 이렇게 디렉토리를 특별히 분할하는 취지에 관해서 설명할 것이다. 그리고 디렉토리 분할 방법의 몇가지 다른 대안에 대해서도 알아보기로 하겠다.
배경
여기서 다룰 내용은 대체로 리눅스 파일시스템 표준안(Linux filesystem standard, FSSTND, version 1.2 - 참고문헌을 볼 것)에 기반하고 있다. 이 표준안은 리눅스에서 파일시스템을 어떻게 조직할 것인가에 대한 표준을 제정하기 위해 만들어진 문서로서, 이런 표준에 따라 각 파일들의 위치가 일관되게 유지된다면 리눅스용 프로그램의 작성,포팅이 쉬워지고 또한 리눅스 머신을 관리하기도 쉬워지는 등 많은 잇점을 지니게 된다. 사실 이런 표준안이 어떤 강제력을 지니고 있는 것은 아니지만 거의 대부분의 리눅스 배포판에서 이를 따르고 있으며, 특별한 이유없이 이 표준을 어기는 것은 별로 바람직한 일이 못된다. FSSTND는 전통적인 유닉스 방식과 최신 경향을 함께 반영하려 노력하고 있으며, 이를 통해 다른 유닉스 경험자들이 리눅스에 보다 친숙함을 느낄 수 있도록 배려하고 있다. 물론 리눅스 경험자가 다른 유닉스를 접하는 경우에도 마찬가지이겠다.
이번 장에서는 FSSTND에 대해 상세하게 다루지는 않는다. 리눅스 시스템 관리자라면 좀 더 깊이있는 이해를 위해 FSSTND를 꼭 읽어보기 바란다.
또한 여기서는 모든 파일들에 대해 일일이 다루지 않으며 파일시스템의 관점에서 시스템의 구조를 이해하는데 치중할 것이다. 각각의 파일에 대한 정보는 이 문서의 다른 곳을 찾아보거나 매뉴얼 페이지(man page)를 참고하기 바란다.
전체 디렉토리 트리는 분할이 가능하도록 되어 있다. 분할된 각 부분들은 서로 다른 디스크나 파티션에 들어가게 되는데, 이렇게 하면 디스크 공간의 제약에서 벗어날 수 있고 백업하기도 수월해지며 그 밖에 다른 시스템 관리 작업도 한결 손쉬워진다. 파일시스템의 주요 부분을 꼽아보자면 루트(root) 파일시스템, /usr 파일시스템, /var 파일시스템 그리고 /home 파일시스템을 들 수 있으며(Figure 3-1을 보세요), 각 부분들은 서로 다른 의도를 가지고 만들어진 것이다. 이런 디렉토리 트리는, CD-ROM 같은 읽기 전용 장치나 NFS를 통해 파일시스템의 일부를 공유하고 있는 리눅스 머신들의 네트워크에 알맞도록 설계되어져 왔다.
아래에 디렉토리 트리 각 부분의 역할에 대하여 설명하였다.
루트 파일시스템은 각 머신마다 고유한 것으로서(비록 루트 파일시스템이 램 디스크나 네트워크 드라이브에 있을 수도 있지만, 보통 로컬 디스크에 있는 것이 일반적이다), 시스템을 부팅시키고 다른 파일시스템을 마운트할 수 있는 상태로 만드는데 필요한 파일들을 갖고 있다. 또한 루트 파일시스템은 단일 사용자 상태를 위한 파일들을 포함하고 있으며, 파일시스템을 수리하고 손상된 부분을 백업으로부터 복구하는데 필요한 도구들을 갖추고 있다.
/usr 파일시스템에는 시스템이 정상적으로 가동되는 데에 필요한 모든 명령들과 라이브러리들 그리고 매뉴얼 페이지들이 위치한다. /usr 파일시스템에 있는 파일들은 어떤 머신에 한정된 것이어서는 안되며, 보통 실행 도중에 그 내용이 고쳐질 필요가 없는 것들이어야 한다. 이렇게 하면 네트워크 상에서 파일들을 공유하는 것이 가능해지는데, 이를 통해 디스크 공간을 절약하여 비용절감의 효과를 누릴 수 있고(/usr 파일시스템은 보통 수백메가바이트 이상의 공간을 차지한다) 시스템 관리도 쉽게 할 수 있다(응용프로그램을 업데이트하기 위해선 공유되고 있는 /usr 파일시스템만 업데이트하면 된다. 즉 머신 하나하나에 손댈 필요가 없다). /usr 파일시스템은 로컬 디스크에 있는 경우라 하더라도 언제나 읽기 전용으로 마운트하는 것이 좋은데, 이것은 시스템이 크래쉬된 경우에 파일시스템이 손상되는 것을 방지하기 위한 것이다.
/var 파일시스템은 스풀(spool) 디렉토리들, 로그 파일들, 포맷된 매뉴얼 페이지들, 그리고 각종 임시파일들 같은, 계속 변화하는 파일들을 위한 공간이다. 전통적으로는 이런 파일들을 /usr 아래에 넣어 두는 것이 관례였는데, 이렇게 되면 /usr를 읽기 전용으로 마운트할 수 없기 때문에 별로 바람직한 일이 못된다.
/home 파일시스템은 각 사용자들의 홈 디렉토리를 갖고 있으므로, 이곳은 아주 중요한 데이터들이 있는 곳이라고 할 수 있겠다. 이렇게 /home을 독립적인 파일시스템으로 만들어 두는 이유는 백업을 쉽게 하기 위해서이다; 즉, /home 이외의 부분들은 거의 변동이 없기 때문에 백업을 그렇게 자주 받아둘 필요는 없다. 그러나 홈 디렉토리들은 무척 중요하므로 따로 백업을 자주 받아두어야 한다. /home 파일시스템이 비대해지면 이것을 다시 /home/students 또는 /home/staff 같이 하위 파일시스템으로 세분화하는 것이 좋겠다.
위에서 각 부분들이 서로 다른 파일시스템인 것으로 가정했지만, 사실 꼭 그렇게 해야만 하는 것은 아니다. 만일 단일 사용자용 시스템이거나 관리를 단순하게 하고 싶은 경우라면 모든 것을 하나의 파일시스템에 몰아 넣는 것도 가능하다. 또한 위에서 제시한 방법 이외에도, 여러가지 상황에 따라 얼마든지 다른 형태로 파일시스템을 구성할 수 있다. 중요한 것은, /usr나 /var 같은 표준적인 이름들을 사용할 수 있도록 해야 한다는 것이다; 즉, 만일에 /var가 /usr 파일시스템의 아래에 존재한다고 하더라도 /usr/lib/libc.a 또는 /var/log/messages 같은 경로들을 사용할 수 있어야만 한다. 이런 경우에는 /var를 /usr/var의 심볼릭 링크로 만들어 둠으로써 표준을 지키도록 할 수 있다.
유닉스 파일시스템 구조에서, 같은 목적의 파일들은 같은 장소에 보관된다. 즉 모든 명령들과, 모든 데이터들, 모든 문서들은 각기 독립적인 장소에 따로 보관된다. 그런데 같은 목적의 파일들을 구분하는데는 좀 다른 원칙이 적용될 수도 있다. 즉 모든 Emacs용 파일들과 모든 TeX용 파일들을 구분해서 각각 다른 곳에 모아두는 식이다. 하지만 두번째 방식을 채택한다면 파일을 공유하기가 어려워질 뿐더러(각각의 프로그램 디렉토리는 공유가능한 파일들과 그렇지 않은 파일들을 함께 가지고 있을 것이기 때문이다) 원하는 파일을 찾아내는 일도 쉽지 않게 되는 단점이 있다(만일 매뉴얼 페이지들이 엄청나게 다양한 장소에 흩어져 있다면, 매뉴얼 페이지 검색 프로그램을 만드는 일은 아마 끝없는 악몽으로 여겨질 것이다).