당신이 유닉스 체제 아래에서 하드 디스크를 바라볼 때, 디렉토리와 파일이라 이름지어진 구조를 보게 될 것이다. 보통 그 이상의 지식이 필요하지는 않지만, 디스크가 고장났을 경우 데이터를 복구하고자 한다면 그 아래에서 어떤 기작이 일어나는지를 알고 있는 것은 유용하다. 불행하게도 파일 단계에서 그 하위 구조로 디스크의 구성을 설명하는 것은 좋은 방법이 아니기 때문에, 나는 이것을 하드웨어 쪽에서 상위 단계로 올라오면서 설명할 것이다.
데이타가 저장되는 디스크의 표면은 다트 게임판과 같이 나누어져 있다. -- 원형의 트렉(track)과 파이 조각과 같은 섹터(sector)로 나누어져 있다. 바깥쪽 끝의 트렉은 안쪽의 트렉보다 넓기 때문에 보다 많은 섹터로 나누어지게 된다. 각각의 섹터(혹은 디스크 블록)은 같은 크기로 이루어져 있고, 오늘날의 유닉스 시스템에서는 일반적으로 1 바이너리 K (8비트 단어 1024개의 분량)로 이루어진다. 각각의 디스크 블록은 고유한 주소를 갖는데 이를 디스크 블록 숫자라 한다.
유닉스는 디스크를 디스크 파티션으로 나눈다. 각각의 파티션들은 파일 시스템에서 사용하던지 혹은 스왑 공간에서 사용하던지 간에 다른 파티션에서 따로 사용되는 블록의 연속이다. 가장 낮은 번호를 갖는 파티션은 특별하게 취급되는데, 그것은 부트 파티션이라 하며 시스템이 시작되기 위해 커널을 넣을 수 있는 파티션이다.
각각의 파티션은 스왑 공간(때로는 가상 메모리라 불리운다) 혹은 파일들이 담겨있는 파일 시스템 가운데 하나로 사용된다. 스왑 공간으로 사용되는 파티션은 블록이 선형 연결(linear sequence) 로 취급된다. 반면에 파일 시스템은 파일 이름과 디스크 블록의 연결에 대한 지도를 필요로 한다. 파일들이 커지거나 줄어들거나, 혹은 시간에 따라 변화하면서, 파일의 데이타 블록은 선형으로 유지되지 않고 보통 한 파티션 내에 뿔뿔이 흩어지게 된다(운영체계는 자신이 필요로 할 때 비어있는 블록을 찾아낼 수 있는데, 파일들이 새로운 블록을 필요로 할 때에는 운영체계에서 이런 블록들을 건네받게 된다).
각각의 파일 시스템에서 이름과 블록 사이의 관계(매핑;mapping)은 i-node라 불리우는 구조체를 통해 다루어진다. 이것들은 각각의 파일시스템의 ``바닥''(가장 낮은 숫자를 가지는 블록; 실은 그보다 낮은 블록들이 기본적인 정보와 이름을 붙이기 위해(labeling) 사용되는데 이 문서에서는 다루지 않기로 한다) 근처에 집합적으로 존재한다. 각각의 i-node들은 하나의 파일을 기술하고 있으며, 파일 데이타 블록은 inode 위에 존재하게 된다.
모든 i-node는 자신이 기술하고 있는 파일의 디스크 블록 숫자들의 리스트를 가지고 있다. (사실 이 말은 반만 맞다. 작은 파일들에 대해서만 이 말이 성립되지만, 그 이외의 사실은 이곳에서 다루어질 만큼 중요하지 않다.) 여기서 i-node가 파일의 이름을 가지고 있지 않다는 것을 주의하기 바란다.
파일 이름들은 디렉토리 구조 안에 존재한다. 디렉토리 구조는 파일 이름들과 i-node 숫자들을 연결시켜 주는 지도 역할을 한다. 이것은 유닉스에서 하나의 파일이 여러개의 이름(true name; 혹은 하드 링크)을 가질 수 있는지 설명해 준다; 이것은 단지 여러개의 디렉토리 엔트리에서 같은 inode를 가리키고 있는 것이다.
가장 간단한 경우, 당신의 모든 유닉스 파일 시스템은 하나의 디스크 파티션에 존재한다. 하지만, 당신이 이런 경우를 개인적 용도의 작은 유닉스 시스템에서 사용되는 것을 본 적이 있을지 몰라도, 이런 방법은 일상적인 것이 아니다. 보다 전형적인 방법은 여러 개의 디스크 파티션이, 서로 다른 물리적 디스크에 나누어져 존재하는 것이다. 따라서, 한 예로, 시스템에 커널이 존재하는 작은 하나의 파티션이 존재한다면, 그보다 약간 큰 파티션에 운영체계 유틸리티들이 존재하고, 보다 큰 파티션에 사용자들의 홈 디렉토리가 존재하는 것이 일반적이다.
커널은 유닉스 파일 시스템의 루트 파티션에서 시작된다. 먼저 루트는 `홈(home)' 디렉토리를 찾는다. 일반적으로 시스템이 부팅된 직후 당신이 접근할 수 있는 것은 유일하게 루트 파티션이고, 이것은 (거의 항상) 부팅이 처음 시작되는 곳이기도 하다. 루트 파티션의 파일 시스템에는 루트 디렉토리가 존재하며, 다른 어떤 것보다 우선하는 노드를 가진다.
시스템의 다른 파티션은 이 루트 파티션에 덧붙여지게 되는데, 그럼으로서 모든, 여러 파티션의 파일 시스템이 접근 가능하게 된다. 부트 프로세스 가운데에는 유닉스 시스템이 루트 이외의 다른 파티션을 접근 가능하게 만드는 과정이 포함되어 있다. 이 과정을 통해서 루트 파티션의 디렉토리로 각각의 파티션이 마운트되는 것이다.
한 예로, `/usr'라는 유닉스의 디렉토리를 가지고 있다면, 이것은 아마 처음 부팅 과정에서는 필요하지 않지만, 시스템에 설치되어 있는 많은 응용 프로그램들을 담고 있는 파티션이 마운트되는 포인트를 가리킨다.
이제 파일 시스템을 상위 레벨에서부터 아래로 바라볼 수 있게 되었다. 당신이 파일(예를 들면, /home/esr/WWW/ldp/fundamentals.sgml 파일)을 열 때 다음과 같은 작업이 수행된다.
커널은 유닉스 파일 시스템의 루트(루트 파티션)에서 시작한다. 다음에 이것은 `home'이라 불리는 디렉토리를 찾는다. 일반적으로 `home'은 일반 사용자들이 쓰는 큰 파티션의 마운트 포인트이고, 따라서 그 곳을 찾아가게 된다. 그 유저 파티션의 최상위 단계의 디렉토리 구조에서, 다음에 `esr'이라는 엔트리를 찾고 inode 숫자를 골라낸다. i-node는 이것이 디렉토리 구조라는 것을 알려줄 것이고, 다음에 `WWW'를 찾게 된다. 그것의 i-node를 받은 다음 적당한 하위 디렉토리 `ldp'를 다시 찾아간다. 이것은 다시 적당한 다른 디렉토리의 inode를 줄 것이다. 그것을 연 다음에는 `fundamentals.sgml' 에 대한 i-node 숫자를 갖게 될 것이다. 그 inode는 디렉토리가 아니기 때문에, 파일에 관련된 디스크 블록의 목록을 가지고 있다.
앞에서 파일 시스템이 깨지기 쉬운 것임을 얼핏 언급했었다. 이제 우리는 디렉토리와 i-node 레퍼런스의 임의적인 긴 사슬과 같이 파일이 이루어져 있다는 사실을 알게 되었다. 그런데 당신의 하드 디스크에 오류를 포함한 지점이 생겼다면?
당신이 운이 좋다면 단지 몇 개의 파일 시스템이 파괴되었을 것이다. 만약 당신이 운이 좋지 못하다면, 디렉토리 구조나 i-node 숫자가 파괴되었을 수도 있고, 시스템의 하위구조가 모두 지워져 버릴 수도 있다. 혹은, 더 나쁜 경우, 망가진 구조가 같은 디스크 블록이나 inode를 여러가지 방법으로 가리키고 있을 수도 있다.(한마디로 파일 시스템이 얽히는 것이다.) 이런 손상은 정상적인 파일 조작으로 번져나갈 수 있고, 원래 손상된 지점에서 데이터의 손상은 점점 커지게 될 것이다.
다행스럽게도, 이런 종류의 뜻밖의 사고는 하드 디스크가 보다 신뢰성있게 만들어지면서 매우 드문 것이 되었다. 하지만 아직도, 유닉스 시스템은 파일 시스템이 안전하게 보전되어 있는지를 확인하는 integrity-check를 주기적으로 하고 있으며, 그 결과 모든것이 정상적이라는 것을 확인하고 싶어한다. 현대의 유닉스 시스템은 각각의 파티션에 대해 부팅 과정에서 마운트가 이루어지기 전에 무결성을 확인한다. 재부팅을 할 때에는 보다 철저한 검사가 이루어지기 때문에 약간의 시간이 더 걸린다.
만약 이 모든 것들에서 유닉스가 매우 복잡하고 손상받기 쉬운 것이라고 생각된다면, 부팅될 때의 검사로 보통 이 에러들을 잡아낼 수 있고, 또한 그 에러들이 심각한 문제로 발전하기 전에 고쳐질 수 있다는 것에서 또한 안심을 하게 될 것이다. 다른 운영체계는 이런 장치가 되어있지 않기 때문에, 부팅이 빠르게 이루어질 수 있지만, 그런 오류를 수동으로 복구하려고 할 때 (당신이 만약 노턴 유틸리티와 같은 프로그램을 처음에 가지고 있었다고 가정할 때 가능한 일이지만) 심각하게 문제가 복잡해질 수 있다.