3. 내가 필요로 하는 파티션은 무엇인가?

3.1 나는 얼마나 많은 파티션이 필요할까?

당신은 어떤 파티션이 필요한가? 어떤 운영 체제들은 얼토당토않은 이유로 논리 파티션에서 부팅하지 못하도록 되어 있다. 따라서 당신은 아마 MS-DOS, OS/2, 리눅스 등등 사용 중인 운영 체제의 부트 파티션으로 쓰기 위해 프라이머리 파티션을 남겨 두기를 바랄 수도 있다. 프라이머리 파티션 하나는 확장 파티션으로서 필요하다는 것도 염두에 두도록 하라. 확장 파티션은 나머지 디스크 공간을 논리 파티션으로 쓰기 위해 담아두는 그릇 노릇을 한다.

부팅 가능한 운영 체제는 BIOS와 1024 실린더의 한계를 포함하는 real-mode여야 한다. 때문에 당신은 말썽을 피하기 위해 부트 파티션들을 모두 앞쪽 1024 실린더 이내에 두기를 원할 것이다. 자세한 내용은 역시 "large-disk" 미니 하우투를 참조하라.

리눅스를 설치하려면 최소한 하나의 파티션이 필요하다. 커널이 이 파티션으로부터 (예를 들면 LILO에 의해) 적재된다면, 이 파티션은 BIOS가 읽을 수 있는 것이어야만 한다. 만일 (예를 들어 부트 디스크나 MS-DOS에 기반한 리눅스 로더인 LOADLIN.EXE 같은) 다른 방법으로 커널을 적재한다면, 리눅스 파티션은 어디 있어도 괜찮다. 어떤 경우이건 이 파티션은 0x83 "Linux native" 형식이어야 한다.

시스템에는 스왑 공간이 필요하다. 스왑을 파일에다 하지 않겠다면, 스왑 전용 파티션이 하나 있어야 한다. 이 파티션은 리눅스 커널에 의해서만 사용되고 커널은 PC BIOS의 의존성에 구속받지 않으므로, 스왑 파티션은 어디에 있어도 좋다. 필자는 스왑 파티션으로는 논리 파티션(/dev/?d?5나 그 이상)을 쓰도록 권장한다. 리눅스 스왑 전용 파티션은 0x82 "Linux swap" 형식이다.

이상이 최소로 요구되는 파티션이다. 하지만 리눅스용 파티션을 더 만들어 두는 편이 좋다. 계속 읽도록 하라.

3.2 파티션의 크기는 얼마나 되어야 할까?

스왑 전용 파티션을 쓰기로 했다면, 대개의 경우 옳은 선택이다. 다음 안내를 따라 그 크기를 결정하도록 하라.

