Linux Partition HOWTOKristan Koehntopp, kris@koehntopp.de$Id: LinuxdocSgml_2fPartition,v 1.1 2003/08/10 02:52:29 kss Exp kss $ 번역: 박민석, dolman@correl1.snu.ac.kr이 글은 리눅스 시스템을 위해 디스크 공간을 계획하고 설계하는 방법을 가르쳐준다. 디스크와 파티션, 스왑 공간의 크기 및 위치 결정에 있어 고려할 점들, 파일 시스템과 그 유형, 관련된 화제들에 대해서 이야기한다. 이 글의 의도는 절차가 아니라 배경 지식을 가르치는 것이다. 1. 소개1.1 이 글에 대하여.이 글은 리눅스 미니 하우투 중의 하나이다. 미니 하우투란 리눅스의 설치와 관리에 관한 자습서 형식의 짧은 글이다. 정식 하우투나 책이 되기에는 글의 길이나 다루는 주제가 너무 작기 때문에 '미니' 하우투다. 하우투는 레퍼런스가 아니므로 레퍼런스가 필요하면 매뉴얼 페이지들을 보기 바란다. 1.2 이 문서의 내용 및 관련된 하우투 문서들이 미니 하우투에서는 리눅스 시스템을 위해 디스크 공간을 계획, 설계하는 방법을 알려주고자 한다. 디스크와 파티션, 스왑 공간의 크기 및 위치 결정에서 고려할 점들, 파일 시스템과 그 유형, 관련된 화제들에 대해서 이야기한다. 이 글은 배경 지식을 가르치고자 하는 것이므로, 도구들에 대한 이야기보다는 주로 원리들에 대해 다룰 것이다. 당신이 처음 리눅스를 설치하기 전에 이 문서를 읽었으면 하지만, 대부분의 사람들에게는 어려운 일이다. 또 초심자라면 디스크 최적화 이외의 문제들도 겪게 된다. 따라서 당신은 아마 막 리눅스 설치를 마치고, 어떻게 하면 설치를 최적 화할 수 있을지 생각하고 있거나 다음에는 귀찮은 계산 착오를 피할 방법을 궁리하고 있는 사람이리라고 생각한다. 어떤 경우에도, 이 글을 다 읽고 당신이 전에 설치한 것을 싹 밀어버리고 새로 깔아야겠다는 욕구가 생겨나길 기대하는 바이다. :-) 이 미니 하우투의 대부분은 디스크 공간을 계획하고 설계하는 것에 국한되어 있으며 fdisk나 LILO, mke2fs, 각종 백업 프로그램의 사용법에 대해서는 다루고 있지 않다. 이런 문제들은 다른 하우투 문서들이 다루고 있다. 리눅스 하우투의 최신 정보가 필요하면 리눅스 하우투 목록(Index)를 보기 바란다. 목록에는 하우투 문서들을 구하는 방법도 나와있다. 파일 시스템의 여러 부분에 요구되는 크기와 속도를 알아볼 방법이 필요하면, by Gjoen Stein <gjoen@nyx.net> 의 "리눅스 다중 디스크 설계 미니 하우투"를 보기 바란다. 1024개 이상의 실린더를 가진 디스크에 대한 내용이 필요하면 Andries Brouwer <aeb@cwi.nl>의 "리눅스 대용량 디스크 미니 하우투"를 보도록 하라. 이용자 별로 사용 가능한 디스크 공간을 제한하는 방법(쿼타, quotas)에 대한 내용은 Albert M.C. Tam <bertie@scn.org>의 "리눅스 쿼타 미니 하우투"를 보라. 현재 디스크 백업에 대한 일반적인 문서는 없지만, 특정한 백업 기법에 대한 문서가 몇 가지 있다. Thomas Koenig <Thomas.Koenig@ciw.uni-karlsruhe.de>의 "리눅스 ADSM 백업 미니 하우투"는 리눅스를 IBM의 ADSM 백업 환경에서 쓰고자 할 때 보라. Christopher Neufeld <neufeld@physics.utoronto.ca>의 "MS-DOS에서의 리눅스 백업 미니 하우투"에는 MS-DOS에서의 리눅스 백업에 대한 정보가 있다. 하우투 문서를 써서 투고하는 방법에 대해서는 Greg Hankins <gregh@sunsite.unc.edu>의 리눅스 하우투 목록을 참고하라. /usr/src/linux/Documentation의 내용을 살펴보는 것도 교육적인 측면에서 큰 도움이 된다. 디스크 드라이버의 특성에 대한 정보나 파일시스템 혹은 하위 디렉터리들을 살펴보려면 ide.txt와 scsi.txt를 보라. 2. 파티션이란 무엇인가?PC의 하드디스크가 발명되고 얼마 지나지 않아, 사람들은 하나의 디스크밖에 없는 시스템에 여러 운영 체제를 설치하고 싶어하게 되었다. 이에 따라 하나의 물리적 디스크를 여러 개의 논리적 디스크로 분할하는 기술이 필요하게 되었는데, 이것이 바로 파티션이다. 대부분의 운영 체제가 하드디스크 상의 인접한 블록 섹션들을 완전히 별개의 디스크인 양 취급한다. 파티션이 겹쳐서는 안 된다는 것은 자명하다. 같은 컴퓨터에 설치된 다른 운영 체제가 구획 중복 때문에 중요한 정보를 덮어 써 버린다면, 어떤 운영 체제이건 기뻐할 리 만무하다. 인접한 파티션 사이에 빈 공간이 있어서도 안 된다. 이런 배치가 해로운 것은 아니지만, 구획 사이의 값비싼 디스크 공간을 낭비하게 되는 까닭이다. 디스크 전체를 파티션으로 분배할 필요는 없다. 디스크 끝에 지금 설치된 어떤 운영 체제에도 속하지 않은 빈 공간을 남겨두기로 할 수도 있다. 나중에 당신이 어떤 운영 체제를 가장 많이 쓰는지 분명해지면, 이 자투리 공간을 분배해서 파일 시스템을 설치하면 된다. 파티션을 옮기거나 그 크기를 바꾸면 그 안의 파일 시스템은 파괴된다.
따라서 파티션을 변경할 때에는 대개 영향을 받는 모든 파일들을 백업해서
보관하게 된다. 실제로 파티션을 변경하면 많은 것들이 뒤죽박죽이 되는
일이 보통이므로, (혹시 운이 좋다면) 특정한 파일 시스템의 파티션은 자료 손실 없이 둘로 나눌 수 있다. 예를 들어 "fips"라는 프로그램은 MS-DOS를 다시 설치하지 않고도 리눅스 설치를 위한 공간을 마련하기 위해 MS-DOS 파티션을 둘로 나눌 수 있다. 하지만 아직은 이런 일을 하기 전에 컴퓨터 안의 모든 것들을 조심해서 백업해두어야만 한다 2.1 백업이 중요하다.테이프는 가장 친근한 백업 장치이다. 테이프는 빠르고 믿을 만 하며 사용하기 편하므로 백업을 자주 쉽게 자동으로 받을 수 있다. Step on soapbox: 필자는 디스크 컨트롤러에 의해 작동되는 ftape 따위가 아니라 진짜 테이프를 이야기하고 있다. SCSI를 사는 것도 고려해 볼 만 하다. 리눅스는 SCSI를 기본적으로 지원하고 있다. 리눅스에서는 ASPI 드라이버를 띄울 필요가 없으므로, 귀중한 HMA를 잃어버릴 일이 없다. 그리고 일단 SCSI 호스트 어댑터가 설치되면 디스크나 테이프, 시디롬 등을 어댑터에 붙이기만 하면 된다. 더 이상 I/O 어드레스나 IRQ 조작이 필요 없고, 마스터/슬레이브와 PIO 레벨을 맞출 필요도 없다. 덧붙임: 적절한 SCSI 호스트 어댑터는 별다른 CPU 부담 없이 입출력 성능의 향상을 가져다준다. 디스크를 심하게 써도 괜찮은 반응 속도를 경험할 수 있다. 리눅스 시스템을 유즈넷 뉴스 서버나 ISP 사업용으로 쓸 계획이라면, SCSI 없는 시스템은 꿈도 꾸지 말라. Climb of soapbox. 2.2 장치 번호와 장치의 이름인텔에 기반한 시스템의 파티션 개수는 애초부터 제한되어 있었다. 원본 파티션 테이블이 부트 섹터의 일부로 설치되어 있고 네 개의 파티션이 들어갈 자리밖에 없다. 이 파티션들은 프라이머리 파티션이라 불린다. 시스템에 더 많은 파티션들이 필요하다는 것이 분명해 지자, 논리 파티션이 고안되었다. 논리 파티션의 개수에는 제한이 없다. 각각의 논리 파티션은 다음 논리 파티션을 가리키는 포인터를 하나씩 가지고 있다. 따라서 파티션은 꼬리에 꼬리를 물고 끝없이 이어질 수도 있다. 호환성 때문에, 논리 파티션이 차지하는 모든 공간은 프라이머리 파티션에
속해야만 한다. 논리 파티션을 쓰고 있다면, 프라이머리 파티션 하나가
"확장 파티션"으로 표시되어서 논리 파티션들이 차지하는 영역의 처음부터
끝까지 덮고 있게 된다. 이것은 모든 논리 파티션들에 할당된 공간이
연결되어 있어야만 한다는 것을 뜻한다. 확장 파티션은 하나 뿐이다.
어떤 리눅스는 드라이브 당 제한된 수의 파티션만을 다룰 수 있다. 리눅스는 4개의 프라이머리 파티션(논리 파티션을 쓰고 있다면 이 가운데 3개를 쓸 수 있다)을 가질 수 있고, 디스크 하나 당 SCSI의 경우 최대 15개, IDE라면 최대 63개의 파티션을 가질 수 있다. 리눅스에서는 디바이스 파일이 파티션을 나타낸다. 디바이스 파일은 c(버퍼 캐쉬를 쓰지 않는 "character" 디바이스)나 b(버퍼 캐쉬를 사용하는 "block" 디바이스) 형식을 갖는 파일이다. 리눅스에서는 모든 디스크가 block 디바이스로만 표시된다. 다른 유닉스 시스템들과는 달리 리눅스는 디스크와 파티션에 대해 "버퍼를 거치지 않는" character 디바이스를 제공하지 않는다. 디바이스 파일에서 중요한 것은 파일 크기 대신 표시되는 주 장치 번호(major device number)와 부 장치 번호(minor device number) 뿐이다.
디바이스 파일에 접근할 때, 주 장치 번호가 입/출력을 수행하기 위해
호출될 디바이스 드라이버를 결정한다. 이 호출은 부 장치 번호를
매개변수로 수행되며, 부 장치 번호가 해석되는 방식은 전적으로
드라이버에 달려있다. 보통 드라이버에 관한 문서에 이 부 장치 번호가
사용되는 방식이 기술되어 있다. IDE 디스크라면
관례에 따라 디바이스 파일은 특정한 이름을 가지며, 많은 시스템
프로그램들은 컴파일될 때부터 이 이름을 알고 있다. IDE 디스크는
디스크 상의 프라이머리 파티션은 1, 2, 3, 4이다. 따라서
각 파티션에는 할당된 공간의 시작 및 끝 블록 주소와 형식이 등록되어 있다. 형식이란 특정 파티션을 어떤 형식의 운영 체제에 지정하는 (1 바이트의) 수치 부호이다. 컴퓨터 참조(computing consultant) 상의 편의를 위해 파티션 형식 부호는 단일하지 않으며, 언제나 두 개의 운영 체제가 같은 형식 부호를 가질 확률이 있다. 리눅스는 형식 부호 0x82를 스왑 파티션으로, 0x83를 "고유의(native)" 파일 시스템 (대부분의 경우 ext2) 정해두고 있다. 한 때 인기 있었지만 이제는 구식이 된 Linux/Minix 파일 시스템의 파티션은 0x81 부호를 쓰며, OS/2와 윈도즈 NT의 NTFS의 파티션은 0x07의 형식 부호로 표시된다. MS-DOS는 다양한 FAT 파일 시스템의 취향에 따라 여러 가지 형식 부호를 할당한다. 0x01, 0x04, 0x06이 알려져 있다. DR-DOS는 보호된 FAT 파티션을 표시하기 위해 0X81을 사용하며, 이 경우 Linux/Minix아 충돌을 일으킨다. 하지만 Linux/Minix와 DR-DOS는 이제는 널리 사용되지 않으므로 별 문제가 아니다. 논리 파티션을 담기 위해 쓰이는 확장 파티션은 0x05의 형식을 갖는다.
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 파티션의 크기는 얼마나 되어야 할까?스왑 전용 파티션을 쓰기로 했다면, 대개의 경우 옳은 선택이다. 다음 안내를 따라 그 크기를 결정하도록 하라.
따라서 16메가의 램을 가진 상황이라면, 최소한의 설정을 위해서는 스왑이 필요 없고, 48메가 이상의 스왑은 아마 쓸모 없을 것이다. 정확히 얼마나 메모리가 필요한지는 응용 프로그램과 컴퓨터에 달려있다. (다른 무엇을 기대했나?) 3.3 스왑 공간의 위치는 어디가 좋을까?
요약: 스왑은 빠르고, 헤드를 많이 가지고 있으며, 다른 작업에 바쁘지 않은 디스크에 잡아라. 디스크를 여러 개 가지고 있다면, 스왑을 쪼개서 디스크마다 혹은 제어기(controller)마다 두도록 하라. 더 나은 방법: 램을 더 사라. 3.4 파일 시스템과 파편화에 대한 몇 가지 것들.운영 체제는 디스크 공간을 블록과 블록의 조각(fragmentation) 단위로 관리한다. Ext2 파일 시스템에서는 조각과 블록이 같은 크기이기 때문에, 이 글에서는 블록에 대해서만 이야기하도록 하겠다. 파일의 크기는 다양하다. 파일이 블록의 크기에 딱 맞는 일은 없다. 따라서 모든 파일의 마지막 블록 가운데 일부는 낭비되게 된다. 파일의 크기가 불규칙하다면 디스크에 들어 있는 모든 파일들은 각각 반 블록 정도의 낭비되는 부분을 갖게 된다. 탄넨바움 씨는 자신의 저서 "운영 체제"에서 이것을 "파편화(fragmentation)"이라고 불렀다. 파일의 개수는 대략 디스크에 있는 할당된 inode의 개수와 같다고 추정할 수 있다. 필자의 디스크에는
블록 하나의 크기가 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에서는 백업 계획과 다양한 파일 수명에 따른 외적 파편화를 줄일 것을 염두에 두고 파티션을 결정해야 한다. 파일은 수명을 갖는다. 한 파일은 만들어진 다음 시스템에 어느 시간
동안 남아 있다가 지워지게 된다. 파일의 수명은 시스템에 따라 크게
다르고, 부분적으로는 파일의 경로 명에도 의존하게 된다. 예를 들어
백업을 위해서는 하루에 백업할 양이 백업 매체 하나의 용량 이하인 쪽이 편하다. 매일 이루어지는 백업은 전체 백업일 수도 있고, 바뀐 부분만 추가해 가는 식(incremental)일 수도 있다. 따라서 (매일 전체 백업을 하기 위해서) 파티션의 크기를 한 백업 매체에 완전히 들어갈 정도로 작게 잡을 수 있다. 어떤 경우이건, 파티션 하나의 크기는 매일 바뀐 파일 전부가 백업 매체 하나에 들어갈 만한 크기여야만 한다. (추가식 백업을 택하고 백업 매체는 주 혹은 월 단위의 전체 백업 때 바꾸도록 한다. 이 경우 자동 백업은 불가능하다.) 백업 전략은 이 결정에 달려있다. 디스크 공간을 계획하고 구입할 때, 백업에 쓸 돈을 충분히 남겨 놓도록 해야 한다. 백업되지 않은 데이터는 쓸모 없다! 아마 누구든 데이터를 다시 만들어내는 비용이 백업 비용에 비해서 훨씬 비쌀 것이다. 수행 성능을 위해서는 파일의 수명에 따라 다른 파티션에 두는 것이
유용하다. 이렇게 하면 뉴스 파티션에 있는 수명이 짧은 파일들이 심하게
파편화 되더라도, 4. 한 가지 예4.1 열성적인 초보자에게 추천하는 모형위에서 이야기한 것처럼 어떤 시스템에서는 이런 모형은 업그레이드나 재설치에도 편리하다. 설정 파일들을 (혹은
5. 필자의 경우필자에게는 쓸모가 없어서 두 해 전에 포기하고 선반에 치워둔 ISA 버스 방식의 낡은 386/40 컴퓨터가 있었다. 필자는 이 컴퓨터를 X 윈도우 없는 조그만 가정용 LAN 서버로 만들 계획을 세웠다. 필자는 우선 이 386 컴퓨터에 16메가의 램을 설치했다. 그리고 가능한 한 가장 작고 값싼 EIDE 디스크(800 메가)와 이더넷 카드를 장착했다. 필자가 아직 허큘리스 용 모니터를 가지고 있었기 때문에 구식 허큘리스 카드를 달았다. 다음에는 리눅스를 설치해서 메일 라우터와 POP3 서버를 비롯해서 NFS, SMB, HTTP, LPD/LPR, NNTP 서버를 띄웠다. ISDN 카드를 달아서 이 컴퓨터는 필자의 TCP/IP 라우터 겸 방화벽 역할도 하게 되었다. 이 컴퓨터의 디스크 공간은 대부분
결국 다음과 같이 되었다.
필자는 네트웍을 통해 |
   
|
