The Linux System Administrators' Guide리눅스 시스템 관리자 가이드Lars WirzeniusJoanna Oja강창수문서 번역과 프로젝트 총괄박용주번역과 문서화 작업이상준문서 번역$Date: 2003/08/10 02:52:29 $ Copyright 1993--1998 Lars Wirzenius. 각 상표는 해당 소유업체의 자산입니다. 이 매뉴얼과 똑같은 복사본을 만들고 배포할 수 있습니다. 모든 복사본에는 이 문서의 저작권에 대해 명시해야 합니다. 그리고 이런 허가 조건에 대해서도 똑같이 명시하여야 합니다. 이 문서의 소스를 TeX이나 그 밖의 다른 포맷으로 변환하거나 인쇄하여 배포할 수 있습니다. 모든 배포본에는 이 문서의 원본을 어디서 구할 수 있는지와, 이 문서의 공식 홈 페이지가 어디인지를 명시해야 합니다. 그리고 모든 배포본은 이 문서의 복사본 배포 허가 조건을 준수해야 하며, 이 허가 조건에 대해서 똑같이 명시하여야 합니다. 이 매뉴얼의 수정본을 만들거나 배포할 수 있습니다. 모든 배포본에는 그것이 이 문서의 허가에 의해 만들어지고 배포된다는 점을 명시해야 합니다. 그리고 모든 배포본은 이 문서의 복사본 배포 허가 조건을 준수해야 하며, 이 허가 조건에 대해서 똑같이 명시하여야 합니다. 이 매뉴얼을 다른 언어로 번역하여 배포할 수 있습니다. 모든 배포본은 이 문서의 수정본 배포 허가 조건을 똑같이 준수해야 하며, 이 허가 조건에 대해서 똑같이 명시해야 합니다. 이 문서의 수정본이나 번역본, 인쇄본에 대해 저자에게 알려주시면 고맙겠습니다. 감사합니다.
이 문서의 소스와 pre-formatted version을 얻으실 수 있습니다이 문서의 소스를 비롯해 여러가지 포맷들을 Linux Documentation Project 홈 페이지 http://sunsite.unc.edu/LDP/에서 anonymous FTP를 통해 얻으실 수 있습니다. 또한 이 문서의 홈페이지 http://www.iki.fi/viu/linux/sag/에서 포스트 스크립트 형식과 TeX, .DVI 형식으로 된 문서를 얻으실 수 있습니다. 1장. 소개
이 리눅스 시스템 관리자 안내서 (Linux System Administrator's Guide)는 리눅스 시스템을 운용하는데 필요한 시스템 관리 방법을 설명하고 있다. 이 책은 최소한 리눅스 시스템의 기본적인 사용법은 알고 있으나, 시스템 관리에 대해서는 거의 아무것도 모르는 ("그게 뭐지?"라고 생각하는 것처럼) 사람들을 위한 책이다. 이 책은 리눅스를 설치하는 방법에 대해서는 설명하지 않는다. 설치하는 방법에 대해서는 "Installation and Getting Started"를 참고하기 바란다. 기타 리눅스 문서에 대해 더 많은 정보를 원하는 사람들을 위해서, 이 페이지의 맨 아래에 Linux Documentation Project에 대해 간략히 설명하였다. 컴퓨터를 사용 가능하게 하기 위해 필요한 모든 작업들이 곧 시스템 관리 작업이다. 여기에는 파일 백업하기(그리고 필요하면 복원하기), 새로운 프로그램 설치하기, 사용자에게 계정 만들어주기(그리고 더이상 필요없으면 지우기), 파일시스템이 망가지지 않게 하기 등의 작업들이 포함된다. 만일 컴퓨터를 집이라 한다면, 시스템 관리(administration)는 집을 유지보수(maintenance)하는 일과 같다고 할 수 있을 것이며, 여기에는 청소하기, 깨진 창문 고치기와 기타 여러가지 작업들을 포함하게 될 것이다. 그러나 시스템 관리하기를 유지보수하기라고는 하지 않는데, 시스템 관리를 설명하기에 이 개념은 너무 단순하기 때문이다. [1] 이 책의 구조는 많은 장들이 독립적으로 읽기 가능하도록 되어 있어서 만약 백업에 대한 정보를 원한다면 바로 백업에 대한 장을 읽을 수 있다. 이렇게 구성이 독립적으로 되어 있는 것은, 모든 것을 다 읽지 않고서도 필요한 부분만 조금씩 읽을 수 있도록 하여 참고서로 활용하기 쉽게 하기 위해서이다. 그러나 이 책은 기본적으로 안내서이므로, 특정한 경우에만 참고서로 쓰일 수 있을 것이다. 또한, 이 책은 완벽히 모든 것이 설명된 백과사전이 아니다. 시스템 관리자는 언제나 다른 많은 리눅스 문서들을 참고하여야 한다. 결국, 시스템 관리자라는 것은 특별한 권리와 의무를 지닌 한 사용자일 뿐인 것이다. 가장 중요한 참고자료는 매뉴얼 페이지로, 매뉴얼페이지는 명령에 대해 잘 모를때 도와준다. 이 책의 주된 목표는 리눅스 시스템 관리를 설명하는 것이지만, 다른 유닉스에 기반을 둔 운영체제에도 쓸모가 있도록 한다는 것이 일반 원칙이었다. 불행히도 일반적으로 유닉스의 다른 버전사이에는 많은 차이가 있기 때문에, 특히 시스템 관리에 대해 모든 차이점을 다 포함해 설명하기는 힘들다. 더구나 리눅스의 개발 특성에 비추어 보면, 심지어 리눅스조차도 모든 경우를 포함시키기 힘든 것이 사실이다. 또한, 하나의 공식적인 리눅스 배포본이 존재하지 않으므로 많은 사람들이 각기 그들 나름대로의 설정을 갖고 있기 마련이다. 비록 필자는 거의 유일하게 데비안 리눅스(Debian GNU/Linux)를 사용하고 있지만, 이 책은 어떤 하나의 리눅스 배포본을 기준으로 하진 않는다. 될 수 있는대로 배포본 간의 차이점을 지적하려 노력했으며, 여러가지 대안들을 설명하였다. 한편, 각각의 작업에 대해 단지 "쉬운 5단계"를 나열하기 보다는 그 일들이 어떻게 작동되는가를 묘사하려고 노력하였다. 사실 그런 많은 정보들이 모든 사람들에게 필요한 것은 아니므로, 그 부분들은 미리 표시가 되어 있으며 미리 설정된 시스템을 사용한다면 건너 뛸 수도 있다. 그러나 모든 부분을 다 읽는 것은 자연히 시스템에 대한 이해를 높여 줄 것이며, 리눅스를 사용하고 관리하는 일을 더욱 즐겁게 해줄 것이다. 모든 다른 리눅스 개발 작업과 마찬가지로, 이 책을 쓰는 작업도 자발적으로 이루어졌다. 이 책을 쓰는 것이 재미있을 것이라고 생각했고 또한 반드시 행해져야 하는 일이라고 생각해서 이 책을 썼다. 그러나 모든 자발적인 작업이 그렇듯이, 여기에 쏟아부을 수 있는 노력도 역시 한계가 있으며 지식과 경험에도 한계가 있을 수 밖에 없다. 사실, 진정한 고수가 보수를 받으며 몇년씩 집필해서 완성한 그런 문서들처럼 이 매뉴얼이 훌륭하다고는 말할 수 없을지 모른다. 하지만, 이것은 다만 자격지심에서 말해두는 것 뿐이다. 이 매뉴얼이 어느 정도 충분히 훌륭하다고 나는 믿는다. 이 매뉴얼에서는, 이미 자유롭게 사용 가능하도록 문서화 되어 있는 내용들은 거의 포함하지 않았다. 이것은 특히, 예를 들어 mkfs 명령의 자세한 사용법과 같은, 프로그램 특정적인 문서들에 적용되는 원칙이다. 여기서는 단지 그 프로그램들의 용도를 설명하였고 이 책의 목적에 필요한 만큼의 사용법만을 서술했다. 즉, 이 매뉴얼에서 언급한 부분은 모두 해당 문서 중의 일부분일 뿐이다. 만일 이 보다 더 많은 정보가 필요하다면, 그 해당 문서를 직접 찾아 보시기를 너그러운 독자 여러분께 부탁드린다. 나는 이 문서를 될 수 있는대로 개선시키기 위해 노력하고 있다. 그러므로 이 문서를 위한 좋은 아이디어가 있다면 아낌없이 충고해 주기 바란다. 잘못된 문법, 실제로 잘못된 내용, 다시 써야할 필요가 있는 분야에 대한 의견, 다양한 유닉스 버전들이 어떻게 작동되는지에 대한 정보 등, 이 모든 것들에 관심이 있다. http://www.iki.fi/viu/ 에서 저자에게 연락을 취할 수 있는 방법을 알려 줄 것이다. 많은 사람들이 직접 또는 간접적으로 이 책을 쓰는데 도움을 주었다. 특히 LDP를 통솔하며 이 문서 작업을 독려해 주신 Matt Welsh, 이 문서를 다시 작성하는데 있어 매우 가치있는 의견을 보내주신 Andy Oram, 이 문서를 완성할 수 있다는 본보기를 보여주신 Olaf Kirch, 또한 많은 사람들이 이런 문서를 필요로 하고 있다는 사실을 깨닫게 해주신 Yggdrasil의 Adam Richter, 그 밖의 많은 분들께 감사드린다. 또한, ext2에 대한 설명과, xia와 ext2 파일시스템 비교 내용, 그 밖에 디바이스 리스트 등 유용한 정보를 제공해 주신 Stephen Tweedie, H. Peter Anvin, Remy Card, Theodore Ts'o께 감사드린다(덕분에 이 문서를 더욱 두껍고 알차게 꾸밀수 있었다). 비록 이 내용들은 여기에 더 이상 수록되지 않게 되었지만, 이 분들께 가장 고맙게 여기며 이전 버전에서 이러한 기여에 대한 언급이 때로 부족했던 것을 죄송스럽게 생각한다. 그 외에 1993년에 많은 자료들을 제공해 주시고, 리눅스 저널에 실린 많은 시스템 관리 기사들도 보내주신 Mark Komarinski에 감사드린다. 그것들은 아주 유익하였으며 많은 영감을 주었다. 많은 분들이 매우 유익한 비평을 해주셨다. 기억력이 안 되어 모든 이름을 기억 못하지만, 일부분은 알파벳순으로 다음과 같다. : Paul Caprioli, Ales Cepek, Marie-France Declerfayt, Dave Dobson, Olaf Flebbe, Helmut Geyer, Larry Greenfield와 그의 아버지, Stephen Harris, Jyrki Havia, Jim Haynes, York Lam, Timothy Andrew Lister, Jim Lynch, Michael J. Micek, Jacob Navia, Dan Poirier, Daniel Quinlan, Jouni K Seppanen Philippe Steindl, G.B. Stotte. 그 밖에 기억을 못하는 다른 분들께는 죄송스럽게 생각한다. 1.1. The Linux Documentation Project리눅스 문서 프로젝트(LDP)는 리눅스 운영체제를 위한 완벽한 문서를 제공하기 위해 같이 일하는 작성자, 교정자, 편집자들의 자유로운 모임이다. 이 프로젝트의 전반적인 진행 상황은 Greg Hankins가 조율해 주고 있다. 이 매뉴얼은 Linux Users' Guide, System Administrators' Guide, Network Administrators' Guide, Kernel Hackers' Guide로 이루어진 LDP의 핵심 문서들 중 하나이다. 이 매뉴얼은 sunsite.unc.edu의 /pub/Linux/docs/LDP에서 anonymous FTP를 통해 LaTeX형식, .dvi형식, 포스트스크립트 형식으로 얻을수 있다. 리눅스 문서의 질을 향상시키기 위한
글 쓰기와 편집에 참여해 보기를 권한다.
의욕이 있으신 분들은 E-mail을
2장. 리눅스 시스템의 개괄
여기서는 리눅스 시스템의 전반적인 구성을 간략히 알아볼 것이다. 먼저, 운영체제의 역할들 중 핵심적인 것 몇 가지를 살펴보고, 이런 역할들을 실제로 구현해주는 프로그램들에 관해 간단히 알아보도록 하겠다. 일단은 리눅스 시스템을 포괄적으로 이해하는 것이 목적이므로, 각각의 세부적인 내용은 뒤로 미루었다. 2.1. 운영체제의 구성UNIX 계열의 운영체제는 커널(kernel)과 여러가지 시스템 프로그램(system programs) 들로 이루어져 있는데, 여기에는 업무수행을 위한 몇가지 응용 프로그램(application programs) 들도 덧붙여져 있다. 이중에서도, 특히 커널은 운영체제의 심장부라고 할 수 있는 부분이다. [2] 커널은 파일들을 디스크에 적절히 배치시키거나, 프로그램을 시동시켜 작업을 수행하게 하고, 메모리와 같은 시스템의 자원(resource)을 각각의 프로세스에 할당하며, 네트워크를 통해 패킷(packet)을 주고받을 수 있게 해준다. 그러나 커널이 모든 일들을 혼자서 처리하는 것은 아니며, 실제로 커널이 혼자서 처리하는 부분은 매우 적다. 대신에 커널은 기반 설비(tools)들을 제공함으로써 모든 작업을 가능하도록 하는데, 이 설비들을 통하지 않고서는 어떤 것도 직접 하드웨어를 다루지 못하게 한다. 이런 방식으로, 하드웨어를 동시에 사용하려는 각각의 사용자들이 서로 충돌하는 일을 막을 수 있다. 커널이 갖추고 있는 설비들을 사용하는 일은 시스템 콜(system call)을 통해서 이루어진다 : 이에 관한 상세한 내용은 해당 매뉴얼 페이지의 두번째 섹션을 참조하기 바란다. 시스템 프로그램들은 운영체제를 위해 다양한 역할을 수행해 주어야 하는데, 이를 구현하기 위해 역시 커널의 기반 설비들을 사용한다. 즉, 시스템 프로그램이나 기타 여러가지 응용 프로그램들은 모두 '커널 위에서' 실행된다고 할 수 있겠다. 이 상태를 사용자 모드(user mode)라고 부른다. 사용자 모드에서 시스템 프로그램과 기타 프로그램은 결국 그 궁극적인 역할에 차이가 있을 뿐이다 : 사용자의 업무에 필요한 역할을 하도록 되어 있는 것이 응용 프로그램이라면(놀이가 필요하다면 게임이 되겠다), 시스템 프로그램은 시스템이 동작하는데 필요한 역할을 하게 되어 있는 것이다. 그러므로 워드 프로세서는 응용 프로그램, telnet 은 시스템 프로그램이라고 할 수 있다. 사실, 이런식의 구분은 애매모호한 경우가 많은데, 강박적으로 뭐든 분류하기를 좋아하는 사람들에게나 중요한 문제일 것이다. 운영체제는 또한 컴파일러와 그에 부합되는 라이브러리를 포함하고 있는데( 리눅스의 경우에는 GCC와 C 라이브러리를 포함하고 있다.), 모든 종류의 프로그래밍 언어가 운영체제에 포함되어 있을 필요는 없다. 또한 각종 문서가 운영체제와 함께 첨부되어 있기도 하며, 어떤 경우에는 게임이 포함되어 있는 경우도 있다. 전통적으로는 설치 디스크나 테이프에 들어있는 내용이 그 운영체제의 모든 것으로 간주되었다 ; 그러나 이런 관점은 리눅스에는 어울리지 않는데, 그것은 리눅스가 FTP 사이트를 통해 전세계로 퍼져나가기 때문이다. 2.2. 커널 핵심부의 구성리눅스 커널에는 몇가지 핵심적인 부분들이 있는데 그것은 : 프로세스 관리자, 메모리 관리자, 하드웨어 장치 드라이버, 파일시스템 드라이버, 네트워크 관리자(process management, memory management, hardware device drivers, filesystem drivers, network management)이며 그 외에도 다양한 구성요소가 있다. 이 중 일부를 그림 2-1 에 나타내었다. 아마도 커널에서 가장 중요한 구성요소는 메모리관리자와 프로세스 관리자일 것이다(이것들 없이는 꼼짝도 할 수 없다!). 메모리 관리자는 프로세스, 커널 일부분, 버퍼 캐쉬를 메모리 영역과 스왑 공간에 적절히 할당하는 역할을 한다. 프로세스 관리자는 새로운 프로세스를 생성하고 멀티태스킹을 구현하는데, 멀티태스킹은 프로세서 상의 프로세스를 계속 바꿔치기(switching)하는 기법으로 이루어진다. 커널의 가장 밑바탕은 갖가지 종류의 하드웨어 장치 드라이버들로 이루어진다. 하드웨어는 그 종류가 워낙 다양해서, 하드웨어 장치 드라이버도 그 수가 무척 많다. 흔히, 비슷한 기능이면서도 소프트웨어에 의해 구동되는 방식이 다른 하드웨어가 많은데, 이런 유사성은 비슷한 기능을 통틀어 구동시키는 일반적인 드라이버 클래스를 갖출 수 있게 해준다; 즉, 같은 클래스에 속하는 멤버 드라이버들은 자신을 제외한 커널의 나머지 부분에 대해선 같은 인터페이스를 갖는다. 그러나 각각의 드라이버들이 기능을 실제로 구현하는 방법은 서로 다르다. 예로, 모든 디스크 드라이버들은 커널의 나머지 부분에 대해 비슷한 인터페이스를 갖는데, 실제로 디스크 드라이버들은 "드라이브 초기화" "N번째 섹터 읽기" "N번째 섹터 쓰기"와 같은 조작방법을 모두 갖추고 있다. 커널이 독립적으로 제공하는 소프트웨어 서비스들 중에도 유사성을 가진 것들이 있어서, 역시 클래스란 것으로 추상화 될 수 있다. 예를 들자면, 수많은 네트웍 프로토콜들은 BSD 소켓 라이브러리라는 하나의 프로그래밍 인터페이스로 추상화되어 왔다. 또 다른 예로, 가상 파일시스템 계층(virtual filesystem (VFS) layer) 이란 것이 있는데, 이것은 파일시스템 조작방법을 실제 구현방법에서 떼어내 추상화한 것이다. 파일시스템을 사용하려는 요청은 VFS에 전해지고, VFS는 요청에 알맞은 파일시스템 드라이버를 골라 준다. 각각의 파일 시스템 드라이버는 그에 해당하는 파일시스템 조작방법을 실제로 구현해 낸다. 2.3. 유닉스 시스템의 주요 기능여기서는 UNIX가 제공하는 핵심적인 기능 몇가지를 대락적으로 알아볼 것이다. 각각의 상세한 내용은 뒤에서 살펴보도록 하겠다. 2.3.1. initUNIX의 독립적인 핵심기능들은 대부분 init에 의해 제공된다. init는 모든 UNIX 시스템에서 가장 먼저 실행되는 프로세스이면서, 또한 부팅시에 커널이 수행하는 맨 마지막 과정이다. init는 시스템 시동에 필요한 갖가지 작업을 수행함으로써 부팅과정을 계속 이어나간다(파일시스템을 검사하고 마운트하기, 데몬을 시동시키기 등의 갖가지 작업을 한다). init가 수행해야할 작업의 구체적인 목록은 시스템이 어떤 상태로 부팅되기를 원하는냐에 따라 달라진다; 여기에는 몇가지 선택이 있을 수 있다. 단일 사용자 모드(single user mode) 는 아무도 로그인하지 못하게하고, root가 콘솔에서만 쉘을 사용할 수 있는 특수한 상태이다; 일반적으로는 다중 사용자 모드(multiuser mode) 가 적용된다. 이런 상태들 중에 몇가지는 실행 레벨(run revel) 이란 개념으로 일반화된다; 단일 사용자 모드와 다중 사용자 모드는 각각 하나씩의 실행 레벨로 간주된다. 또한 여기에 부가적인 실행레벨이 있을 수 있는데, 예를 들자면 콘솔 상에서 X를 구동하기 위한 또하나의 실행 레벨이 있을 수 있다. 시스템이 일반적으로 가동되는 상태에서, init는 getty(사용자가 로그인 할 수 있도록 해준다)가 제대로 동작하고 있는지 확인하며, 또한 고아 프로세스를 인수하는 역할을 맡는다(orphan processes, 부모 프로세스가 죽어버린 프로세스; UNIX 시스템에서 모든 프로세스는 하나의 트리(tree) 구조를 이루어야만 한다. 따라서, 고아가 된 프로세스는 누군가가 양자로 삼아주어야 한다). 시스템이 셧다운 될 때, 남아있는 프로세스를 모두 종료시키고 모든 파일시스템의 마운트를 해제해 주는 것도 init이다. 그 밖에, 시스템 종료시에 수행하도록 정해준 기타 작업들도 init가 처리하게 된다. 2.3.2. 터미널을 통한 로그인터미널(시리얼 라인으로 연결된)이나, 콘솔(X가 구동되지 않은)을 통한 로그인은 getty 프로그램이 처리하게 된다. 우선 init는 각각 개별적인 getty 인스턴스를 각각의 로그인 터미널에 띄워 놓는다. getty는 입력받은 username을 확인하고 login 프로그램을 돌려 password를 해독하게 한다. username과 password가 정확하면, login은 쉘을 구동시킨다. username과 password가 정확하지 않거나, 사용자가 로그아웃하여 쉘이 종료되면, init는 이 사실을 간단히 알려주고 새로운 getty 인스턴스를 시작시킨다. 커널은 로그인 과정에 전혀 관여하지 않으며, 이런 모든 과정은 시스템 프로그램들이 도맡아 처리한다. 2.3.3. Syslog커널과 여러가지 시스템 프로그램들은 각종 에러와 경고 메시지, 기타 일반적인 메시지들을 내놓는다. 이런 메시지들은 무척 유용한 정보이므로, 시간이 많이 흐른 뒤에도 다시 볼 수 있도록 꼭 파일로 기록해 두어야 한다. 이 일을 해주는 것이 바로 syslog이다. syslog는 여러 메시지들을 그 출처와 중요도에 따라 각기 다른 파일에 정리할 수 있다. 예를 들어, 커널이 출력하는 메시지는 따로 파일을 만들어 기록해 두는 일이 많은데, 이렇게 하는 이유는 커널 메시지가 워낙 중요하고, 문제점을 집어내기 위해선 자주 읽어 보아야 하기 때문이다. 2.3.4. 명령의 주기적인 실행 : cron과 at일반 사용자이거나 시스템 관리자이거나 간에, 어떤 명령을 주기적으로 반복 실행시켜야 할 필요성은 누구나 느끼게 된다. 한가지 예로, 어떤 프로그램들은 임시로 생성한 파일들을 제대로 지우지 않는데, 그래서 임시 파일용 디렉토리(/tmp,/var/tmp) 안에는 더 이상 필요하지 않은 파일들이 있을 수 있다. 이런 것들이 점점 많아지면 디스크의 공간이 낭비되므로, 시스템 관리자들은 이런 파일들을 주기적으로 지우고 싶어하기 마련이다. 이런 반복작업을 바로 cron 서비스가 해준다. 사용자는 각각의 crontab 파일을 가질 수 있는데, 여기에 각 사용자가 실행시키기 원하는 명령들과 그 시간을 적어두면 cron 데몬이 특정 시간마다 그 명령들을 실행시켜 준다. at 서비스는 cron과 비슷하지만 한가지 면에서 다르다; at도 주어진 시간에 명령을 수행해주지만 그것을 되풀이 하지는 않는다. 2.3.5. 그래픽 유저 인터페이스UNIX나 Linux의 커널은 사용자 인터페이스를 내장하고 있지 않다; 그 대신, 유저 레벨의 프로그램이 사용자 인터페이스를 구현해 주는데, 이런 점은 텍스트 모드 인터페이스와 그래픽 환경의 인터페이스 둘다 마찬가지이다. 이런 방식은 시스템을 보다 융통성있게 해준다. 그러나 각각의 프로그램들이 서로 다른 유저 인터페이스를 가지게 되고, 이에따라 시스템을 익히기가 어려워지는 점은 약간의 단점이라 할 수 있다. Linux에서 기본적으로 사용하는 그래픽 환경은 X이다(X Window System이라고도 불리운다). 그런데 X도 역시 유저 인터페이스를 내장하고 있지 않기는 마찬가지이다; 다만 그래픽 유저 인터페이스를 구현하기 위한 기반 설비들, 즉 윈도우 시스템 그 자체만을 제공한다. X 위에서 구현되는 유저 인터페이스에는 여러가지 스타일이 있는데, 그 중에 가장 많이 쓰이는 것으로는 아데나, 모티프, 오픈룩 스타일을 꼽을 수 있다.(Athena, Motif, and Open Look) 2.3.6. 네트워킹네트워킹이란 둘 이상의 컴퓨터를 연결하여 서로 커뮤니케이션 할 수 있도록 해주는 것을 말한다. 실제로 연결과 커뮤니케이션이 이루어지는 방법은 상당히 복잡한 감이 있지만, 이를 통해 얻을 수 있는 이득은 실로 막대한 것이다. UNIX 운영체제는 다양한 네트워킹 지원을 갖추고 있다. 가장 기본적인 서비스들 -- 파일시스템, 프린팅, 백업 등등 -- 은 모두가 네트워크 상에서도 이루어질 수 있다. 이를 통해, 저비용과 결함허용 같은, 마이크로컴퓨팅과 분산컴퓨팅의 잇점들을 모두 살리면서도 시스템을 중앙집중식으로 보다 쉽게 관리하는 것이 가능해진다. 아쉽게도 여기서는 네트워킹에 관해 깊이있게 다루지 않는다; 네트워크가 기본적으로 어떻게 움직이는지를 포함해서 더 깊이있는 내용을 알고 싶은 사람은 Linux Network Administrators' Guide를 읽어보기 바란다. 2.3.7. 네트워크를 통한 로그인네트워크를 통한 로그인은 일반적인 로그인과는 좀 다르다. 일반적인 로그인의 경우에는 로그인 가능한 각각의 터미널을 잇는 개별적인 시리얼 라인이 일정하게 존재하고 있다. 반면에, 네트워크를 통해 로그인하는 경우에는 네트워크를 통한 가상의 연결이 이루어질 뿐이며 그 연결도 일정하지 않다. [3] 따라서 각각의 가상연결마다 미리 getty를 띄워놓고 기다린다는 것은 불가능하다. 네트워크로 로그인하기 위해서는 몇가지 다른 방법이 필요한데, TCP/IP 네트워크에서는 telnet과 rlogin을 주로 사용한다. 네트워크 로그인에서는 getty들을 대신해서 각각의 로그인 방법마다 데몬 하나씩을 독립적으로 띄워 놓고(즉, telnet과 rlogin은 서로 다른 데몬이 필요하다) 로그인 요청이 있는지를 잘 듣고 있도록 한다. 로그인 요청 하나가 들어오면, 데몬은 자기자신의 새로운 인스턴스 하나를 실행시켜 그에 응하게 한다; 그리고 원래의 인스턴스는 다른 요청이 있는지 다시 귀 기울이고 있게 된다. 새로운 인스턴스가 하는 일은 getty와 비슷하다. 2.3.8. 네트워크 파일 시스템네트워크를 통해 얻을 수 있는 커다란 이점 중 하나는 네트워크 파일 시스템(network file system)을 통해 파일을 공유할 수 있다는 점이다. 이것은 Network File System 또는 NFS라고 불리며, Sun사에 의해 개발되었다. 네트워크 파일 시스템을 통하면, 한 컴퓨터에서 프로그램이 어떠한 파일 조작을 하더라도 그것을 네트워크 건너편의 다른 컴퓨터로 보낼 수 있다. 이것은 다른 컴퓨터에 있는 파일들이 마치 자신의 컴퓨터에 있기라도 한 것처럼 프로그램을 착각하게 만든다. 이렇게 하면 프로그램들을 특별히 수정하지 않아도 되므로, 정보의 공유를 아주 손쉽게 할 수 있다. 2.3.9. 전자 우편전자 우편은 컴퓨터를 통한 커뮤니케이션에서 가장 중요한 위치를 차지하고 있다. 편지는 특별한 형식의 파일에 저장되며, 편지를 읽고 보내기 위해서는 특정한 메일 프로그램을 사용하여야 한다. 각 사용자는 새로 온 편지가 보관되는 편지함( incoming mailbox, 특정 형식의 파일이다)을 갖고 있게 된다. 누군가 편지를 보내면, 메일 프로그램은 받는 이의 편지함이 어디 있는지 확인하고 그 파일의 뒤에 편지 내용을 덧붙여 놓는다. 만일 누군가가 다른 컴퓨터에 있는 사용자에게 편지를 보낸다면, 메일 프로그램은 편지를 배달하기에 적당한 위치에 있는 다른 컴퓨터를 찾아서 그 편지를 넘겨준다. 이러한 전자 우편 시스템은 많은 프로그램들로 이루어진다. 편지를 배달해 주는 일은 하나의 프로그램이 도맡아 처리하는데, 이런 프로그램을 mail transfer agent 또는 MTA라고 하며 sendmail이나 smail 같은 것이 있다. 반면에 사용자들은 편지를 읽고 쓰기 위해 각자 다양한 프로그램을 사용하기 마련이다. 이런 프로그램을 mail user agent 또는 MUA라고 하며, pine이나 elm이 대표적이지만 그 종류가 무척이나 다양하다. 보통 편지함은 /var/spool/mail에 위치하는 것이 일반적이다. 2.3.10. 인쇄프린터는 한번에 한사람만이 쓸 수 있다. 하지만 프린터를 한사람만 계속 사용한다면 그것은 아주 비경제적인 일일 것이다. 그래서, 프린터는 프린트 큐(print queue)라는 것을 구현해 주는 소프트웨어를 통해 서로 공유할 수 있도록 되어있다: 모든 프린트 작업은 큐로 보내지며 그곳에서 차곡차곡 쌓여있다가 자기 차례가 오면 자동으로 인쇄된다. 이렇게 하면 사용자들이 인쇄작업의 순서에 신경쓰지 않아도 되고, 또한 프린터를 서로 장악하기 위해 싸울 필요도 없어진다. [4] 실제로 프린트 큐 소프트웨어는 프린트 작업을 디스크에 쌓아두는(spool) 일을 한다. 즉, 프린트 작업들은 실제로 출력되기 전까지 파일의 형태로 큐에서 대기하게 된다. 이런 방식은 응용 프로그램들이 인쇄물을 빨리 프린터 큐로 내보내 버리고 다른 일을 할 수 있도록 해준다; 즉, 응용프로그램은 자신의 인쇄물이 프린터에서 실제로 출력될 때까지 기다릴 필요가 없게 된다. 따라서 하나의 문서를 작성한 뒤 그것이 인쇄될 때까지 기다리지 않고도 즉시 다른 문서를 작성할 수 있으므로 무척이나 편리하다. 2.3.11. 파일시스템의 얼개파일시스템은 많은 부분으로 나누어 질 수 있다; 보통은 /bin, /lib, /etc, /dev를 포함하는 루트(root) 파일시스템과 /usr, /var, /home 같은 몇가지 다른 파일시스템으로 나누게 된다. /usr 파일시스템에는 일반 프로그램들과 내용이 변화하지 않는 데이터들이 위치하게 되고, /var 파일시스템에는 내용이 계속 변화하는 데이터(log 파일 같은 것)들이 위치하게 된다. 또한 /home 파일시스템은 모든 사용자들의 개인 파일을 위한 공간이다. 이런 분할은 하드웨어의 사정과 시스템 관리자의 결정에 따라 얼마든지 바뀔 수 있으며, 심지어 모든 것을 하나의 파일시스템에 몰아 넣을 수도 있다. 파일시스템의 얼개에 대해서는 다음에 이어지는 3장 부분에서 좀 더 상세한 내용을 다룬다; 또한 Linux Filesystem Standard 문서를 읽어본다면 더욱 더 상세한 내용을 접할 수 있을 것이다. 3장. 디렉토리 트리의 개괄
디렉토리는 마치 나뭇가지와도 같은 계층구조를 이루고 있는데, 이를 가리켜 트리(tree) 구조라고 한다. 이번 장에서는 표준 리눅스 디렉토리 트리 구조의 주요 부분을 FSSTND 파일시스템 표준에 근거하여 살펴 볼 것이다. 또한 여기서는 여러가지 목적에 알맞게 디렉토리 구조를 분할하는 일반적인 방법에 대해 개괄적으로 알아 볼 것이며 이렇게 디렉토리를 특별히 분할하는 취지에 관해서 설명할 것이다. 그리고 디렉토리 분할 방법의 몇가지 다른 대안에 대해서도 알아보기로 하겠다. 3.1. 배경여기서 다룰 내용은 대체로 리눅스 파일시스템 표준안(Linux filesystem standard, FSSTND, version 1.2 - 참고문헌을 볼 것)에 기반하고 있다. 이 표준안은 리눅스에서 파일시스템을 어떻게 조직할 것인가에 대한 표준을 제정하기 위해 만들어진 문서로서, 이런 표준에 따라 각 파일들의 위치가 일관되게 유지된다면 리눅스용 프로그램의 작성,포팅이 쉬워지고 또한 리눅스 머신을 관리하기도 쉬워지는 등 많은 잇점을 지니게 된다. 사실 이런 표준안이 어떤 강제력을 지니고 있는 것은 아니지만 거의 대부분의 리눅스 배포판에서 이를 따르고 있으며, 특별한 이유없이 이 표준을 어기는 것은 별로 바람직한 일이 못된다. FSSTND는 전통적인 유닉스 방식과 최신 경향을 함께 반영하려 노력하고 있으며, 이를 통해 다른 유닉스 경험자들이 리눅스에 보다 친숙함을 느낄 수 있도록 배려하고 있다. 물론 리눅스 경험자가 다른 유닉스를 접하는 경우에도 마찬가지이겠다. 이번 장에서는 FSSTND에 대해 상세하게 다루지는 않는다. 리눅스 시스템 관리자라면 좀 더 깊이있는 이해를 위해 FSSTND를 꼭 읽어보기 바란다. 또한 여기서는 모든 파일들에 대해 일일이 다루지 않으며 파일시스템의 관점에서 시스템의 구조를 이해하는데 치중할 것이다. 각각의 파일에 대한 정보는 이 문서의 다른 곳을 찾아보거나 매뉴얼 페이지(man page)를 참고하기 바란다. 전체 디렉토리 트리는 분할이 가능하도록 되어 있다. 분할된 각 부분들은 서로 다른 디스크나 파티션에 들어가게 되는데, 이렇게 하면 디스크 공간의 제약에서 벗어날 수 있고 백업하기도 수월해지며 그 밖에 다른 시스템 관리 작업도 한결 손쉬워진다. 파일시스템의 주요 부분을 꼽아보자면 루트(root) 파일시스템, /usr 파일시스템, /var 파일시스템 그리고 /home 파일시스템을 들 수 있으며(그림 3-1을 보세요), 각 부분들은 서로 다른 의도를 가지고 만들어진 것이다. 이런 디렉토리 트리는, CD-ROM 같은 읽기 전용 장치나 NFS를 통해 파일시스템의 일부를 공유하고 있는 리눅스 머신들의 네트워크에 알맞도록 설계되어져 왔다. 아래에 디렉토리 트리 각 부분의 역할에 대하여 설명하였다.
위에서 각 부분들이 서로 다른 파일시스템인 것으로 가정했지만, 사실 꼭 그렇게 해야만 하는 것은 아니다. 만일 단일 사용자용 시스템이거나 관리를 단순하게 하고 싶은 경우라면 모든 것을 하나의 파일시스템에 몰아 넣는 것도 가능하다. 또한 위에서 제시한 방법 이외에도, 여러가지 상황에 따라 얼마든지 다른 형태로 파일시스템을 구성할 수 있다. 중요한 것은, /usr나 /var 같은 표준적인 이름들을 사용할 수 있도록 해야 한다는 것이다; 즉, 만일에 /var가 /usr 파일시스템의 아래에 존재한다고 하더라도 /usr/lib/libc.a 또는 /var/log/messages 같은 경로들을 사용할 수 있어야만 한다. 이런 경우에는 /var를 /usr/var의 심볼릭 링크로 만들어 둠으로써 표준을 지키도록 할 수 있다. 유닉스 파일시스템 구조에서, 같은 목적의 파일들은 같은 장소에 보관된다. 즉 모든 명령들과, 모든 데이터들, 모든 문서들은 각기 독립적인 장소에 따로 보관된다. 그런데 같은 목적의 파일들을 구분하는데는 좀 다른 원칙이 적용될 수도 있다. 즉 모든 Emacs용 파일들과 모든 TeX용 파일들을 구분해서 각각 다른 곳에 모아두는 식이다. 하지만 두번째 방식을 채택한다면 파일을 공유하기가 어려워질 뿐더러(각각의 프로그램 디렉토리는 공유가능한 파일들과 그렇지 않은 파일들을 함께 가지고 있을 것이기 때문이다) 원하는 파일을 찾아내는 일도 쉽지 않게 되는 단점이 있다(만일 매뉴얼 페이지들이 엄청나게 다양한 장소에 흩어져 있다면, 매뉴얼 페이지 검색 프로그램을 만드는 일은 아마 끝없는 악몽으로 여겨질 것이다). 3.2. 루트 파일시스템루트 파일시스템은 보통 크기를 작게 만든다. 왜냐면 루트 파일시스템은 아주 중요한 파일들을 담고 있는데, 크기가 작고 자주 갱신되지 않는 파일시스템일 수록 손상될 위험은 줄어들기 때문이다. 만일 루트 파일시스템이 손상된다면 특별한 방법(한 예로, 플로피로 부팅하는 방법)을 쓰지 않는 이상 부팅은 불가능해진다. 이런 일은 꼭 피해야만 될 일이다. 루트 디렉토리( / 디렉토리 )에는 /vmlinuz라고 불리는 부트 이미지 파일만 넣어두는 것이 일반적이지만, 부트 이미지마저도 /boot라는 디렉토리 안에 넣어두고 루트 디렉토리에는 파일을 두지 않는 경우도 많다. 그 밖의 다른 파일들은 모두 루트 파일시스템의 하위 디렉토리 안에 존재한다.
3.3. /etc 디렉토리/etc 디렉토리는 많은 파일들을 포함하고 있는데, 그 중 몇가지를 아래에 설명하였다. 여기에 설명되지 않은 파일들에 대해서 알아보고자 한다면, 우선 그 파일이 어느 프로그램에 속한 것인지를 파악한 후 그 프로그램의 매뉴얼 페이지를 살펴보기 바란다. 또한 이곳에는 많은 네트워킹 설정 파일들이 있는데 이런 파일들에 대한 자세한 내용은 Networking Administrators' Guide를 참고하기 바란다.
3.4. /dev 디렉토리/dev 디렉토리는 모든 하드웨어 장치에 대한 장치 파일들을 가지고 있다. 장치 파일들의 이름은 특별한 명명법을 가지고 있다; 이 명명법은 Linux device list 문서에 설명되어 있다. (장치 파일들은 설치시에 생성되며, 설치 후에는 /dev/MAKEDEV 스크립트에 의해 생성될 수 있다.) /dev/MAKEDEV.local은 시스템 관리자가 작성하는 스크립트로서 특정한 로컬 장치 파일들을 생성하거나 링크를 만드는 데 쓰인다(즉 표준 MAKEDEV 파일에 그 내용이 없는 몇몇 비 표준적인 장치 드라이버들을 위한 스크립트이다). 3.5. /usr 파일시스템/usr 파일시스템은 쉽게 커지는데, 모든 프로그램들이 이 곳에 설치되기 때문이다. 보통 /usr 디렉토리에는 배포판에서 제공하는 파일들이 들어 있으며, 그 밖에 따로 설치되는 프로그램들과 내부적 용도의 프로그램들은 /usr/local에 들어가는 것이 일반적이다. 이렇게 하면, 배포판을 업그레이드 하거나 아예 새로운 배포판으로 바꾼다고 해도 전체 프로그램을 다시 설치할 필요가 없게 된다. /usr의 몇몇 하위 디렉토리들을 아래에 설명하였다(몇가지 중요하지 않은 디렉토리들은 설명하지 않았다; 이들에 대한 자세한 내용은 FSSTND를 참고하기 바란다).
3.6. /var 파일시스템/var 파일시스템에는 시스템 운용 중 계속 갱신되는 데이터들이 모여 있다. 이 데이터들은 각 시스템에 고유한 것으로서, 네트워크를 통해 공유될 수 있는 성질의 것이 아니다.
3.7. /proc 파일시스템/proc 파일시스템은 실제로 존재하지 않는 일종의 환영이다. 이 파일시스템은 커널이 메모리 상에 만들어 놓은 것으로 디스크에는 존재하지 않는다. /proc은 시스템의 갖가지 정보를 제공해 주는데, 원래는 주로 프로세스에 대한 정보를 제공했기 때문에 proc(process)이란 이름을 갖게 되었다. 이 곳에 있는 중요한 파일과 디렉토리들을 아래에 설명하였다. /proc 파일시스템에 관한 더욱 자세한 정보는 /proc 매뉴얼 페이지를 찾아보기 바란다.
위에 나열한 파일들 대부분이 알아보기 쉬운 텍스트 파일로 되어 있긴 하지만, 어떤 경우에는 쉽게 알아보기 힘든 형식을 가지고 있기도 하다. 그래서 이런 파일들을 좀 더 쉽게 알아볼 수 있도록 해주는 많은 명령들이 준비되어 있다. 예를 들어 /proc/meminfo 파일은 메모리 사용량을 byte 단위로 나타내고 있는데, free 명령은 이것을 kilobyte 단위로 좀 더 알기 쉽게 나타내 준다(그리고 그 외에 몇가지 유용한 정보를 덧붙여 보여준다). 4장. 디스크 및 다른 저장장치 사용하기
리눅스시스템을 설치하거나 업그레이드할 때에는 디스크에 많은 작업을 해야할 필요가 있다. 디스크에 파일을 저장하기 위해 디스크에 파일시스템을 만들어야 하고 시스템의 여러 부분들을 위해 공간을 확보해야 한다. 이 장은 이러한 모든 초기작업에 대해 설명한다. 보통 일단 시스템을 구성하고 나면 플로피를 사용하는 것을 빼고는 다시 그러한 작업을 안해도 될 것이다. 만약 새 디스크를 추가하거나 디스크를 잘 조절하여 사용하고 싶다면 이 장을 다시 읽을 필요가 있을 것이다.
디스크를 관리하는 기본적인 일들은 다음과 같다.
5장에서는 가상메모리와 디스크캐싱에 대한 정보를 포함하고 있는데 디스크를 사용할 때 알아둘 필요가 있다. 이 장은 하드디스크, 플로피, 시디롬, 테이프를 설명한다. 4.1. 두 종류의 장치유닉스 그리고 리눅스는 두종류의 다른 장치를 인식한다. 랜덤-억세스 블럭 디바이스(random-access block devices)(디스크같은)와 캐릭터 디바이스(character devices)(테이프나 시리얼라인같은)로 장치들의 일부분은 시리얼(serial)이고 일부분은 랜덤-억세스이다. 각 지원되는 장치들은 파일시스템에서 장치파일(device file)로 표시된다. 장치파일을 읽거나 장치파일에 쓰면 데이타는 그것이 가리키는 장치로 왔다갔다한다. 이러한 방법으로 특별한 프로그램(그리고 인터럽트를 잡는다던가 시리얼포트를 폴링한다던지의 특별한 프로그래밍 방법론도)은 장치에 접근하는데 필요치 않다. 예를 들면 프린터에 파일을 보낼 때 다음과 같이 하면 된다.
장치들이 파일시스템에서 파일로(/dev 디렉토리안에서) 보여지므로 ls나 다른 적당한 명령으로 장치파일이 있는지 단지 보는것은 쉽다. ls -l의 결과에서 첫째 열은 파일의 퍼미션과 유형을 포함한다. 예를 들어, 시스템에서 시리얼 장치를 조사해보면,
장치자체는 설치되어 있지 않더라도 보통 모든 장치파일은 존재한다는 것을 유의해야 한다. 그래서 단지 /dev/sda가 있다고 SCSI하드디스크가 있는건 아니다. 모든 장치 파일을 가지고 있는 것은 설치프로그램을 쉽게 만들고 새로운 하드웨어를 설치하는 것을 쉽게 한다.( 정확한 파라미터를 찾을 필요도 새로운 장치를 위한 장치파일을 만들 필요도 없다.) 4.2. 하드 디스크이 절에서는 하드디스크와 관련된 용어를 소개한다. 만약 용어나 개념을 이미 알고 있다면 이 절은 넘어갈 수 있다. 그림 4-1은 하드디스크안의 중요부분의 개략도이다.하드디스크는 하나 이상의 둥그런 플래터(platter)로 구성되고, 플래터의 한면이나 양면은 데이타를 저장하기 위해 자기물질로 덮여있다. [5] 각 표면(surface)마다 기록된 데이타를 조사하거나 바꾸는 읽기-쓰기 헤드(read-write head) 가 있다. 플래터는 축을 중심으로 회전하는데, 높은 수행능력을 가진 하드디스크는 더 빠른 속도로 돌지만 대표적인 속도는 분당 3600회전이다. 헤드는 플래터의 반지름을 따라 움직이고, 플래터의 회전과 혼합되어 헤드는 표면의 모든부분에 접근할수 있다. CPU와 디스크는 디스크제어기(disk controller) 를 통해 통신한다. 다른 형식의 디스크에 달린 제어기라도 컴퓨터의 다른부분과의 인터페이스는 같기 때문에 디스크제어기를 통해 통신함으로써 컴퓨터의 나머지 부분은 드라이브를 어떻게 사용하는지 몰라도 된다. 그래서, 컴퓨터는 헤드를 적당한 위치로 옮기고 정확한 위치가 헤드 밑으로 올 때까지 기다리며, 필요한 다른 모든 즐겁지 않은 일을 길고 복잡한 전기신호들로 보내는 대신 단지 "야! 디스크, 내가 원하는 것 내봐."라고 하면 된다.(실상, 제어기에 있는 인터페이스는 여전히 복잡하나, 없는것보다는 낫다.) 또 제어기는 캐싱이나 자동으로 배드섹터를 교체하는 일도 한다. 위에 적은것이 보통 하드웨어에 대해 이해할 필요가 있는 모든 것이다. 플래터를 돌리고 헤드를 움직이는 모터, 기계적인 부분의 움직임을 제어하는 전자공학같은 많은 다른 요소들이 있지만 하드디스크의 작동원리를 이해하는데는 대부분 적절하지 않다. 표면은 보통 트랙(track) 중심이 같은 원으로 나뉘어지고 트랙은 차례로 섹터(sector)로 나뉘어진다. 이 구분은 하드디스크상의 위치를 나타내고 파일에 디스크공간을 할당하기 위해 사용된다. 하드디스크에서 정해진 위치를 찾기 위해 "표면 3, 트랙 5, 섹터 7"라고 말할 것이다. 보통 섹터수가 모든 트랙마다 같지만, 어떤 하드디스크는 바깥쪽 트랙에 좀더 많은 섹터를 만든다.(모든 섹터는 크기가 같아서 더 길이가 긴 바깥쪽 트랙에서는 더 많은 섹터수가 들어맞는다.) 일반적으로, 한 섹터는 512바이트의 정보를 지닐 것이다. 디스크 자체는 한섹터보다 더 작은 양의 데이타를 처리할 수 없다. 각 표면은 같은 방법으로 트랙(과 섹터)로 나뉘어진다. 이건 한 표면를 맡는 헤드가 한 트랙 위에 있으면 다른 표면을 맡는 헤드들도 상응하는 트랙 위에 있다는 것을 의미한다. 모든 상응하는 트랙들을 묶어서 실린더(cylinder) 라 한다. 한 트랙(실린더)에서 다른 트랙(실린더)로 움직이는 것은 시간이 걸리므로, 때로 같이 호출되는 데이타들(즉, 하나의 파일)을 한 실린더안에 있게 하면 그 모든 데이타들을 읽기 위해 헤드를 움직일 필요가 없어진다. 이것은 성능을 향상시킨다. 이런 식으로 파일을 놓는 것은 항상 가능한 것은 아니다. 디스크 상의 여러곳에 저장된 파일들은 프레그멘트(fragmented : 조각난, 산산히 부서진)되었다고 한다. 표면(혹은 헤드,숫자는 같다), 실린더, 섹터의 수는 매우 다양하다. 각 숫자의 명세 사항을 하드디스크의 결합구조(geometry)라 한다. 이들은 CMOS램(CMOS RAM)이라 불리우는 특별하고 건전지로 동력이 공급되는 기억장치에 저장되는데, 운영체제는 CMOS램으로부터 부팅시나 드라이버 초기화 때 결합구조를 불러올 수 있다. 불행히도, 바이오스(BIOS) [6] 는 설계의 한계를 지니고 있는데, CMOS램 안에 1024보다 큰 트랙 수를 명시하지 못한다는 것으로, 1024는 큰 하드디스크엔 넘 작다. 이걸 극복하기 위해, 디스크제어기는 결합구조에 대해 속이고, 컴퓨터가 준 어드레스(address)를 현실에 맞는 것으로 변환시킨다. 예를 들면, 하드디스크가 8헤드, 2048트랙, 트랙당 35섹터를 가지고 있다고 하자. [7] 이 하드의 제어기는 컴퓨터에게 거짓말을 하고 하드가 트랙의 한계를 넘어서지 않는 16헤드와 1024트랙, 트랙당 35섹트를 가지고 있다고 선언하고, 컴퓨터가 준 어드레스를 헤드수는 절반으로 트랙수는 2배로 해서 변환시킬 수 있을 것이다. 현실에서는 계산이 더 복잡할 수 있는데, 숫자들이 이렇게 간단하진 않기 때문이다 (다시말하지만, 자세한 것은 원리를 이해하는데는 적합하지 않다). 이 변환은 디스크가 어떻게 구성되는지를 운영체제에게 왜곡시켜 보여줘서, 성능을 올리기 위해 모든 데이타를 한 실린더안에 넣는 것을 비현실적으로 만든다. 변환은 오로지 IDE디스크의 문제이다. SCSI디스크는 순차적인 섹터번호(즉, 제어기는 순차적인 섹터번호를 헤드,실린더와 섹터 세가지로 변환시킨다)와 시피유가 제어기와 통신하기 위해 완전히 다른 방법을 사용하므로 SCSI디스크는 위 문제와 상관이 없다. 그러나, 컴퓨터는 역시 SCSI디스크의 실제 결합구조를 알지 못한다는 점을 유의해라. 리눅스는 때로 실제 디스크 결합구조를 모를 것이기 때문에, 리눅스의 파일시스템은 파일들을 한 실린더 안에 저장하려고 하지 않는다. 대신, 순차적으로 번호가 매겨진 섹터들을 파일에 할당하려고 하고, 이건 거의 항상 비슷한 성능을 줄 것이다. 이 문제는 제어기에 달린 캐쉬와 제어기가 하는 자동적인 미리 불러오기에 의해 더 복잡해진다. 각 하드 디스크는 구별되는 장치파일로 나타내어진다. 보통 단지 2개 혹은 4개의 IDE 하드디스크가 있다. 각각 /dev/hda, /dev/hdb, /dev/hdc, /dev/hdd가 된다. SCSI하드디스크는 /dev/sda, /dev/sdb 이런 식으로 된다. 다른 하드디스크 형식에도 비슷하게 이름을 만드는 관례가 있다. 하드디스크를 위한 장치파일은 파티션(다음에 이야기 할 것이다)에 상관없이 전체 디스크에 접근하며, 주의하지 않는다면 전체 디스크안에 있는 파티션이나 데이타가 망가질 것이다. 디스크 장치파일은 보통 오로지 master boot record(역시 다음에 이야기할 것이다)에 접근하기 위해 사용된다. 4.3. 플로피플로피디스크는 하드디스크처럼 자기 물질로 한면 혹은 양면이 둘러싸인 유연한 막으로 구성된다. 플로피디스크 자체는 읽기-쓰기 헤드가 없고, 드라이브에 포함된다. 하나의 플로피는 하드디스크의 한 플래터에 해당하나, 하드디스크는 나눌 수 없는 반면, 플로피는 제거가 가능하고 한 드라이브는 다른 플로피를 사용할 때 사용될 수 있다. 하드디스크처럼, 플로피는 트랙과 섹터로 구분되나(그리고 양면 2개의 대응하는 트랙은 실린더를 이룬다), 하드디스크에 있는 것보단 매우 적다. 플로피드라이브는 몇가지 다른 디스크형식을 사용할 수 있다. 예를 들면 3.5인치드라이브는 720kB 와 1.44MB디스크를 모두 사용할 수 있다. 플로피드라이브는 약간 다르게 작동되어야 하고 운영체제는 디스크의 용량이 얼마나 큰지 반드시 알아야 하므로, 플로피드라이브를 위해 드라이브와 디스크형식의 조합에 하나씩 많은 장치파일이 있다. 그래서, /dev/fd0H1440는 3.5인치, 크기 1440kB(1440)의 고밀도(H)디스크,즉 평범한 3.5인치 HD 플로피를 사용하고, 반드시 3.5인치 드라이브이어야 하는 첫째 플로피드라이브(fd0)이다. 그러나, 플로피드라이브를 위한 이름이 복잡해서, 리눅스에는 드라이브안에 있는 디스크의 형식을 자동으로 알아내는 특별한 플로피장치 형식이 있다. 그건 알맞은 형식을 찾을 때까지 다른 플로피형식을 사용해 새로 집어넣은 디스크의 첫 섹터를 읽는다. 자연히 이건 먼저 플로피를 포맷시키는 것을 요구한다. 자동장치들을 /dev/fd0,/dev/fd1과 같이 부른다. 자동장치가 디스크에 접근하기 위해 사용하는 변수들은 setfdprm을 이용해서 조절할 수도 있다. 만약 디스크 크기가 아닌, 예를 들면, 섹터수가 보통이 아닌, 디스크를 사용할 필요가 있을 때나, 어떤 이유로 자동감지가 실패하고, 알맞은 장치파일이 사라졌다면 사용될 수 있다. 리눅스는 모든 표준 외에도 많은 표준이 아닌 플로피 디스크도 다룰 수 있다. 비표준 중 일부는 특별한 포맷 프로그램을 요구할 것이다. 지금은 이러한 디스크 형식을 다루지 않겠지만, 중간에 당신이 /etc/fdprm 파일을 조사할 수 있다. 그 파일은 setfdprm이 인지하는 설정들을 열거하고 있다. 운영체제는 플로피드라이브 안의 디스크가 바뀌었을 때, 예를 들면, 전 디스크로 부터 캐쉬된 데이타를 사용되는 것을 피하기 위해서 알아야 한다. 불행히도 이걸 위해 사용되는 신호선이 때때로 끊어지거나, 더 나쁘게도, MS-DOS에서 드라이브를 사용할 때는 항상 인지가능하지는 않을 것이다. 만약 플로피를 사용하면서 이상한 문제를 경험한다면, 방금 말한 것이 이유가 될 수도 있다. 그걸 정정하는 유일한 방법은 플로피드라이브를 수리하는 것이다. 4.4. CD-ROM시디롬 드라이브는 광학적으로 읽히는 플라스틱 코팅된 디스크를 사용한다. 정보는 디스크표면 [8] 위에 있는, 중심으로부터 바깥으로 나가는 나선형을 따라 정렬된 조그마한 구멍에 기록된다. 드라이브는 디스크를 읽기 위해 나선형을 따라 레이저빔을 쏜다. 레이저가 구멍에 부딪혔을 때, 레이저는 같은 방향으로 반사되고, 부드러운 표면에 부딪히면, 다른 방향으로 반사된다. 이건 비트, 곧 정보를 코드화하는 것을 쉽게 만든다. 다른 부분은 단지 기계적인 부분으로 쉽다. 시디롬 드라이브는 하드디스크와 비교해서 느리다. 전형적인 하드디스크는 평균적인 탐색시간이 15밀리초 미만일 것이나, 빠른 시디롬 드라이브는 찾는데 영점 몇초 정도 걸릴 것이다. 실제 데이타 전송 비율은 초당 수백 킬로바이트 정도로 꽤 높다. 느리기 때문에, 사용가능하지만 시디롬드라이브를 하드디스크대신 사용하는 건 즐겁지 않다(어떤 리눅스 배포본은 하드디스크에 파일을 복사할 필요없게 해서, 인스톨을 쉽게 그리고 하드디스크 공간을 많이 절약하기 위해 시디롬에 '라이브(live)' 파일시스템을 제공한다.) 프로그램 설치할 때는 최고 속도가 필수적인 것이 아니므로, 새로운 소프트웨어를 설치하기 위해 시디롬을 사용하는 것은 매우 좋다. 시디롬에 데이타를 배열하는 방법은 여러가지가 있다. 가장 대중적인 것은 국제 표준 ISO 9660에 명시되어 있다. ISO 9660은 아주 작은 파일시스템을 명시하고 있는데, MS-DOS가 사용하는 파일시스템보다 훨씬 조잡하다. 반면에 매우 작아서 모든 운영체제들이 자기 고유의 시스템에 ISO 9660을 대응시키는 것이 가능할 것이다. 평범한 유닉스 사용에 ISO 9660 파일시스템은 사용할 수 없어서, 록 릿지 확장(Rock Ridge extension)이라 부르는 표준을 확장한 것이 개발되었다. 록 릿지는 시디롬이 다소간 현재의 유닉스 파일 시스템과 비슷하도록, 긴 파일명, 심볼릭링크와 그외 다른 많은 매력있는 것들을 가능하도록 한다. 훨씬 좋은건, 록 릿지 파일시스템이 여전히 유닉스가 아닌 운영체제에서도 사용가능한 정확한 ISO 9660파일시스템이라는 것이다. 리눅스는 ISO 9660과 록 릿지확장 모두를 지원한다. 록 릿지 확장은 자동적으로 인지되서 사용되어진다. 그러나, 문제는 파일시스템에만 그치는 것이 아니다. 대부분의 시디롬은 접근하기 위해 특별한 프로그램을 요구하는 데이타를 포함하고 있고, 그 프로그램들의 대부분은 리눅스에서 는 돌아가지 않는다(리눅스 MS-DOS 에뮬레이터인 dosemu로 가능한 것은 제외한다). 시디롬 드라이브는 대응되는 장치파일을 통해 접근할 수 있다. 시디롬 드라이브를 컴퓨터에 연결하는 방법은 몇가지가 있다. SCSI를 통해, 사운드카드를 통해, 그리고 EIDE를 통해서이다. 연결하기 위해 하드웨어에 대해 자세히 알아보는 건 이 책이 다루는 범위를 벗어난다. 4.5. 테이프테이프 드라이브는 음악을 위해 사용되는 카세트와 비슷한 [9] 테이프를 사용한다. 테이프는 사실상 시리얼로, 테이프의 어떤 부분에 이르기 위해 먼저 사이의 모든 부분을 통과해서 가야 되는 걸 의미한다. 디스크는 맘대로 접근할 수 있다. 즉 디스크상의 어느 곳이나 바로 갈 수 있다. 테이프가 시리얼 접근을 사용하는 것은 테이프를 느리게 만든다. 반면에, 테이프는 빠를 필요가 없기 때문에 만드는데 비교적 비용이 저렴하다. 뿐만 아니라 테이프는 쉽게 상당히 길게 만들 수 있어서, 많은 양의 데이타를 저장할 수 있다. 이런 이유로 테이프는 큰 속도는 요구하지 않으나 낮은 비용과 큰 저장용량으로 이익을 얻을 수 있는, 파일모으기와 백업같은 일에 매우 적합하다. 4.6. 포맷하기포맷한다(Formatting)는 것은 자기 매체에 트랙과 섹터를 표시하는 과정이다. 디스크가 포맷되기 전에는 자기 표면(magnetic surface)은 완전히 자기신호의 덩어리이다. 포맷되었을 때, 어디서 트랙이 이루어지고, 섹터가 나누어지는지 필수적인 선을 그림으로써 혼돈상태가 약간의 질서상태로 된다. 실제적인 자세한 것은 이와 같지 않지만, 상관없다. 중요한 것은 디스크가 포맷되지 않는다면 사용하지 못한다는 점이다. 여기서 용어가 약간 헷갈릴 것이다. MS-DOS에서는 포맷한다는 말이 파일시스템을 만드는 과정(나중에 설명된다)도 포함하면서 사용된다. 두 작업이 때때로 합쳐지기도 한다. 특히 플로피의 경우가 그렇다. 구별이 필요할 때, 파일시스템을 만드는 것은 high-level formatting이라고 하고, 진짜 포맷하는 것을 low-level formatting이라고 한다. 유닉스 안에서는 두가지를 파일시스템 만들기와 포맷하기라고 하고, 이 책에서도 역시 그렇게 사용한다. IDE 디스크와 약간의 SCSI 디스크는 공장에서 실제적으로 포맷이 되어서 반복할 필요가 없다. 그러므로 대부분의 사람들은 포맷에 대해 거의 걱정할 필요가 없다. 실은 하드디스크를 포맷하는 것은 디스크가 다소 잘 작동하지 않도록 할 수 있다. 예를 들면 자동으로 배드섹터를 교체하도록 하기 위해서는 매우 특별한 방법으로 디스크를 포맷할 필요가 있기 때문이다. 드라이브 내부 포맷 로직 인터페이스가 드라이브마다 다르기 때문에, 포맷할 필요가 있거나 포맷해야 하는 디스크는 때때로 특별한 프로그램을 요구한다. 포맷프로그램은 때때로 바이오스에 있기도 하고, 혹은 MS-DOS프로그램으로 제공되기도 하지만 그 어느 것도 리눅스에서 쉽게 사용할 수 없다. 포맷하는 동안 배드블럭(bad blocks)이나 배드섹터(bad sectors)라고 불리는 디스크상의 잘못된 곳을 만날 수 있다. 때때로 드라이브 자체적으로 처리되지만, 만약 더 많이 나타난다면 디스크의 배드난 부분을 사용하는 것을 피하기 위해 다른 일을 해야한다. 배드난 곳을 피하는 논리는 파일시스템에 포함된다. 파일시스템 안에 정보를 어떻게 첨가하는지는 다음에 설명한다. 대안으로, 배드난 부분을 포함하는 작은 파티션을 만들 수 있다. 파일시스템은 매우 큰 배드가 있으면 때때로 문제를 일으키므로 만약 배드난곳이 매우 넓다면 작은 파티션을 만드는 것이 좋은 생각이다. 플로피는 fdformat으로 포맷한다. 사용할 플로피 장치파일은 매개변수로 주어진다. 예를 들어, 첫번째 플로피드라이브 안에 있는 고밀도 3.5인치 플로피를 포맷하는 경우를 보자.
fdformat 시 플로피를 확인한다, 즉 배드 블럭이 있는지 체크한다. 배드블럭을 몇차례 확인하려고 할 것이다(이과정을 들을 수 있다. 드라이브에서 극적으로 소리가 바뀔 것이다.) 만약 플로피가 오로지 부분적으로 배드가 났다면(읽기/쓰기 헤드의 먼지때문에, 몇개의 에러는 잘못된 신호이다), fdformat는 불평하지 않을 것이나, 진짜 에러는 플로피 확인 작업을 중지시킬 것이다. 커널은 발견한 I/O 에러를 로그메시지에 기록할 것이다. 메시지는 콘솔로 가거나, 만약 syslog가 사용된다면 /usr/log/messages 파일로 갈것이다. fdformat 자신은 에러가 어디서 일어났는지 말하지 않을 것이다(보통 염려하지 않는데, 플로피는 배드난 것은 던저버려도 될만큼 충분하게 싸다).
최근의 많은 디스크는 자동적으로 배드블럭을 알아차리고, 대신에 특별히 확보된 좋은 블럭으로 배드블럭을 고치려고 시도할 것이다. 이 과정은 운영체제에는 보이지 않는다. 만약 디스크가 배드블럭을 자동을 고치는지 알고 싶다면 그런 특징은 디스크매뉴얼에 문서로 있을 것이다. 만약 배드블럭의 수가 매우 많이 증가하게 된다면, 디스크가 녹슬어 사용하지 못할 때까지 기회는 있겠지만, 자동으로 고치는 기능을 지니는 디스크조차도 실패할 수 있다. 4.7. 파티션하드디스크는 몇개의 파티션(partitions)으로 나누어질 수 있다. 각 파티션은 마치 다른 하드디스크처럼 동작한다. 만약 하나의 디스크를 가지고 있는데 두개의 운영체제를 사용하고 싶다면 디스크를 두개의 파티션으로 나눌 수 있다. 각 운영체제는 자신의 파티션을 원하는 대로 사용하고 다른 쪽을 건들지 않는다. 이런 방식으로 두개의 운영체제가 같은 디스크 안에 평화적으로 공존할 수 있다. 파티션이 없다면 다른 운영체제를 위해 하드디스크를 하나 사야할 것이다. 플로피는 파티션으로 나누지 않는다. 이것을 막는 기술적인 이유는 없으나 플로피는 너무 작아서, 파티션으로 나누는 것은 쓸모있는 경우가 매우 드물것이다. CD-ROM도 역시 보통 파티션을 나누지 않는다. 시디롬을 한 큰 디스크로 사용하는 것이 더 쉽고, 몇개의 운영체제를 시디롬에 설치할 필요가 좀처럼 없기 때문이다. 4.7.1. MBR, 부트섹터, 파티션 테이블하드디스크가 어떻게 나누어져 있는가에 대한 정보는 하드의 첫번째 섹터에 저장된다(즉 첫번째 디스크 표면위에 있는 첫번째 트랙의 첫번째 섹터). 이 첫번째 섹터가 바로 master boot record (MBR)이다. MBR은 컴퓨터가 처음 부팅될 때 바이오스가 읽어들이고 시작하는 섹터이다. master boot record는 파티션 정보를 읽어들이고, 어떤 파티션이 부팅 가능한 파티션인지, 각 파티션의 boot sector인 첫번째 섹터(MBR도 역시 부트섹터이나 MBR은 특별한 상태여서 특별한 이름을 가지고 있다.)를 읽어들이는 조그마한 프로그램을 포함하고 있다. 파티션 설계는 하드웨어에 내장되는 것도 아니고 바이오스에 있는 것도 아니다. 파티션은 많은 운영체제들이 따르는 관습일 뿐이다. 모든 운영체제들이 파티션 설계를 따르는 것은 아니지만, 그런 운영체제는 예외일 뿐이다. 어지간한 운영체제는 파티션을 지원하나, 그 운영체제들은 하드디스크의 한 파티션을 차지하고 그 파티션안에서 그 운영체제 내부의 파티션 방법을 사용한다. 나중 형식이 다른 운영체제(리눅스를 포함하는)와 평화스럽게 공존하고, 다른 특별한 수단을 요구하지 않으나, 파티션을 지원하지 않는 운영체제는 같은 디스크상에 다른 운영체제와 공존할 수 없다. 안전책으로, 종이에 파티션 정보를 적어두는 것이 좋다. 만약 파티션이 망가졌을 경우 모든 파일들을 날리지 않아도 되기 때문이다.(망가진 파티션은 fdisk로 고칠 수 있다.). 관련 정보는 fdisk -l 명령으로 얻을 수 있다.
4.7.2. 확장파티션과 논리 파티션PC하드 디스크의 본래 파티션 설계는 오로지 4개의 파티션만 허용한다. 4개만 허용하는 것은 실생활에서 너무 작다는 것이 빠르게 알려졌는데, 상당수의 사람들이 4개의 운영제체 이상을 (Linux, MS-DOS, FreeBSD, NetBSD, Windows/NT, 그외 약간의 운영체제들) 사용하길 원한다는 것이 부분적인 이유이나, 주된 이유는 때때로 한 운영체제가 몇개의 파티션을 가지는 것이 좋기 때문이다. 예를 들어, 스왑공간은 속도문제 때문에 리눅스의 주된 파티션에 있는 대신 스왑공간 고유의 파티션에 있는 것이 가장 좋다.(다음에 설명한다.) 이 설계문제를 극복하기 위해 확장파티션(extended partitions)이 개발되었다. 확장파티션을 통해 primary partition을 하위 파티션들로 나눌 수 있다. 나뉘어지는 primary partition이 확장파티션이고 하위파티션이 논리파티션(logical partition)이다. 논리파티션은 primary [10] partition처럼 행동하나 다르게 만들어진다. primary partition과 논리파티션 사이에는 속도차이는 없다. 하드디스크의 파티션 구조는 그림 4-2와 같이 보일 수도 있다. 디스크는 3개의 primary partition으로 나누어져있고, primary partition 중 2번째는 2개의 논리파티션으로 나누어져있다. 디스크의 일부분은 파티션되어 있지 않다. 디스크 전체적으로, 그리고 각각 primary partition은 부트섹터를 가지고 있다. 4.7.3. 파티션 형식파티션 정보(MBR에 하나, 확장파티션에 하나씩 있는)에는 각 파티션의 형식을 확인하는 1바이트가 파티션당 하나씩 있다. 그 1바이트로 파티션을 사용하고 있는 운영체제를 확인하거나, 운영체제가 어떤 목적으로 그 파티션을 사용하는지 확인하려고 할 것이다. 우연히 같은 파티션을 사용하는 2개의 운영체제를 피하는 것을 가능하게 하기 위해서이다. 그러나 실제로 운영체제들은 파티션형식 바이트에 대해 걱정하지 않는다. 예를 들면, 리눅스는 파티션형식 바이트가 무엇인지 걱정하지 않는다. 나쁘게도, 약간의 운영체제들은 파티션형식 바이트를 부정확하게 사용한다. 예를 들면, 적어도 DR-DOS의 어떤 버전들은 파티션형식 바이트의 가장 중요한 비트를 무시한다. 각 바이트 값이 뜻하는 것을 명시한 표준단체가 없으나, 상당히 일반적으로 받아들여지는 값들이 표 4-1에 포함되어 있다. 같은 값들이 리눅스 fdisk에서 사용가능하다. 표 4-1. 파티션 형식 (리눅스의 fdisk 프로그램에서 따옴).
4.7.4. 하드디스크 파티션하기파티션을 만들고 삭제할 수 있는 많은 프로그램들이 있다. 대부분의 운영체제는 그들 자신의 프로그램을 가지고 있고, 다른 운영체제에서 할 수 없는 특이한 것을 할 경우는 운영체제 고유의 프로그램을 사용하는 것이 좋은 생각일 것이다. 리눅스에 있는 것을 포함해서 많은 프로그램들을 fdisk라 하거나 약간 변종들도 있다. 리눅스 fdisk의 자세한 사용법은 man 페이지에 나와있다. cfdisk명령은 fdisk와 비슷하나, 좀더 좋은(전체화면) 사용자 인터페이스를 가지고 있다. IDE디스크를 사용할 때, 부트 파티션(부팅가능한 커널 이미지 파일이 있는 파티션)은 반드시 첫 1024실린더 안에 완전히 있어야 한다. 디스크는 부팅중(시스템이 프로텍티드 모드로 가기 전) 바이오스를 통하여 사용되기 때문인데, 바이오스는 1024실린더 이상을 처리할 수 없다. 첫 1024실린더에 부분적으로 있을 뿐인 부트파티션을 사용하는 것이 때때로 가능하다. 이건 바이오스가 읽는 모든 파일들이 첫 1024실린더안에 있는 한 작동한다. 그렇게 정렬하는 것이 힘들기 때문에, 부분적으로 첫 1024 실린더에 부트파티션이 오게하는 것은 매우 나쁜 생각이다. 커널업데이트나 디스크 조각모음이 부팅할수 없는 시스템을 언제 초래할지 모르는 일이다. 그러므로, 부트 파티션이 첫 1024실린더 안에 완전히 있는지 확실히 해야 한다. 실은, 바이오스나 IDE 디스크의 몇몇 새 버전에서는 1024실린더 이상되는 디스크를 처리할 수 있다. 만약 그런 시스템이라면 1024 실린더문제를 잊어버려도 된다. 만약 시스템이 1024 실린더를 처리할 수 있는지 완전히 확신할 수 없다면, 첫 1024 실린더안에 부트 파티션을 집어넣어라. 리눅스 파일시스템은 1kB 블럭크기, 즉 2섹터를 사용하기 때문에, 각 파티션들은 짝수개의 섹터를 가져야 한다. 홀수로 섹터를 가지면 마지막 섹터를 사용 못하게 될 것이다. 문제를 일으키지는 않겠지만, 보기 흉하고, 버전에 따라 그것에 대해 경고하는 fdisk도 있을 것이다. 파티션 크기를 바꾸는 것은 보통 첫번째 그 파티션(단 경우에 따라서는 오히려 전체 디스크)에서 남기고 싶은 모든 것을 백업하고, 파티션을 삭제하고, 새로운 파티션을 만든 후, 새로운 파티션으로 모든 것을 다시 저장하는 과정이 필요하다. 파티션을 늘리는 거라면, 인접한 파티션 역시 크기를 조절하는(그리고 백업하고 다시 저장하기)것이 필요할 지도 모른다. 파티션 크기를 바꾼다는 것은 괴로운 일이기 때문에, 처음에 파티션을 적절히 하거나, 효휼적이고 사용하기 쉬운 백업시스템을 가지는 것이 바람직하다. 만약 사람의 간섭이 필요없는 매체(플로피가 아니라 시디롬)로 설치하는 거라면, 때때로 처음에 다른 설정으로 설치하는 것이 쉽다. 백업할 데이타를 가지고 있지 않기 때문에, 여러번 파티션 크기를 수정하는 것이 고통스럽지 않다. fips라는 MS-DOS프로그램이 있는데, 백업과 다시 저장할 필요 없이 MS-DOS 파티션의 크기조정을 하나, 다른 파일시스템을 위해서도 여전히 필요하다. 4.7.5. 장치파일과 파티션각 파티션과 확장파티션은 자신만의 장치파일을 가지고 있다. 전체 디스크의 이름에 1-4는 primary partition(얼마나 많은 primary partition이 있는지에 상관없이), 5-8은 논리파티션(논리파티션이 어떤 primary partition에 있는지 상관없이)으로 파티션 번호를 붙이는 것이 관습이다. 예를 들면, /dev/hda1은 첫번째 IDE 하드 디스크에 있는 첫번째 primary partition이고, /dev/sdb7은 두번째 SCSI 하드디스크에 있는 세번째 논리 파티션이다. 4.8. 파일시스템4.8.1. 파일시스템이란 무엇인가?파일시스템(filesystem)이란 운영체제가 파티션이나 디스크에 파일들이 연속되게 하기 위해 사용하는 방법들이고 자료 구조이다. 즉, 파일들이 디스크상에서 구성되는 방식이다. 파일시스템이라는 말은 파일을 저장하는 데 사용되는 파티션이나 디스크를 가리킬 때나, 파일시스템의 형식을 가리킬 때 사용되기도 한다. 그래서 파일을 저장하는 2개의 파티션을 가지고 있다는 의미에서 어떤 사람이 "난 2개의 파일시스템을 가지고 있다."고 말할지도 모르고, 파일시스템의 형식을 의미해서 "extended filesystem"을 그 사람이 사용하고 있을 것이다 디스크나 파티션과, 디스크나 파티션이 포함하고 있는 파일시스템의 차이는 중요하다. 약간의 프로그램들(합리적으로 충분히 파일시스템을 만드는 프로그램을 포함해서)은 디스크나 파티션의 원시 섹터를 직접 조정한다. 만약 디스크나 파티션에 파일시스템이 존재한다면 그 파일시스템은 파괴되거나 심하게 망가질 것이다. 대부분의 프로그램들은 파일시스템 위에서 작동하며, 파일시스템이 없는(혹은 다른 형식의 파일시스템이 있는) 파티션에서는 작동하지 않을 것이다. 파티션이나 디스크가 파일시스템으로서 사용될 수 있게 되기 전에, 초기화되어야 하며, 파일정보 기록을 위한 자료구조를 디스크에 만들 필요가 있다. 이 과정을 파일시스템 만들기(making a filesystem)라고 한다. 정확한 세부사항은 상당히 다르지만, 대부분의 유닉스 파일시스템은 비슷한 전반적인 구조를 지닌다. superblock, inode, data block, directory block, indirection block이 중심 개념이다. 슈퍼블럭은 파일시스템 크기같은 전체적인 파일시스템에 대한 정보를 포함한다(여기에 들어가는 정보는 파일시스템에 의존한다). inode는 이름을 제외한 파일에 대한 모든 정보를 포함한다. 파일이름은 inode 번호와 함께 디렉토리안에 저장된다. 디렉토리 입구는 파일이름과 파일을 나타내는 inode 번호로 구성된다. inode는 몇개의 데이터블럭 번호를 포함하는데, 데이터블럭은 파일에서 데이타를 저장하기 위해 사용된다. 하지만 inode에는 오로지 약간의 데이터블럭 번호들을 위한 공간이 있어서, 만약 더 많이 필요하면 데이타블럭을 가리키는 포인터를 위한 더 많은 공간이 동적으로 할당된다. 이런 동적으로 할당된 블럭들은 간접적인 블럭들이다. 이름은 데이타블럭을 찾기 위해, 먼저 간접적인 블럭안에서 블럭의 번호를 찾아야한다고 가리킨다. 유닉스 파일시스템은 보통 파일안에 홀(hole)을 만들도록 하는데(홀을 만드는 건 lseek로 행해진다. 메뉴얼페이지를 조사해라), 파일시스템이 파일안의 특정한 장소에 단지 0바이트가 있는체 한다는 것을 의미하나, 파일안에서 그 곳을 위해 실제적인 디스크섹터는 없다(이건 파일이 디스크 공간을 다소 적게 사용할 것이라는 것을 의미한다). 특히 이런 일이 때때로 작은 바이너리, 리눅스 공유 라이브러리, 약간의 데이타베이스와 약간의 다른 특별한 경우에 일어난다. (홀은 inode나 간접적인 블럭안에 데이타 블럭의 주소로 특별한 값을 저장하므로 이루어진다. 이 특별한 주소는 그 파일의 그 부분에 할당된 데이타블럭이 없다는 것, 즉 파일안에 홀이 있다는 것을 의미한다.) 홀은 보통 쓸모있다. 저자의 시스템에서, 간단한 측정을 통해 약 200메가바이트 총용량의 하드에서 홀을 통해 약 4메가바이트의 절약이 있을 수 있음을 볼 수 있었다. 그러나 측정에 사용된 시스템은 비교적 프로그램이 거의 없고 데이타베이스파일이 없다. 4.8.2. 다양한 파일시스템리눅스는 몇가지 파일시스템을 지원한다. 이 글을 쓰고 있는 시점에서 중요한 파일시스템은 다음과 같다.
여기에, 다른 운영체제와 파일 교환을 쉽게 하기 위해, 몇가지 외부의 파일시스템을 지원한다. 이 외부 파일시스템들은 유닉스 특징이 부족하다던가, 심각한 제한이 있다던가, 아니면 다른 특별한 점이 있는 경우를 제외하고 리눅스 파티션처럼 작동한다.
파일시스템의 선택은 상황에 따라 다르다. 호환성과 다른 이유로 리눅스 본래의 파일시스템이 아닌 것 중 하나가 필요하다면, 그것은 반드시 사용되어야 한다. 만약 자유롭게 고를 수 있다면 아마도 ext2를 사용하는 것이 가장 현명할 것이다. ext2는 모든 특성을 가지고 있고 수행능력이 부족해서 고생하지 않기 때문이다. proc파일시스템이라는 것도 존재하는데, 보통 /proc 디렉토리로 접근할 수 있다. proc파일시스템은 파일시스템같이 보일지라도 실제로 전혀 파일시스템이 아니다. proc파일시스템은 프로세스 리스트(process list, proc파일시스템의 이름의 유래)같은 일정한 커널 데이타 구조에 접근하기 쉽게 한다. proc파일시스템은 이런한 데이타 구조를 파일시스템처럼 만들어버리고, 이러한 파일시스템은 모든 평범한 파일도구로 다룰 수 있다. 예를 들어 모든 프로세스 리스트를 얻기 위해 다음 명령을 내릴 수 있다.
파일시스템이지만 proc파일시스템의 어느 것도 디스크를 건드리지 않는다는 것을 유의해라. proc파일시스템은 오로지 커널의 상상속에서만 존재한다. 누군가가 proc 파일시스템의 어떤 부분을 보려고 한다면, 커널은 실제로 존재하지는 않지만, 마치 어딘가에 존재하는 것처럼 보이게 한다. /proc/kcore 파일이 있을지라도, 디스크 공간을 차지하지는 않는다. 4.8.3. 어떤 파일시스템을 사용할 것인가?보통 많은 다른 파일시스템을 사용하는데는 조그만 이유가 있을 것이다. 현재는 ext2fs가 가장 유명한 파일시스템이고, ext2fs가 가장 현명한 선택일 것이다. 파일구조를 기록하기 위한 부하, 속도, (파악된) 안정성, 호환성과 여러가지 다른 이유에 의해서, 다른 파일시스템을 사용하는 것도 추천할만 할지도 모른다. 파일시스템을 고르는 것은 각각의 경우에 따라 결정될 필요가 있다. 4.8.4. 파일시스템 만들기파일시스템은 mkfs 명령으로 만들어진다. 즉 초기화되는 것이다. 실제로 각 파일시스템마다 다른 프로그램이 있다. mkfs는 단지 원하는 파일시스템의 형식에 따라 적절한 프로그램을 돌리는 전위 프로그램이다. 파일시스템 형식은 -t fstype 옵션으로 선택되어진다. mkfs라 불리는 프로그램들은 약간 다른 명령어 인터페이스를 가진다. 일반적이고 가장 중요한 옵션들은 아래에 요약되어 있다. 더 자세한 것은 메뉴얼 페이지를 보아라.
ext2파일시스템을 플로피에 만들기 위해, 다음과 같은 명령을 내릴 것이다.
badblocks와 배드블럭리스트 대신에 -c 옵션이 mkfs와 함께 사용될 수도 있을 것이다. 예는 아래와 같다.
포맷하는 것이 불필요한 것을 제외하고, 하드디스크나 파티션에 파일시스템을 만드는 과정은 플로피와 같다. 4.8.5. 마운트하기와 마운트 풀기파일시스템을 사용하기 전에, 마운트되어야 한다. 그리고나서, 운영체제는 모든 것이 잘 작동하는지 확실히 하기 위해 여러가지 기록하는 작업을 한다. 유닉스안의 모든 파일들은 단일 디렉토리 트리안에 있으므로, 마운트 작업은 새로운 파일시스템의 내용이 이미 어딘가에 마운트된 파일시스템의 존재하는 하위디렉토리의 내용으로 보이게 할 것이다. 예를 들어, 그림 4-3은 각각 고유의 루트 디렉토리를 지니는 세개의 다른 파일시스템을 보여준다. 마지막 두 파일시스템이 첫째 파일시스템의 /home과 /usr에 각각 마운트되었을 때, 그림 4-4처럼 단일 디렉토리 트리를 얻을 수 있다. 마운트는 다음과 같이 행해질 수 있다.
리눅스는 많은 파일시스템 형식을 지원한다. mount는 파일시스템의 형식을 추측하려고 할 것이다. 형식을 바로 지정하기 위해 -t fstype 옵션을 사용할 수 있다. -t fstype은 때때로 필요하다. mount가 사용하는 추론이 항상 동작하는 것은 아니기 때문이다. 예를 들어, MS-DOS플로피를 마운트하기 위해, 다음 명령을 내릴 수 있다.
마운트할 디렉토리는 반드시 존재해야 하지만 비어있을 필요는 없다. 그러나, 그 안에 있는 어떤 파일이라도 파일시스템이 마운트되어 있는 동안은 이름으로는 접근할 수 없을 것이다.(이미 열려있던 어떤 파일들은 여전히 접근 가능할 것이다. 다른 디렉토리에 하드링크되어 있는 파일들은 그 이름을 가지고 접근할 수 있을 것이다.) 그렇게 한다고해서 해가 되지 않고, 심지어 필요할 수도 있다. 예를 들어, 어떤 사람들은 /tmp와 /var/tmp를 같게 사용하는 것을 좋아해서, /tmp를 /var/tmp로 심볼릭링크시킨다. 시스템이 부팅될 때, /usr 파일시스템이 마운트되기 전, 루트 파일시스템에 들어있는 /var/tmp 디렉토리가 대신 사용된다. /usr이 마운트되었을 때, 루트 파일시스템에 있는 /var/tmp 디렉토리는 접근불가능이 될 것이다. 만약 /var/tmp가 루트파일시스템에 존재하지 않는다면 /var을 마운트하기 전에는 임시파일들은 사용하는 것이 불가능할 것이다. 만약 파일시스템에 어떤 것도 기록할 생각이 없다면, 읽기전용 마운트를 하기 위해 mount에 -r 스위치를 사용해라. 읽기전용 마운트는 커널이 파일시스템에 기록하려고 하는 어떤 시도도 중지하도록 할 것이고, 커널이 inode안에 있는 파일 접근 시간을 갱신하는 것도 방해할 것이다. 읽기전용 마운트는 쓸 수 없는 미디어, 예를 들어 시디롬에 필요하다. 기민한 독자들은 벌써 약간의 논리적인 문제가 있다는 것을 눈치챘다. 분명 다른 파일시스템에 마운트될 수 없는데, 첫번째 파일시스템(루트 디렉토리를 포함하기 때문에, root 파일시스템이라 불린다.)은 어떤게 마운트되는가? 글쎄 답은 마술에 의해 이루어진다이다. [11] 루트 파일시스템은 마술같이 부트타임에 마운트되고, 루트 파일시스템이 항상 마운트될 것이라고 믿을 수 있다. 루트 파일시스템이 마운트될 수 없다면, 시스템은 부팅되지 않는다. 루트로 마술처럼 마운트되는 파일시스템의 이름은 커널에 컴파일되어 들어가거나, LILO나 rdev를 이용해서 지정한다. 보통 루트 파일시스템은 처음에 읽기만 되도록 마운트된다. 그리고나서,시작 스크립트는 루트 파일시스템의 타당성을 검증하기 위해 fsck를 실행할 것이고, 만약 문제가 없다면, 시작스크립트는 루트 파일시스템을 쓰기가 허용되도록 루트 파일시스템을 다시 마운트할 것이다. fsck는 마운트된 파일시스템에서는 행해지면 안된다. fsck가 돌아가는 동안에 파일시스템에 어떤 변화가 있으면 문제를 일으킬 것이기 때문이다. 루트 파일시스템이 체크되는 동안에 루트파일시스템은 읽기전용으로 마운트되어 있기 때문에, fsck는 걱정없이 어떤 문제라도 고칠 수 있다. 다시 마운트하는 작업은 파일시스템이 메모리에 저장했던 어떤 중간에 생긴 데이타라도 방출해 버릴 것이다. 많은 시스템에는 부팅시간에 자동으로 마운트되어야할 다른 파일시스템이 있다. 그런 파일시스템들은 /etc/fstab 파일에 명시되어 있다. 형식에 대한 자세한 것을 위해서는 fstab메뉴얼페이지를 봐라. 여분의 파일시스템이 마운트될 때 정확한 세부사항들은 많은 인수에 의존하고, 필요하다면 각 관리자에 의해 설정될 수 있다. 이에 대한 자세한 내용은 6장을 보기 바란다. 파일시스템이 더 이상 마운트될 필요가 없을 때, umount라는 명령으로 마운트를 풀 수 있다. [12] umount는 한개의 인수를 취한다. 장치파일이나 마운트된 곳이다. 예를 들어 전 예에서 마운트한 디렉토리들의 마운트를 풀고 싶다면, 다음 명령을 사용할 수 있다.
명령을 어떻게 사용하지는 더 많은 지시들을 원하면 메뉴얼페이지를 봐라. 항상 마운트된 플로피의 마운트를 풀어야하는 것은 꼭 해야할 일이다. 드라이브에서 플로피를 그냥 꺼내지 마라! 디스크 캐쉬때문에 플로피를 마운트 풀기 전까지 데이타가 플로피에 기록될 필요는 없어서, 드라이브에서 플로피를 너무 빨리 제거하는 것은 플로피 내용이 왜곡되게 할지도 모른다. 만약 플로피에서 읽기만 했다면, 그렇지 않겠지만, 만약 기록했다면, 우연일지라도, 결과는 재앙일지도 모른다. 마운트하기와 마운트 풀기는 슈퍼유저 권한을 필요로 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