• 리눅스에서는 램과 스왑 공간이 더해진다. (모든 유닉스 시스템에서 이런 것은 아니다.) 예를 들어 8메가의 램과 12메가의 스왑이 있다면, 당신은 총 20메가 정도의 가상 메모리를 갖게 된다.
• 스왑 공간의 크기를 정할 때, 최소한 총 16메가의 가상 메모리를 갖도록 해야 한다. 즉 램이 4메가 있는 경우라면 최소한 12메가의 스왑을 잡아야 하고, 8메가의 램이 있다면 적어도 스왑 8메가를 잡아야 한다.
• 리눅스에서는 한 스왑 파티션의 크기가 128메가를 넘을 수 없다. 파티션의 크기는 128메가 보다 클 수도 있지만, 128메가 이상의 공간은 절대로 사용되지 않기 때문이다. 따라서 128메가 이상의 스왑이 필요하면, 스왑 파티션을 여러 개 만들어야 한다.
• 스왑 공간의 크기를 정할 때에는 너무 많은 스왑 공간은 전혀 쓸 데 없다는 점을 명심해야 한다. 모든 프로세스는 "working set"을 갖는다. Working set이란 프로세서에 의해 곧 참조될 메모리에 올려진 페이지들의 집합이다. 리눅스는 (최근 사용된 페이지들이 가까운 장래에 다시 사용되리라고 가정함으로써) 이 메모리 접근을 예측하고자 한다. 그리고 가능한 한 이 페이지들을 램 내에 남겨두려고 노력한다. 프로그램의 "참조의 국소성"이 좋으면 이 가정은 참이 되고, 예측 알고리즘이 제 몫을 할 것이다. Working set을 주 메모리에 남겨 두는 것은 충분한 주 메모리가 있을 경우에만 작동한다. 한 컴퓨터에서 지나치게 많은 프로세스를 실행시키면, 커널은 매우 가까운 장래에 다시 참조될 페이지들을 디스크에 넣어 두도록 강요받게 된다. (다른 working set에서 한 페이지를 메모리에서 내리고, 막 참조된 페이지를 메모리에 올리도록 한다.) 대개 이런 상황은 페이지 관리 작업을 매우 증가시키고, 작업 수행 능력을 현저히 저하시킨다. 이런 상태에 있는 컴퓨터를 "몸부림치고 있다(thrashing)"고 한다. (For you german readers: That's "thrashing" ("dreschen", "schlagen", "haemmern") and not trashing ("muellen")) 몸부림치고 있는 컴퓨터에서는 프로세스들이 램이 아니라 디스크로부터 수행되고 있다. 메모리 접근 속도와 디스크 접근 속도의 비 정도로 수행성능이 저하되리라고 생각하면 된다. PDP와 Vax가 쓰이던 옛 시절의 경험적인 원칙 하나는 한 프로그램의working set의 크기는 그 프로그램의 가상적인 크기의 1/4정도라는 것이다. 따라서 램의 세 배 이상 스왑을 잡는 것은 대개 소용없는 일이다. 하지만 이 것은 단지 한 가지 경험 법칙일 뿐이라는 점을 명심하기 바란다. 엄청나게 크거나 지독히 작은 working set을 갖는 상황을 만들기란 쉬운 일이다. 예를 들어 매우 불규칙적으로 이용되는 커다란 데이터집합을 갖는 시뮬레이션 프로그램이라면, 데이터 참조에 있어서 눈에 띌 만 한 국소성이란 거의 없다. 따라서 이런 프로그램의 working set은 상당히 클 것이다. 한편 여러 JPEG 파일들을 동시에 열어 놓았지만 하나 만 빼고는 모두 아이콘화시켜 놓은 xv 프로그램은 매우 큰 데이터를 갖는다. 그러나 이미지 전환은 하나의 이미지에서만 이루어지고, xv가 차지하고 있는 메모리의 대부분은 전혀 건드리지 않는다. 여러 개의 편집기 창을 가지지만 한 번에 하나의 창에서만 편집이 되는 편집기도 마찬가지 경우다. 이런 프로그램들은 제대로 설계되었다면 매우 높은 참조의 국소성을 가지며, 프로그램의 대부분이 큰 성능 저하 없이 스왑 공간으로 내려질 수 있다. 커맨드 라인 시대에 통하던 1/4이라는 working set 크기가 요즘처럼 여러 개의 문서를 편집하는 GUI 프로그램에서도 맞을지 의심스러울 수도 있지만, 필자가 아는 바로는 이 수치를 확인하려고 시도한 새로운 논문은 없다.

따라서 16메가의 램을 가진 상황이라면, 최소한의 설정을 위해서는 스왑이 필요 없고, 48메가 이상의 스왑은 아마 쓸모 없을 것이다. 정확히 얼마나 메모리가 필요한지는 응용 프로그램과 컴퓨터에 달려있다. (다른 무엇을 기대했나?)

3.3 스왑 공간의 위치는 어디가 좋을까?

• 기계적인 것은 느리고, 전자적인 것은 빠르다. 요즘의 하드디스크에는 많은 헤드가 있다. 같은 트랙의 헤드 사이를 오가는 것은 완전히 전자적인 것이어서 빠르다. 반면 트랙들 사이를 오가는 것은 느린데, 실제 물체를 움직이는 일이 포함되기 때문이다. 따라서 헤드가 많은 디스크와 적은 디스크가 있다면, 다른 사양이 같을 경우에는 헤드를 많이 가진 쪽이 빠를 것이다. 하지만, 스왑 공간을 나누어서 두 개의 디스크에 두는 편이 더 빠를 것이다.
• 구형 디스크에는 모든 트랙에 같은 숫자의 섹터가 있다. 이런 디스크의 경우에는, 디스크 헤드가 임의의 트랙에서 스왑 영역으로 간다고 가정하면 스왑을 디스크 중간에 잡는 것이 가장 빠를 것이다.
• 신형 디스크는 ZBR(zone bit recording)을 사용한다. 이런 디스크는 바깥 쪽 트랙에 더 많은 섹터를 갖고 있다. Rpms가 일정하다면, 이런 구조에서는 바깥 쪽 트랙이 안쪽 보다 훨씬 우수한 성능을 보인다. 스왑은 빠른 트랙에 두어야 한다.
• 물론 디스크 헤드가 무작위로 움직이지는 않을 것이다. 늘 바쁜 home 파티션과 거의 사용되지 않는 보관용 파티션 사이에 스왑 공간을 두고 있다면, 헤드가 덜 움직이도록 스왑을 home 파티션 중간에 두는 편이 낫다. 스왑을 거의 스왑 전용인 다른 디스크에 잡는다면 훨씬 더 좋을 것이다.

요약: 스왑은 빠르고, 헤드를 많이 가지고 있으며, 다른 작업에 바쁘지 않은 디스크에 잡아라. 디스크를 여러 개 가지고 있다면, 스왑을 쪼개서 디스크마다 혹은 제어기(controller)마다 두도록 하라.

더 나은 방법: 램을 더 사라.

3.4 파일 시스템과 파편화에 대한 몇 가지 것들.

운영 체제는 디스크 공간을 블록과 블록의 조각(fragmentation) 단위로 관리한다. Ext2 파일 시스템에서는 조각과 블록이 같은 크기이기 때문에, 이 글에서는 블록에 대해서만 이야기하도록 하겠다.

파일의 크기는 다양하다. 파일이 블록의 크기에 딱 맞는 일은 없다. 따라서 모든 파일의 마지막 블록 가운데 일부는 낭비되게 된다. 파일의 크기가 불규칙하다면 디스크에 들어 있는 모든 파일들은 각각 반 블록 정도의 낭비되는 부분을 갖게 된다. 탄넨바움 씨는 자신의 저서 "운영 체제"에서 이것을 "파편화(fragmentation)"이라고 불렀다.

파일의 개수는 대략 디스크에 있는 할당된 inode의 개수와 같다고 추정할 수 있다. 필자의 디스크에는

---

# df -i

Filesystem           Inodes   IUsed   IFree  %IUsed Mounted on

/dev/hda3              64256   12234   52022    19%  /

/dev/hda5              96000   43058   52942    45%  /var

---

/에 약 12000 개의 파일이 있고, /var.에는 약 44000 개의 파일이 있다.

블록 하나의 크기가 1KB인 경우, 파일 꼬리에 붙은 약 6+22 = 28MB의 디스크 공간이 손실된다. 만약 블록 하나의 크기가 4KB였다면, 필자는 네 배의 공간을 손해보았을 것이다.

반면에 데이터의 전송은 인접 데이터 덩어리가 큰 경우에 더 빠르다. 때문에 ext2 파일 시스템에서는 점점 커지는 파일에 대해서는 8 개의 인접 블록을 한 단위로 하여 공간을 미리 배분하도록 한다. 사용되지 않은 사전 할당 공간은 파일이 닫혀질 때 놓여나므로, 공간의 낭비는 없다.

한 파일 안의 블록들이 인접해 있지 않다면, 파일이 종종 차례로 접근되기 때문에 성능에 좋지 않다. 이렇게 되면 운영 체제가 디스크 접근을 나눠서 해야 하고, 디스크도 헤드를 움직여야 하게 된다. 이런 상황을 "외적 파편화" 혹은 간단히 "파편화"라고 부르며, 도스 파일 시스템에서 흔한 문제다.

Ext2 파일 시스템에는 외적 파편화를 방지하기 위한 몇 가지 전략이 있다. 보통 ext2에서는 유즈넷 뉴스 스풀처럼 혹사되는 파티션의 경우에도 파편화가 큰 문제가 되지 않는다. Ext2 파일 시스템에도 파편화된 것을 정리해주는 도구가 있지만, 아무도 이 도구를 쓴 일이 없고 현재 쓰이는 ext2에 비하면 구식이다. 한 번 해 봐도 되지만, 문제가 생기면 당신이 책임져야 한다.

MS-DOS 파일 시스템은 병적인 디스크 공간 관리로 유명하다. MS-DOS에서 쓰는 최악의 버퍼 캐쉬와 더불어, 파일 파편화가 수행 성능에 끼치는 영향은 정말 엄청나다. DOS 사용자들은 몇 주마다 디스크의 파편화 상태를 정리하는데 익숙해진 나머지, 파편화를 정리하는데 대해 약간은 종교적인 신념까지 생기게 되었다. 리눅스와 ext2 파일 시스템에서는 이런 습관이 필요 없다. 정상적으로 사용한다면 리눅스 본래의 파일 시스템에서는 파편화를 정리할 필요가 없다. 디스크에 최소한 5%만 빈 공간이 있다면 어떤 경우에도 괜찮다.

MS-DOS 파일 시스템은 내적 파편화 때문에 많은 디스크 공간을 낭비하는 것으로도 잘 알려져 있다. 256메가 이상의 파티션에서는, DOS 블록의 크기가 너무 커져서 더 이상 쓸모가 없어져 버린다. (이런 점은 FAT32에서는 어느 정도 고쳐졌다.)

Ext2는 0.5 TB (1테라 바이트는 1024 기가 바이트와 같다) 이상의 엄청나게 큰 파일 시스템만 아니라면, 대형 파일 시스템에서도 큰 블록을 선택할 필요가 없다. 0.5 테라 이상인 경우에는 작은 크기의 블록이 효율적이지 않게 된다. 따라서 DOS와는 달리 블록 크기를 줄이려고 큰 디스크를 여러 파티션으로 쪼갤 필요가 없다. 가능하다면 1 킬로바이트의 디폴트 블록 크기를 쓰도록 하라. 어떤 파티션에 대해서는 2 킬로바이트 짜리 블록 크기를 시험해 보고 싶을 수도 있지만, 흔치 않은 버그와 맞닥뜨리기 십상이다. 대부분의 사람들은 디폴트를 쓴다.

3.5 파티션 결정 기준으로서의 파일 수명과 백업 주기

Ext2에서는 백업 계획과 다양한 파일 수명에 따른 외적 파편화를 줄일 것을 염두에 두고 파티션을 결정해야 한다.

파일은 수명을 갖는다. 한 파일은 만들어진 다음 시스템에 어느 시간 동안 남아 있다가 지워지게 된다. 파일의 수명은 시스템에 따라 크게 다르고, 부분적으로는 파일의 경로 명에도 의존하게 된다. 예를 들어 /bin, /sbin, /usr/sbin, /usr/bin나 이 비슷한 디렉터리에 있는 파일들은 대개 여러 달 이상의 매우 긴 수명을 갖는다. /home에 있는 파일들의 수명은 여러 주쯤으로 중간 정도이다. /var의 파일들은 보통 수명이 짧다. /var/spool/news에 있는 파일들은 며칠 이상 남아있는 것이 드물고, /var/spool/lpd에 속한 파일들의 수명은 몇 분 남짓이다.

백업을 위해서는 하루에 백업할 양이 백업 매체 하나의 용량 이하인 쪽이 편하다. 매일 이루어지는 백업은 전체 백업일 수도 있고, 바뀐 부분만 추가해 가는 식(incremental)일 수도 있다. 따라서 (매일 전체 백업을 하기 위해서) 파티션의 크기를 한 백업 매체에 완전히 들어갈 정도로 작게 잡을 수 있다. 어떤 경우이건, 파티션 하나의 크기는 매일 바뀐 파일 전부가 백업 매체 하나에 들어갈 만한 크기여야만 한다. (추가식 백업을 택하고 백업 매체는 주 혹은 월 단위의 전체 백업 때 바꾸도록 한다. 이 경우 자동 백업은 불가능하다.)

백업 전략은 이 결정에 달려있다.

디스크 공간을 계획하고 구입할 때, 백업에 쓸 돈을 충분히 남겨 놓도록 해야 한다. 백업되지 않은 데이터는 쓸모 없다! 아마 누구든 데이터를 다시 만들어내는 비용이 백업 비용에 비해서 훨씬 비쌀 것이다.

수행 성능을 위해서는 파일의 수명에 따라 다른 파티션에 두는 것이 유용하다. 이렇게 하면 뉴스 파티션에 있는 수명이 짧은 파일들이 심하게 파편화 되더라도, /나 /home 파티션의 수행 성능에는 영향이 없다.