개정을 나누어 가지고 있는 많은 컴퓨터의 site는 사용자 데이터 베이스를 NIS나 다른 방법으로 저장한다. 컴퓨터들은 중앙에서부터 다른 컴퓨터들에게 자동적으로 데이터 베이스를 복사할 것이다.
이 사용자들의 데이터 베이스는 사용자에 관한 password와 사용자들의 홈디렉토리, 실명 과 login shell 등의 몇 개의 추가적인 정보를 가지고 있다. 이런 사용자에 대한 추가적인 정보들은 다른 사람들이 읽을 수 있게 공개를 필요로 한다. 그러므로 password은 encode되어 저장된다.
누군가가 컴퓨터를 통한 실질적인 로그인을 하지 않고 다양한 암호 해독 방법으로 password를 추측하여 password를 해독하려 한다면 저장된 password는 장애를 일으킨다. shadow password는 다른 누군가가 password 안으로 침입하는 것을 막는다. 이것은 오직 root만이 읽을 수 있다. (이 password 를 여전히 encode되어 저장된다.). 그러나 shadow password를 지원하지 않는 에서 shadow password를 인스톨 한다면 diOEcult 할 수 있다.
password를 가지고 있든지 가지고 있지 안든지, 시스템 안의 password 들이 쉽게 추측할 수 있도록 하는 것은 중요한 문제이다. 크랙 프로그램들은 password를 크랙하는데 사용되어 질 수 있다. 크랙이 침입자에 의해 실행되는 반면에, 쉽게 해독되는 password를 찾아내기 위해 시스템 관리자에 의해 실행될 수 도있다. 좋은 password은 passwd 프로그램에 의해 만들어 질 수도 있다. 시실 이 passwd를 만드는 프로그램은 CPU 클럭으로 만들어지기 때문에 password 크랙 프로그램이 아주 많은 시간을 계산 하여야 한다.
사용자가 그룹데이터베이스는 /etc/group 에 보관된다. shadow password 를 가진 프로그램에서는 /etc/shadow group dp 있을 수 도 있다. root는 언제나 대부분의 터미널 네트웍을 통해서 로그인할순 없다. 오로지 /etc/security 의 터미널 리스트를 통해 로그인 해야 한다. 이것은 하나 또는 그이상의 터미널을 통한 물리적인 접속을 얻는 것을 필요로 한다. 그러나 다른 사용자로서 어떤 터미널에서나 로그인하는 것은 가능하다. 그리고 root가 되어 사용하는 것은 가능하다.
6.6 Shall startup
상호 활동적인 login shell 이 시작되었을 때 이것을 자동적으로 하나 또는 이 per**ed 한 것들을 실행 한다. Dioeerent shell dioeerent 것들을 실행한다. 더많은 자료를 위해 각 셸의 문서를 넣어라.
대부분의 shells 어떤 전체적인 것들을 운영해야 한다. 예를 들면, Bourne shell과 이것의 파생물들 은 /etc/profile 을 실행한다. 더욱이 그들은 사용자의 home directory에 있는 profile 을 실행한다. /etc/profile 은 system 의 처리가 일반적 사용자 환경을 setup하는 것을 허락한다. 틀별이, 일반적인 경우를 포함하는 지역 명령 디렉토리들은 포함하고 path를 설정하는 반면에 profile은 필요로 한다면 사용자가 그 자신의 취향에 맞는 환경을 습관화하는 것을 이미 예상한 설정이나 미리 정한 환경을 파괴함으로서 허락한다.
제7장. 백업
하드웨어는 신뢰성이 보장되지 않을수있다.
소프트웨어는 결정적으로 믿을수 있는 것은 아니다.
사람들은 확인할수 있는 믿음이다.
자연은 결정적으로 믿을수 있는 것이다.
이 장에서는 왜,어떻게, 그리고 백업을 할 때,풀때 어떻게 하는 것인지를 설명한다.
7.1 백업이 중요한 점
당신의 자료는 소중하다. 그것을 재생산하려면 시간과 금전적노력과 사람들은 큰슬픔을 갖게 될것이다;때때로 만약그것이 시험장의 결과라면 그것은 다시 만들수도 없을수도 없다. 연구결과라면 당신은 잃어버리지 않기위해 다단계의 보안을 취해야 한다.
왜 당신은 자료를 잃어버리는지 4 가지 이유가 있다.;하드웨어의 잘못됨,소프트웨어의 버그들,사람들의 오동작,자연재해. 비록 근래의 하드웨어들은 매우 신뢰할만하여도, 그것은 여전히 자연스럽게 정지하기도 한다.저장을위한 하드웨어중 가장 중요한부분은 하드디스크이며,이것은 전기적 신호와 함께 얇은마크네틱 선에 의존하고 있다. 요즘의 소프트웨어는 이것에 의존하지 않는 경향이 있다.; 사람은 매우 신뢰할수 없는 존재이다. 그들은 실수를 하기도 하고 악의가 있어서 고의로 자료를 파괴하기도 한다.
모든 면에서 좋아지고 있다. 이것은 어떤 일에서건 작은 기적이다.
백업은 자료를 보호하는 한 방법이다.
여러개의 자료의 복사복을 만들어 놓는 것은, 만약 하나가 파괴되어도 괜찮을수 있다.
(비용은 단지 백업본으로부터 잃어버린 자료의 풀어놓는것일 뿐이다.)
적당히 백업하는 것은 중요하다.
잘 백업하는 부분은 그들의 일을 확고히 한다; 당신의 백업이 일을 하지않는 것을 원하지 않는다면 말이다.
당신이 백업본을 만들려할 때 손상을 입었을 수도 있다; 만약 당신이 단 하나의 백업본을 마들었다면, 그것은 잘 파괴되는 경향이 있다. 당신이 담배재와 같은 것을 남겨놓았을 경우에. 백업을 복원 할 때, 15000사용자의 데이터 베이스와 같이, 어떤 중요한 데이터를 백업하는 것을 잊지 않아야 한다.
가장 좋은 것은, 모든 당신의 백업을 완벽하게 하는 것이다, 하지만
그러나,당신이 썼던 일종의 테이프를 읽는 가장 늦은 기지수 테이프 드라이브는 사람 이었습니다. 예비 복사에 관해서 말하자면 , 편집증은 직무내용 설명서에서 입니다.
7.2 백업미디어의 선택
가장 중요하게 고려하는 것은 예비의 매체의 선택입니다.
당신은 비용 신뢰성 속력 가용도를 생각할 필요가 있습니다. 그리고,유용성 가격은 중요합니다, 당신이 몇몇의 시간 더 예비의 기억장치를 오히려 가지고 있어야했었던 싼 매체는 보통 절대 필요한 것입니다. 예비의 매체는 여러해 동안 파괴됨이 없이 데이터를 잡을 수 있음에 틀림없습니다.
당신은 중간의 aoeects를 씁니다.
하드 디스크는 전형적으로 매우 믿을 수 있습니다. 그러나, , 위에 돌아 왔던 디스크 당신이 같은 종류의 컴퓨터에서 입니다.
만약 예비 복사가 상호작용을 없이 지내져야만 있다고 속도는 보통 매우 중요합니다,.
만약 존재하지 않는다면 당신이 백업의 매체을 쓸 수 없는 이래로(이유로) 가용도는 명백하게 필요합니다,.
이것이 가지고 있는 것은 몇몇의 사람(에)게 발생했습니다.
당신은 천재 지변후에 복원할수 없을 것입니다.
유용성은 얼마나 자주 백업하느냐하는 항목입니다. 백업하는 것이 쉽고 더 낫다.
백업매개물은 쓰기에 힘들고 지루하면 안된다.
전형적인 선택은 플로피와 테이프이다. 플로피는 매우 싸고 충분히 신뢰할만하다. 하지만 별로 빠르지 못하고,매우 유동적이다, 하지만 대용량의 데이터를 위해서는 적당치않다.
테이프는 다소 비싸고 충분히 신뢰할만하며,충분히 빠르다,아주 신뢰할만하다, 그리고 테이프의 크기에 따라 편리하게 이용할수 있다.
다른선택이 있다. 그들은 일반적으로 매우 유동적이지 못하다. 하지만 만약 문제를 발생하지 않는다면, 그들은 다른방향에서 더 나을수도 있다. 예를들어, 마그네틱옵티컬디스크는 양면모두 좋은 상태를 유지할수 있다.(그들은 대용량의 데이터를 랜덤하게 억세스하고, 한부분만 빨리 복원할수 있다.)
7.3 백업툴의 선택
백업을 하기 위해서 많은 툴들이있다. 전통적인 유닉스툴들은 tar, cpio,그리고, dump를 위해 사용되어진다. 게다가, 많은 수의 써드파티 팩키지들이 사용되어 질수 있다.(모두 프리웨어또는 상용) 백업매개물의 선택은 툴의 선택으로 결정될수 있다.
tar와 cpio는 유사하고, 백업의 관점으로부터 거의 동등하다.
둘다 테이프상에서 복원할수 있고, 그들로부터 다시 찾을수 있다. 둘다 거의 모든 미디어에 사용할수 있다,
커널디바이스 드라이버들이 저수준의 핸들링과 유저레벨프로그램과 같은 경향이 있다.
tar 와 cpio의 어떤 유닉스버전들은 별난 것으로 인해서 문제를 일으킬수도 있다.(심볼릭 링크,디바이스 에러, long filename, 기타등등), 하지만 리눅스버젼들은 모두 정상적으로 작동한다. 이것은 백업을 위해 특별히 쓰여졌다; tar 와 cpio는 비록 그들이 백업에 아주 잘사용되어진다. 시스템디렉토리를 읽는 것은 어떤 이득이 있다. 그것은 그들의 시간의 낭비를 없애줄수 있다; tar 와 cpio를 위해 당신은 시스템을 읽기 전용으로 만들어 줄수 있다. 만약 모든 것이 백업을 위해 필요하다면, 이후로 그것은 디스크헤드의 움직임을 최소화하여 줄수 있다; 가장 중요한 단점은 시스템소프트웨어에 따라 특별해야 한다는 것이다; 리눅스 dump프로그램은 ext2형식만 지원한다.
dump 는 또한 백업수준의 디렉토리 지원을 한다.(우리는 아래와 같이 논의 할수 있으것이다); tar와 cpio는 다른툴과같이 도구들이다.
써드파트백업툴의 비교는 이책의 관점에서 벗어난다.
리눅스 소프트웨어 맵리스트는 프리웨어가 많다.
7.4 Simple backups
간단한 백업기법은 모든 것을 한번에 백업하는 것이다.
첫 번째 백업은 풀백업이라 불리우고, 두 번째는 백업의추가를 말한다.
풀백업은 종종 부가시보다 더많은 노동력을 요구한다.
부가한 백업들로부터 복원하는 것은 풀백업으로부터 보다 많은 일을 필요로 한다.
복원은 최적화 될 수 있다. 그래서 당신은 백업을 할 때면 언제나 모든 것을 백업하기를 원한다; 이 방법은 백업은 조금의 수고를 더한다. 하지만 거기에는 부가적인 백업과 풀백업모다 복원에 더욱 필요로 한다.
만약 당신이 매일 백업하기 원하고 6개의 테이프가 있다면 당신은 첫 번째로 풀백업을 할수 있다.(금요일.!), 그리고, 테이프2에서 5까지(월요일에서 목요일까지).
그러면 당신은 하나의 새로운 풀백업을 6번테이프에(두번째 금요일), 그리고, 2번째 테이프를 추가용으로 다시 시작할수 있다. Friday)
만약 당신이 6개 이상의 테이프를 가지고 있다면 당신은 풀백업을 위해 하나를 여분으로 남겨둘수 있을것이다.이 방법으로 당신은 몇주전부터 풀백업을 받을수 있을 것이다.
7.4.1 tar로 백업 만들기
풀백업은 tar로 쉽게 할수 있다;
# tar --create --file /dev/ftape /usr/src
tar: Removing leading / from absolute path names in the archive
아래는 tar의 GNU버젼의 사용을 보여주고 그것의 긴 옵션명을 보여준다.
tar의 전통적인 버전은 단일문자옵션만 지원했다. GNU버젼은 또한 하나이상의 테이프나 플로피를 핸들링할수 있다.그리고, 또한 매우 긴파일명; 모든 전통버젼이 이것을 할수 있는 것은 아니다.(리눅스만이 GNU의 tar를 이용한다.)
당신은 --multi volume(-M)옵션으로 플로피에서 연속 백업한다.
# tar -cMf /dev/fd0H1440 /usr/src
tar: Removing leading / from absolute path names in the archive
Prepare volume #2 for /dev/fd0H1440 and hit return:
#
당신이 백업하기 전에 플로피는 먼저 포맷을 해야 하며, 또는 다른 윈도우나 가상 터미널을 사용하고, 새로운 플로피를 위해 tar가 요청할때해야한다.
그후에 당신은 백업을 만들 수 있고, 당신은 그것이 좋은지 (-d)옵션으로 체크해야한다.
# tar --compare --verbose -f /dev/ftape
usr/src/
usr/src/linux
usr/src/linux-1.2.10-includes/
....
#
Failing to check a backup means that you will not notice that your backups aren't
working until after you've lost the original data.
하나의 추가 백업은 -N옵션으로 tar에서 행해질수 있다.
# tar --create --newer '8 Sep 1995' --file /dev/ftape /usr/src --verbose
tar: Removing leading / from absolute path names in the archive
usr/src/
usr/src/linux-1.2.10-includes/
usr/src/linux-1.2.10-includes/include/
usr/src/linux-1.2.10-includes/include/linux/
usr/src/linux-1.2.10-includes/include/linux/modules/
usr/src/linux-1.2.10-includes/include/asm-generic/
usr/src/linux-1.2.10-includes/include/asm-i386/
usr/src/linux-1.2.10-includes/include/asm-mips/
usr/src/linux-1.2.10-includes/include/asm-alpha/
usr/src/linux-1.2.10-includes/include/asm-m68k/
usr/src/linux-1.2.10-includes/include/asm-sparc/
usr/src/patch-1.2.11.gz
#
7.4.2 tar 로 복원하기
복원하기 위한 옶션은 -x 이다;
# tar --extract --same-permissions --verbose --file /dev/fd0H1440
usr/src/
usr/src/linux
usr/src/linux-1.2.10-includes/
usr/src/linux-1.2.10-includes/include/
usr/src/linux-1.2.10-includes/include/linux/
usr/src/linux-1.2.10-includes/include/linux/hdreg.h
usr/src/linux-1.2.10-includes/include/linux/kernel.h
...
#
당신은 또한 커맨드라인에 써 줌으로해서 단지 하나또는 디렉토리채로 풀수 있다.(서브디렉토리를 가지고 있을경우)
# tar xpvf /dev/fd0H1440 usr/src/linux-1.2.10-includes/include/linux/hdreg.h
usr/src/linux-1.2.10-includes/include/linux/hdreg.h
#
만약 당신이 백업볼륨을 열람하기 원하면 (-t)옵션을 사용하여라.
# tar --list --file /dev/fd0H1440
usr/src/
usr/src/linux
usr/src/linux-1.2.10-includes/
usr/src/linux-1.2.10-includes/include/
usr/src/linux-1.2.10-includes/include/linux/
usr/src/linux-1.2.10-includes/include/linux/hdreg.h
usr/src/linux-1.2.10-includes/include/linux/kernel.h
...
#
tar는 항상 백업볼륨을 순차적으로 읽는 것을 기억하라.그래서, 큰 볼륨들은 더 느리다.그러나, 테이프드라이브나 다른 순차적 매체를 읽을때는 랜덤하게 접근하는 데이터베이스 기술이 불가능하다.
7.5 멀티레벨 백업
이전 부분에서 간단한 백업 수단의 윤곽을 살펴보았다 이것은 종종 개인이나 작은 site에 아주 적합하다. 더 많은 용도로 사용하려면, 멀티레벨 백업은 더욱 적당하다.
간단한 방법은 두가지 백업레벨들이 있다; 전부그리고, 추가 백업이다. 이것은 레벨을 일반화 할 수 있다. 풀백업은 레벨0, 그리고 추가백업의 1,2,3...의 레벨이다. 각 추가 백업레벨은 같거나 또는 이전레벨 또는 백업이후로 바뀐 당신이 백업하는 모든것들이다.
이렇게 하는 목적은 긴 백업정보를 쉽게 하기 위해서이다. 이전부분에서 예를 들면, 백업정보는 이전의 풀백업으로 되돌려진다.이것은 더많은 테이프들을 가지게할수 있다, 반면 한주에 한번의 새로운테입만이다, 이것은 너무 비싸다. 긴 백업정보는, 긴시간동안 종종 지워거나 사고 때문에 유용하다.
멀티레벨을 가지는 백업 정보는 더욱쉬워질수 있다. 예를 들어, 만약 우리가 10개의 테이프를 산다면, 우리는 월별 백업을 위해서 1에서 2개를 사용할수 있다.(각 달의 첫 번째 금요일) 테이프 3에서6은 주간 백업용이다.
7.6 무엇을 백업하는가?
당신은 가능한 많이 백업을 원할 것이다. 주요한 예외는 소프트웨어가 쉽게 재설치가능한 것일때이다. 하지만 그들이 그렇게 할수 있다해도 백업은 중요한 것이다. 다른 주요한 예외는 시스템상의 이유이다; 커널은 항상 자동으로 생성하는 데이터를 가지고 있다. 이것을 백업한다는 것은 결코 좋은 생각은 아니다. 이것은 자동적으로 생성되므로 백업이 불필요한 것이다. Gray areas는 새로운 스풀과 많은 다른것들을 /var에 포함하고 있다. 당신은 무엇이 중요한가를 고려해 보아야할 것이다. 백업을 위한 것은 명백한 것이다. /home과 시스템의 장치들.( /etc, 하지만 시스템에 흩어진 다른 것들도 가능하다면 백업하라)
7.7 압축 백업
백업은 많은 공간을 요구한다. 그것은 많은 경제적인 비용일수 있다. 필요한 공간을 줄이면 되는데, 백업은 압축되어질수 있다. 그렇게 하는 것에는 몇가지 방법이 있다. 어떤 프로그램은 압축을을 지원한다; 예를 들어 gzip(-z)옵션이다. 당신은 무엇이 쉬울 인지 결정해라.어떤 사람들은 한다스의 플로피가 더 쉽다고 생각한다. GNU tar pipe를 위한 gzip압축프로그램은 백업미디어에 쓰기 전에 압축해준다.
불행히도, 압축백업은 문제점을 발생시킬수도 있다. 자연적으로 어떤환경 때문에, 만약 하나의 비트가 잘못 되엇다면 모든 나머지 데이터가 사용못하게 될 수 있다. 어떤 백업프로그램은 에러를 교정해 준다. 하지만 많은 수의 에러는 어찌할 도리가 없다. 이 수단으로 만약 백업이 GNU tar의 방법으로 압축되어진다면, 하나의 에러를 백업중에 만나도 나머지 데이터를 잃을수도 있다. 백업은 안전해야된다. 그리고, 압축의 방법은 좋은생각이 아니다.
하나의 선택적방법으로 각부분을 따로 압축하는 것이 있다. 이것은 여전히 하나를 잃는 방법이다. 하지만 모든 다른 것들은 무사할수 있다. 잃어 버린 부분은 어떠한 방법으로도 되찾을수 있다. 그래서 이 상황은 모두 압축한 것보다 덜 심각한 것이다. afio프로그램은 이것을 행할수 있다.
압축은 시간이 걸리고, 이것은 테이프드라이브를 위해서도 충분히 빠른 시간을 이용하지 못하게 한다. 이것은 느린 컴퓨터에서만 문제점이 될 것이다. 만약 테이프 드라이브가 자료를 더빨리 이용하지 못한다면, 이것은 정지한다; 이것은 백업을 더 느리게 만들고 테이프와 드라이브를 나쁘게 할수도 있다.
제8장. 시간관리
Time is an illusion. Lunchtime double so. (Douglas Adams.)
이장에서는 리눅스 시스템이 어떻게 시간을 관리하고 문제의 발생을 피하기 위해서는 무엇이 필요한지에 대해서 설명한다. 일반적으로, 시간에 대해서는 어떤 것도 할 필요가 없지만 이것을 이해하는 편이 더 좋다.
8.1 Time Zone
최근의 연구에 따르면 태양이 최정점에 있는 오후부터 지구는 돈다. 오후는 어떤 장소, 어떤 시간에서도 오며 이것이 지역시간의 기준이 된다. 인간은 여러 가지 단위로 시간을 측정한다. 대부분의 것이 오후같은 자연 현상에 묶이게 된다. 그러므로 같은 장소에 있는 한은 지역시간차는 중요하지가 않게 된다.
만일 당신이 다른 장소에서 통신이 필요하다면 여러분은 '일반시'에 대하여 알아야 한다. 현대에는 세상의 대부분의 장소에서 세상의 대부분의 장소와 의사소통을 한다. 그래서 '지구 표준시'가 정의되었다. 이 시간이 Universal Time( UT 혹은 UTC, 일반적으로는 GreenWich Mean Time 혹은 CMT로 알려져 있다. 사삼들이 통신하기 위해 다른 지역시간이 필요할 때 그들은 Universal Time으로 표현할 수 있다. 그래서 시간에 대해 혼란스러운 일이 발생되지 않는다.
각각의 지역시간은 Time Zone이라 불린다. 정치적으로는 다르지만 지리학적으로 같은 위치에 있는 모든 장소는 같은 Time Zone으로 인정된다. 여러 가지 이유로 많은 나라에서 Daylight Savings Time은 사용한다. 이것은 그들의 시계로 그들이 일하는 동안 더 만든 낮시간을 갖도록 하기 위해 겨울 동안 시계를 뒤로 돌린다. 다른 나라들은 이렇게 하는 것을 하지 않는다.저렇게 하는 것들도 시계가 움직이는 것이 일치하지 않는다. 그래서 그들은 매년 규칙을 변화시킨다. 이런 이유 때문에 Time Zone이 중요한 것이다.
Time Zone들은 위치나 혹은 지역과 국제시간간의 차이를 말하는데 최고의 이론이 된다. 미국에나 몇몇 다른 국가에서 지역 Time Zone은 이들을 갖고 세계의 문자로된 약자를 갖는다. 이 약자는 독특하지는 않지만 어쨌든 이 약자는 국가로 이름붙여지지 않는다면 사용되지도 않는다. 이것은 지역시간에 대해 말하는 것보다 낮다. 즉, "Helsimhi"는 똑같은 Time Zone규칙을 따르는 동유럽의 모든 국가를 나타내는 것은 아니지만 동유럽시간을 대표한다.
리눅스는우리가 아는 모든 Time Zones를 Time Zone으로 팩키지로 갖고 있고그것은 쉽게 규칙이 바뀔때마다 업데이트될 수 있다. 모든 system관리자가 필요한 것은 적당한 Time Zone을 선택하는 것이다. 또한 각각의 사용자는 그 자신의 Time Zone을 맞출 수 있고, 이것은 인터넷 상에서 다른 나라의 컴퓨터로 작업하는 많은 사람들에게 중요한 것이다. 당신의 지역 Time Zone에서 규칙이 Daylight Saving Time 때문에 바뀌었을 때 당신은 당신의 최소한 리눅스 시스템의 부분을 Upgrade 하는 것을 명심하라. 다른 것보다 System Time Zone을 맞추고 Time Zone의 data파일과 업그레이드해서 시간에 대해 귀찮게 될 필요가 없게 해야 한다.
8.2 하드웨어와 소프트웨어내의 시계
개인용 컴퓨터는 하드웨어 내부의 시계를 동작시키는 시계를 가지고 있다. 배터리는 심지어 컴퓨터에 전기가 들어오지 않는 동안에도 시계가 동작하도록 한다. 하드웨어 시계는 BIOS 셋업화면이나 어떤 OS에서든지 시간을 맞출 수 있도록 작동한다. 리눅스 커널은 하드웨어 시계로부터 독립적인 시간을 따른다. 부팅하는 동안 리눅스는 하드웨어 시간처럼 같은 시간으로써 자신의 시간을 맞춘다. 이런 후에 똑같은 시계는 독립적으로 동작한다.
리눅스는 하드웨어 시계를 따르는 것이 느리고 또한 복잡해지므로 자신의 시계를 운영한다. 커널 시계는 항상 국제 시간을 보여준다. 이런 방식으로, 커널은 Timse Zone을 전혀 알 필요가 없다. 이것은 높은 신뢰성에 인한 간단한 결과이고 또한 Time Zone 정보를 갱신하기도 쉽다. 각각의 과정은 Time Zone변화 그 자체가 다루어진다. (Time Zone 팩키지의 일반적인 tools을 이용)
하드웨어 시계는 지역시간이나 국제 시간이 될 수 있다. 리눅스는 일반적으로 국제 시간을 갖기에 더 낳다. 왜냐하면 당신은 'daylight saving time'때 혹은 UTC가 DST를 갖지 않을 때 당신의 하드웨어 시계를 바꿀 필요가 없기 때문이다. 불행히도 몇몇 PC용 OS (MS-DOS, 윈도우, OS/2등) 는 틀림없이 하드웨어 시계가 지역시간을 보여줄 것이다. 리눅스는 지역시간과 국제시간 모두를 다룰 수 있다. 그러나 만일 하드웨어 시계가 지역시간을 보여준다면 그것은 'DAYLIGHT SAVING TIME'이나 utc가 dst를 갖지 않을 때인 'ENDS'에 시간은 바뀌어져야 한다.
8.3 화면 표시와 시간 맞추기
데비안 Linux시스템에서 time zone은 'Symbolic link'에 의해 결정되어진다. 이러한 time zone자료화링에서 link는 지역 시간을 가리킨다. time zone자료파링은 /usr/lib/zoneinfo에 저장되어있다. 다른 리눅스 배포판은 이것과 다르다.
사용자는 time zone환경변수의 설정에 의해 그의 개인적인 time zone을 변화시켜야 한다. 만일 이것이 설정되어 있지 않으면, 시스템 시계를 사용한다. time zone변수의 구문은 time zone set(3)메뉴얼에 서술되어져 있다.
Date 명령어는 현재 날짜와 시간을 보여준다. 예제 :
$ date
Sun Jul 14 21:53:41 EET DST 1996
$
1996년 7월의 14번째 일용일의 저녁 10시 이전인 10시경을 time zone에서는 'EET DST'라 부른다. (이것은 동유럽의 Daylight Savings Time이다.) Date 명령어는 또한 국제 시간( Universal Time)도 보여준다.
$ date -u
Sun Jul 14 18:53:42 UTC 1996
$
Date 명령어는 또한 커널의 프로그램 시계를 설정하는데로 이용된다.
# date 07142157
Sun Jul 14 21:57:00 EET DST 1996
# date
Sun Jul 14 21:57:02 EET DST 1996
#
date 명령어 매뉴얼을 더 자세히 보면 date 명령어 구문은 bit의 조화이다. 단지 root 만이 시간을 설정할 수 있다. 각각의 사용자가 그 자신의 time zone을 갖고 있지만 시계는 모든 사람에게 동일한 것이다.
date 명령어는 단지 프로그램 시계를 보여주거나 맞추는 것이다. clock 명령어는 하드웨어와 프로그램 시계를 동시에 표시한다. 이것은 하드웨어 시계를 읽어들이고 프로그램 시계를 맞추기 위하여 사용된다. 만일 여러분이 이들 시계를 모두 맞추기 위해서는 먼저 프로그램 시계를 date 명령어로 맞추고, 그 다으머에 하드웨어 시계를 clock -w 명령어로 맞추어야 한다.
clock 명령어에서 -U 스위치는 하드웨어 시계가 국제 시간을 말해주는 것이다. 여러분은 -U 스위치를 정확하게 사용해야 한다. 그렇지 않으면 당신의 computer는 몇시인지 대해 꽤 혼란스러워 진다.
시계는 조심스럽게 바뀌어져야 한다. Unix System에서는 시계가 정확히 작동하기를 요구한다. 예를 들어 cron 데몬은 주기적으로 명령어를 실행한다. 만약 여러분이 시계를 바꾸면 cron은 명령어를 수행해야 될지 말아야 될지에 대해 혼란스러워 한다. 한 초기의 Unix System에서 시계를 20년 미래로 맞추었다. 그러자 crom은 20년동안 모든 주기 명령어를 수정하기 위해 즉시 모든 명령어를 수행해 버렸다. 현재 버전의 cron은 이렇게 하지 않고 정확하다. 그러나 여러분은 여전히 조심해야 한다. 시간을 크게 건너뛰거나 뒤로 건너뛰면 작게 한 혹은 하나 앞으로 간 것보다 더 위험하다.
8.4 시계가 잘못됐을 때
리눅스 프로그램 시계는 항상 정확하진 않다. 이것은 PC 하드웨어의 주기적 timer interrupt에서 생성되어지는대로 따라서 작동한다. 만일 시스템이 어욱 많은 processes rk 수행되면 이것은 timer interrupt를 데공하기에 너무 길어지는 것이 생긴다. 그리고 프로그램 시계가 Slipping이전에 시작되어도 너무 길어지게 된다. 하드웨어 시계는 독립적으로 작동한다. 그래서 하드웨어 시계가 일반적으로 더 정확한다. 만일 여러분이 Computer를 자주 부팅한다면 (서버가 아닌 대부분의 경우처럼), 그것은 일반적으로 정확한 시계를 공정히 지킨다.
만일 당신이 하드웨어 시계를 맞출 필요가 있다면 그것은 일반적으로 재부팅하기에 가장 간단하다. BIOS Setup화면으로 가서 거기서 그것을 하면 된다. 이것은 시스템 시간을 바꿈으로 발생할 수 있는 모든 문제를 피하는 것이다. 만일 옵션이 아닌 BIOS를 경유해서 맞춘다면 새로운 시간을 date나 clock으로 맞춰라. 그러나 재부팅이 준비되어야 한다. 그렇지않으면 시스템의 몇몇 부분에서 웃기는 일이 벌어진다.
Network으로 연결된 컴퓨터는 다른 컴퓨터의 시간과 비교를 통해 그 자신이 자동으로 자신의 시계를 점검한다. 만일 다른 컴퓨터가 매우 정확한 시간을 따르는 것이 알려지면 양쪽 검퓨터가 둘이 정확한 시간을 따르게 된다. 이것은 rdate와 netdate명령을 사용하므로 수행될 수 있다. 이들 명령어로 remote컴퓨터를 검사할 때와 local 컴퓨터를 검사할 때 이들명령어를 일정하게 실행시킴으로 여러분의 컴퓨터는 remote 컴퓨터처럼 정확하게 동작할 것이다.
Appendix A. Holes 측정하기
이 Appendix는 파일시스템에서 holes의 잠재를 측정하는데 상툥되는 프로그램의 흥미있는 부분을 담고 있다. 책의 소스 배포는 전체 소스들을 달고 있다(sag/measure-holes/measure-holes.c).
int process(FILE *f, char *filename){
static char *buf = NULL;
static long prev_block_size = -1;
long zeroes;
char *p;
if ( buf == NULL || prev_block_size != block_size ){
free(buf);
buf = rmalloc(block_size + 1);
buf[block_size] = 1;
prev_block_size = block_size;
}
zeroes = 0;
while ( fread(buf, block_size, 1, f) == 1) {
for (p=buf; *p == '\0'; )
++p;
if (p==buf+block_size)
zeroes += block_size;
}
if(zeroes > 0)
printf("%ld %s\n", zeroes, filename);
if(ferror(f)){
errormsg(0, -1, "read failed for '%s'", filename);
return -1;
}
return 0;
}
Appendix B. 용어 ( 초안 )
The librarian of the Unseen University
bad unilaterally decided to aid comprehension
by producing on Orang-utan/Human Dictionary.
He'd been working on it for three months.
It wasn't easy. He'd got as far as 'Oook.'
(Terry Pratchett, "Men Al Arms")
이것은 리눅스와 시스템 관리자에게 관계된 짧은 이스트의 단어로 된 개념정의이다.
- application program(p.6)
유용한 프로그램 application program 프로그램의 사용 때문에 컴퓨터를 사야한다. 또한 Systemp program이나 Operation System에게 결과를 준다. - daemon
뒤에 숨어있는 프로세스로 그것을 작동시키기 위해 어떤 것을 유발시킬 때까지 일반적으로 알아채지 못하는 것. 예를 들어 Update 때몬은 매3초마다 일어난다. 버퍼 캐쉬도 왈칵 The아져 흘러내리는 것으로 sendmail daemon은 어떤 사람이 메일을 보낼 때마다 발생한다. - file systemp
DOS 에서의 방식과 자료처리로 디스크나 파티션에서 파일을 따라 사용된다. 이런 방식으로 파일은 디스트에서 조직화된다. 또한 디스크나 파티션에서는 파일이나 파일시스템의 형태로 사용된다. - Glossary
해야 할 섯의 말의 나열이나 설명, 사전의 말의 나열이나 설명이 혼란스럽지 않는, - kernel(p.6)
O.S 의 부분으로 하드웨어와 리소스의 공유로 상호작요의 도구, System program을 보세요. - Operating System
여러장치들과 그들이 Application program을 실행시킬 때 그들 사이에 컴퓨터 시스템 리소스를 분배하는 프로그램. 보안을 제공하기 위해 시스템에서 접근을 조절한다. kernel, systemp program, application program을 보세요. - System Call (p.6)
커널에 의해 application program에서 제공되는 service로 같은 방식 으로 그들이 불려진다. section 2의 매뉴얼 pages를 보세요. - system program (p.6)
높은 수준의 O.S를 보충하는 program, I, e.., 하드웨어에 곧바로 의존하지 않는 것으로 실행을 위해 가끔 특별한 권리가 요구되나, 일반적으로는 systemm의 부분처럼 여겨진다. application progra, kernel, operating system을 보세요.
한국어 번역판 부록 A
Second Extended Filesystem의 구현과 설계
Design and Implementation of the Second Extended Filesystem
서론
리눅스는 유닉스 계열의 O/S로 PC-386에서 동작한다. 이것은 처음에 미닉스(Minix)의 확장으로 구현되었고 처음 버전은 미닉스 화일 시스템만 지원했다. 미닉스 화일 시스템은 두 가지의 심각한 제한점을 가지고 있었는데, 첫째 블럭 주소가 16비트 정수형으로 저장되므로 최대 화일 시스템의 크기가 64메가 바이트로 제한되었고, 둘째 디렉토리는 고정된 크기의 엔트리를 가짐으로써 최대 화일 이름의 길이가 14자로 제한되었다.
우리는 표준 리눅스 커널에 포함된 두 가지 새로운 화일 시스템을 디자인하고 구현하였다. 이것은 Extended Filesystem(extfs)과 Second Extended Filesystem(ext2fs)으로 미닉스의 한계를 극복하고 새로운 모습을 추가하였다.
우리는 이 글에서 리눅스 화일 시스템의 역사를 기술하고 유닉스 화일시스템에서 구현된 기본적인 개념을 간략히 소개하도록 하고 리눅스에서 가상 화일시스템 계층의 구현과 ext2fs,커널 코드, 사용자 모드 툴(tools)들에 대해 다룰 것이다. 마지막으로 리눅스와 BSD 화일시스템의 성능 측정결과와 앞으로의 방향에 대한 정보를 제공할 것이다.
1 화일시스템의 역사
아주 옛적에 리눅스는 미닉스 하에서 개발되었다. 두 화일 시스템간에 디스크를 공유하는 것이 새로운 화일시스템의 설계보다 쉬웠기 때문에 Linuz Torvalds는 리눅스에서 미닉스 화일시스템을 지원하도록 설계할 것을 결정하였다. 미닉스 화일시스템은 효율적이고 비교적 버그가 없었다. 그러나 미닉스 화일시스템의 제한점을 극복하려고 사람들은 새로운 화일 시스템을 구현하려고 시도하였다.
새로운 화일시스템을 리눅스 커널에 추가하기 쉽게 하기 위해, 가상 화일시스템(VFS) 계층이 개발되었다. VFS는 처음에 Chris Provenzano에 의해 쓰여 지고 리눅스 커널에 통합되기 전에 Linuz Torvalds에 의해 다시 쓰여졌다. 이것은 3절에서 자세히 다룰 것이다.
VFS가 리눅스에 추가된 후 소위 Extended fs가 1992년 4월에 구현되었고 리눅스 0.96c에 추가 되었다. 이 새로운 화일시스템은 미닉스의 두 가지 제한점을 제거하였다. 즉 최대 화일시스템 크기가 2기가 바이트로 늘어나고 최대 화일 이름 길이가 255자로 늘어났다. 이것은 미닉스를 능가하는 것이었지만 아직도 문제점은 남아 있었다. 개별적 접근, inode 수정, 자료 수정 timestaps에 대한 지원이 없었다. 또한 Free block과 inode를 추적하기 위해 링크드 리스트를 사용함으로써 성능이 나빠졌다. 이런 리스트들이 정렬되지 않고 화일시스템이 분할되었다. 이에 대한 해결책으로 1993년 1월에 새로운 두가지 화일 시스템이 알파 버전으로 발표되었다. xia fs와 second extended fs이 그것이다.
xia fs는 미닉스에 바탕을 두고 새로운 형태를 추가하였고 긴 화일명, 큰 파티션, 3 timestaps를 지원하고 ext2fs는 extfs에 기본을 두고 많은 개선을 하였다. 즉 앞으로의 확장을 염두에 두고 개선을 위한 공간을 고려하였다. 이것은 4절에서 다룰 것이다.
두 화일 시스템이 처음 발표되었을 때 그들은 본질적으로 같은 기능을 제공하였다. 최소한의 변경으로 디자인된 xia fs가 보다 안정적이었다. 하지만 ext2fs가 널리 사용되어짐에 따라 버그도 고쳐지고 새로운 모습이 많이 추가 되었기 때문에 지금은 매우 안정적이고 사실상 리눅스 화일 시스템의 표준이 되었다.
2. 화일 시스템의 기본 개념
모든 리눅스 화일시스템은 유닉스에서 도입된 기본 개념들의 집합으로 구현된다. 즉, 화일은 inode로 표현되고 디렉토리는 엔트리 목록을 담고 있는 화일이며 디바이스들은 특정화일에 대한 I/O 신청으로 처리될 수 있다는 것이다.
2.1 inodes
각 화일은 inode로 불리는 구조체로 표현된다. 각 inode는 화일의 특성을 기술하고 화일 형식, 소유자, timestamps, 크기, 자료 블럭에 대한 포인터등을 담고 있다. 화일에 할당된 data block 에 대한 주소는 자신의 inode에 저장된다. 사용자가 특정 화일에 대한 I/O 요청을 하면, 커널은 현재 오프셋을 블럭 번호로 바꾸고 이 번호를 블럭 주소 테이블의 인덱스로 사용하여 실제 물리 블럭을 읽거나 쓴다.
2.2 디렉토리
디렉토리는 계층 트리구조를 이룬다. 각 디렉토리는 화일들과 서브 디렉토리를 포함할 수 있다. 디렉토리들은 특별한 형태의 화일들로 구현된다. 실제로 디렉토리는 엔트리의 리스트를 가진 화일이다. 각 엔트리는 inode번호와 화일이름을 가지고 있다.
한 프로세스가 패스 명을 사용하면 커널은 해당 inode번호를 찾기 위해 디렉토리를 검색한다. 이름이 inode번호로 변환된 뒤 inode는 메모리에 로드되고 뒤따르는 요청에 따라 사용된다.
2.3 Links
유닉스 화일시스템은 링크의 개념을 사용한다. 여러 이름들이 inode에 의해 연관되어질 수 있다. inode는 화일과 연관된 번호를 가진 필드를 가지고 있다. 링크를 추가하는 것은 디렉토리 엔트리를 만들고 inode번호는 새로운 inode를 가리키고 링크 카운트를 증가 시킨다. 링크를 제거하면 커널은 링크 카운트를 감소하고 이것이 0이면 inode의 메모리를 해제한다. 이것은 하드 링크(Hard link)라 불리는 것으로 한 개의 화일 시스템 내에서만 쓸 수 있다. 다른 화일시스템과의 하드 링크를 만들 수 없다. 더구나 하드 링크는 화일를 가리키는 데에만 쓰일 수 있다. 그러므로 디렉토리 하드 링크는 디렉토리 트리의 사이클이 생기는 것을 방지하는데 쓰일 수 없다.
최근 유닉스 화일 시스템에는 또 다른 형태의 링크가 존재한다. 심볼릭 링크는 단순히 화일 이름을 가지는 화일이다. 커널이 패스명을 inode로 변환 중 심볼릭 링크를 만나면 링크의 이름을 목적 화일 이름으로 대체한 후 패스명의 해석을 다시 시작한다. 심볼릭 링크는 inode를 가리키지 않기 때문에 다른 화일 시스템과의 링크가 가능하다. 또한 어떤 형태의 화일도 기리 킬 수 있고 심지어 존재하지 않는 화일도 가능하다.
이것은 하드 링크의 한계를 가지고 있지 않으므로 매우 유용하다. 그러나 커널이 심볼릭 링크를 만나면 새로 해석을 다시 시작하므로 패스명을 inode로 변환하는데 오버헤드가 있고 기억 공간이 낭비된다.
2.4 특수 디바이스 화일
유닉스 계열의 O/S에서는 디바이스는 특수 화일에 의해 처리된다. 특수 디바이스 화일는 화일 시스템 상에서 기억 공간을 차지 하지 않고 단지 디바이스에 대한 처리 포인트로 쓰인다. 두 가지의 특수 화일이 있다. 문자 화일은 문자 모드에서 I/O동작을 가능하게 하고, 블록 화일은 버퍼 캐쉬 함수에서 데이타를 블럭 단위로 쓸 때 사용된다. 특수 화일에 대한 I/O요청이 생기면 이것은 디바이스 드라이버로 간주된다. 특수 화일은 디바이스 타입을 나타내는 Major number와 unit을 나타내는 Minor number에 의해 참조된다.
3. 가상 화일 시스템(Virtual File System)
3.1 원리
리눅스 커널은 화일에 대한 시스템 콜을 할 때 쓰는 VFS를 가지고 있다. VFS는 화일 지향의 시스템 콜을 다루는 간접 계층이고 I/O를 행하는 물리적 화일시스템에서 필요한 함수들을 호출한다. 이런 간접 메카니즘은 유닉스 계열 o/s에서 여러 화일시스템의 사용과 통합을 쉽게 하기 위해 종종 사용된다.
프로세스가 화일에 대한 시스템 콜을 하면 커널은 VFS안에 있는 함수를 호출한다. 이 함수는 구조에 비종속적인 조작들을 다루고 구조 종속적인 동작을 담당하는 물리적 화일 시스템에 포함된 함수로 redirection을 행한다. 화일 시스템은 i/o 디바이스를 요청하기 위한 버퍼 캐쉬 함수를 사용한다.
3.2 VFS 구조
VFS는 모든 화일 시스템이 구현해야 하는 함수의 집합을 정의한다. 이런 인터페이스는 화일 시스템, inodes, 개방 화일 세가지의 연관된 동작의 집합으로 구성된다. VFS는 커널 configuration시 정의된 테이틀을 통해 커널이 지원하는 화일 시스템의 타입을 알고 있다. 이 테이블의 각 엔트리는 화일 시스템의 타입을 기술한다. 즉 화일 시스템 타입명, 마운트될 때 불려지는 함수의 포인터 등등...
화일시스템이 마운트 될 때 적절한 마운트 함수가 불려진다. 이 함수는 디스크로 부터 수퍼블럭을 읽고 내부변수를 초기화하고 마운트된 와일시스팀의 기술자(descriptor)를 VFS로 되돌리는 역할을 한다. 화일시스템이 마운트 된 후 VFS함수는 이 기술자를 문리 화일 시스템 루틴을 처리하는데 쓸 수 있다.
마운트된 화일 시스템 기술자는 몇가지의 정보를 갖게 되는데 모든 화일시스템을 공통된 정보, 물리 화일 커널 코드에 제공되는 함수에 대한 포인터, 물리 화일 시스템에 의해 유지 보수되는 개별 데이타들이 있다. 화일 시스템 기술자내의 함수 포인터는 VFS가 화일 시스템 내부 루틴을 처리하는 것을 가능토록 한다. 두가지 다른 기술자가 VFS에 의해 쓰이는데, inode기술자와 개방 화일 기술자가 그것이다. 각 기술자는 물리 화일 시스템에 의해 제공되는 동작의 집합과 사용에 관계된 화일들의 정보를 가지고 있다. inode기술자가 임의의 화일에 대해 영향을 미치는 함수의 포인터를 가지는 반면 화일 기술자는 개방 화일에 영향을 미치는 함수에 대한 포인터를 가지고 있다.
4. Second Extended File System(ext2fs)
4.1 동기
ext2fs는 처음 extfs의 문제점을 해결하기 위해 설계/구현 되었다. 우리의 목표는 유닉스 화일의 의미(semantics)를 가지는 강력한 화일시스템s의 제공과 진보된 모습을 제공하는데 있다.
물론 우리는 ext2fs가 뛰어는 성능을 갖길 원한다. 또한 격렬한 사용으로 인한 자료 손실을 줄이는 강력한 화일시스템s를 제공하길 원한다. 마지막으로 사용자가 사용중인 화일시스템을 재포맷하지 않고도 새로운 화일시스템의 장점을 얻을 수 있도록 확장에 대한 대비도 포함해야 할 것이다.
4.2 표준 ext2fs
ext2fs는 정규화일, 디렉토리, 특수 디바이스 화일, 심볼릭 링크 등 표준 유닉스 화일 형식을 제공한다. ext2fs는 굉장히 큰 파티션을 다룰 수 있다. 반면 초기 커널은 최대 화일시스템의 크기를 2기가 바이트로 제한하였지만 최근 VFS 계층의 성과로 인해 이 한계를 4테라 바이트로 끌어 올렸다. 그러므로 큰 디스크를 여러 파티션으로 나눌 필요가 없게 되었다.
ext2fs는 긴 화일명을 제공한다. 이것은 가변길이 디렉토리를 사용한다. 최대 화일명 길이는 255자이다. 이 제한은 필요에 따라 1012로 확장될 수 있다.
ext2fs는 몇개의 블럭을 수퍼 유저(root)를 위해 보존한다. 보통 블럭의 5%이다. 이것은 사용자 프로세스가 화일시스템에 꽉 찼을때 관리자가 상황을 쉽게 극복할 수 있도록 한다.
4.3 진보된 ext2fs
표준 유닉스 형식에 이어 ext2fs는 현재 유닉스 fs에서 쓰이지 않는 몇가지 확장들을 제공한다.
화일 속성들은 사용자들이 화일에 대한 커널의 처리 방식을 수정할 수 있도록 한다. 사용자는 화일과 디렉토리에 속성을 줄 수 있으며 디렉토리의 경우 새로 생긴 화일이 디렉토리의 속성을 상속하도록 할 수 있다.
BSD나 System V R4의 의미는 마운트시에 선택될 수 있다. 마운트 옵션은 관리자가 화일 생성의 의미를 선택할 수 있게 한다. BSD에서 화일들은 부모 디렉토리와 같은 그룹 id를 갖도록 생성된다. System V는 좀 더 복잡한데 만약 디렉토리의 setgid 비트가 세트되어 있으면 새로운 화일은 디렉토리그룹 id로 서브 디렉토리는 그룹 id와 setgid 비트를 상속 받는다. 그렇지 않으면 화일과 서브 디렉토리는 호출 프로세스의 그룹 id를 가지고 생성된다.
ext2fs에서는 BSD 같은 동시 갱신 방법이 쓰인다. 마운트 옵션은 관리자가 metdata(inode, bmp blocks, indirect blocks, directory block)가 수정될 때 디스크에 동시에 쓰여지도록 요청할 수 있게 한다. 이것은 metdata의 견고함을 유지하는데 효율적이지만 성능이 나빠진다. 사실상 이것은 보통의 경우 쓰이지 않는다. 왜냐하면 성능 저하와 함께 fs checker에 의해 표시되지 않는 사용자의 자료의 손상을 유발할 수 있다.
ext2fs는 관리자가 fs를 만들때 논리적 블럭의 크기를 선택할 수 있게 한다. 블럭 크기는 보통 1024, 2048, 4096 바이트이다. 큰 블럭 크기를 사용하면 i/o요청이 작아지므로 속도를 높일 수 있다.(화일 처리를 위한 seek time이 줄어들므로) 반면 이것은 디스크의 낭비를 가져올 수 있다. 평균적으로 마지막으로 화일에 할당된 블럭은 반밖에 차지 않는다. 그러므로 블럭 크기가 커지면 공간의 낭비가 심해진다. 게다가 큰 블럭 크기로 얻어지는 잇점은 ext2fs의 preallocation 기술로 해결할 수 있다.
ext2fs는 빠른 심볼릭 링크를 구현한다. 빠른 심볼릭 링크는 fs의 데이타 블럭을 사용하지 않는다. 목적 이름은 데이타 블럭에 저장되지 않고 inode만 저장된다. 이 전략은 약간의 디스크 공간을 절약하고 링크 동작 속도를 높인다. 물론 inode의 가용공간이 제한되므로 모든 링크에 대해 빠른 심볼릭 링크가 되는 것은 아니다. 이를 위한 최대 목적 이름의 크기는 60자이다. 우리는 이 구조를 가까운 미래에 작은 화일들로 확장할 계획이다.
ext2fs는 fs의 상태를 보존한다. 커널에 의해 쓰이는 수퍼 블럭의 특정필드가 fs의 상태를 나타낸다. fs가 read/write모드로 마운트 되면 상태는 "Not Clean"으로 세트된다. 언마운트되거나 다시 마운트 되면 상태는 "Clean"이 된다. 부트시에 fs checker는 이 정보를 fs가 체크되어야 하는지 결정하는데 쓴다. 커널은 이 필드에 에러를 기록한다. 에러가 있으면 fs는 "Erroneous"로 표시되고 fs checker는 Clean상태일 지라도 강제로 테스트를 한다.
항상 fs를 체크하지 않는 것은 위험하므로 ext2fs는 일정간격으로 강제로 체크하는 것을 두가지 형태로 행한다. 마운트 계수는 수퍼 블럭안에서 유지된다. fs가 read/write모드로 마운트될 때마다 계수가 증가한다. 이것이 최대치가 되면 fs checker는 강제로 테스트를 행한다. 마지막 체크 시간과 최대 마운트 계수는 수퍼 블럭에 유지된다. 이 두 필드는 관리자가 주기적은 fs 체크를 가능하게 한다. 최대 체크 시간 간격이 되면 checker는 fs의 상태와 무관하게 테스트를 행한다.
ext2fs는 화일시스템(fs)의 행동을 조율(tune)하기 위한 툴들을 제공한다. tune2fs로 아래와 같은 사항을 수정할 수 있다.
- Error behavior : 에러 발생시 그냥 계속할 것인지, 읽기/쓰기 모드로 다시 마운트할지, checker를 실행하기 위해 다시 부팅할지를 결정한다.
- 최대 마운트 계수
- 최대 체크 간격
- 수퍼 블럭 유저를 위한 논리 블럭 할당 크기
마운트 옵션 또한 커널 error behavior를 변경하는데 쓸 수 있다.
속성들 중 사용자가 보안삭제를 요청할 수 있게 한다. 이런 화일이 삭제되면 할당되었던 화일에 임의의 데이타를 덮어쓴다. 이것은 지워진 화일에 대한 부당한 접근을 막을수 있다.
마지막으로 4.4 BSD에서 영향을 받은 새로운 형태의 화일이 최근에 ext2fs에 추가되었다. Immutable 화일은 읽을수 만 있고 아무도 다시 쓰거나 지울 수 없다. 이것은 민감한 config화일을 보호하는데 쓰인다. Append-only화일은 쓰기 모드로 개방되지만 데이타는 항상 화일 끝에 추가되며 삭제되거나 새로운 이름을 부여할 수 없다. 이것은 로그 화일에 유용하게 쓰일수 있다.
4.4 물리적 구조
ext2fs의 물리 구조는 BSD fs에서 지대한 영향을 받았다. fs는 블럭 그룹으로 구성되고 블럭 그룹은 BSD FFS의 실린더 그룹과 유사하다. 그러나 현대의 디바이스들이 순차 처리에 최적화 되고 물리적 구조를 숨기는 경향이 있으므로 플럭그룹은 디스크상의 물리적 계층으로 묶이지 않는다.
각 블럭 그룹은 중요 제어 정보(수퍼블럭, fs 기술자)의 여분의 복사 본을 가지고 있고 fs의 일부분(block bitmap, inode bitmap...)을 가지고 있다. 블럭 그룹의 사용은 신뢰성이라는 관점에서 크나큰 성과이다. 제어구조는 각 블럭 그룹에 복사되므로 수퍼 블럭 손상시 복구가 용이하다. 이 구조는 성능향상에도 도움을 준다. inode 테이블과 데이타 블럭 구조사이의 거리를 줄임으로써 i/o시 헤드 seek time을 줄인다.
ext2fs내에서 디렉토리는 가변길이 엔트리들의 링크드 리스트로 구현된다. 각 엔트리는 inode 번호등의 정보를 갖는다. 이런 가변 길이 엔트리의 사용으로 디스크 공간의 낭비없이 긴 화일 이름의 구현이 가능하다.
4.5 성능 최적화
ext2fs 커널 코드는 화일을 읽고 쓸때 i/o 속도를 향상시키는 여러 성능 최적화 기능을 가진다. ext2fs는 readahead를 수행함으로써 버퍼 캐쉬 관리에서 장점을 얻는다. readahead란 블럭이 읽힐 때 커널 코드는 여러 연속된 블럭의 i/o를 요청한다. 이렇게 해서 다음에 읽을 블럭이 이미 버퍼 캐쉬에 로드되도록 하려고 한다. readahead는 보통 순차적인 읽기를 하는 동안 실행되며 ext2fs는 이것을 디렉토리 읽기, 명시적인 읽기, 암시적인 읽기로 확장한다.
ext2fs는 또한 많은 할당 최적화 기능을 갖는다. 블럭 그룹은 연관있는 inode와 데이타의 군집화에 쓰인다. 커널 코드는 같은 그룹의 화일들이 같은 inode를 갖도록 할당하려고 한다. 이것은 커널이 inode와 데이타 블럭을 읽을 때 head seek를 줄이는 역할을 한다.
데이타를 쓸 때 새로운 블럭을 할당해야 할 때 ext2fs는 최대 8개의 인접한 블럭을 pewallocate한다. preallocation hit rare는 꽉 찬 fs에서 조차도 약 75%이다. 이것은 과부하시 좋은 성능을 보인다. 또한 화일에 연속된 블럭을 할당시켜 미래의 순차 읽기시에 속도향상을 꾀한다.
이런 할당 최적화는 다음과 같은 매운 좋은 지역성(Locality)을 발생시킨다.
- 블럭 그룹을 통한 연관된 화일
- 블럭 할당의 8비트 클러스터링을 통한 연관된 블럭
5. ext2fs 라이브러리
사용자 모드 프로그램이 ext2fs의 구조를 제어할 수 있도록 하기 위해 libext2fs가 개발되었다. 이 라이브러리는 직접적인 물리 디바이스를 통한 처리를 통해 ext2fs의 데이타를 수정 검색할 수 있도록 하는 루틴을 제공한다.
ext2fs 라이브러리는 추상화 기법을 사용하여 최대의 코드 재사용을 할 수 있게 디자인되었다. 예를 들어 여러 다른 반복자(iterator)가 제공된다. 프로그램은 단순히 inode에서 각 블럭을 호출할 수 있는 ext2fs_block_iterate()를 함수적으로 간단히 전달할 수 있다. 또다른 반복자 함수는 디렉토리내에서 각 화일을 호출할 수 있는 사용자 제공 함수의 사용을 허용한다. 많은 ext2fs 유틸리티들(mke2fs, e2fsck, tunee2fs, dumpe2fs, 그리고 debugfs)은 ext2fs 라이브러리를 사용한다. 이것은 이런 유틸리티의 유지보수를 굉장히 간단히 만드는데 이것은 ext2fs 화일 시스템 형식에서 새로운 모습을 반영하는 어떤 변화도 한곳에서 이루어지고 되는데 이것이 바로 ext2fs 라이브러리이다. ext2fs 라이브러리는 공유 라이브러리 이미지로 이루어졌기 때문에 이 코드는 비교적 작은 이진 화일로 재사용된다.
ext2fs 라이브러리의 인터페이스는 굉장히 추상적이고 일반적이기 때문에, ext2fs 화일시스템을 직접 처리해야 하는 새로운 프로그램은 굉장히 쉽게 쓰여질 수 있다. 예를 들어 ext2fs 라이브러리는 4.4BSD 덤프나 백업을 푸는 유틸리티를 포팅하는 동안 쓰이는데 이 툴들을 리눅스에 사용하기 위해서는 아주 작은 변화만 있으면 된다. 즉 단지 함수에 종속적인 몇몇 화일시스템만 ext2fs 라이브러리를 호출하도록 바꾸면 된다.
ext2fs 라이브러리는 동작의 여러 처리 계층을 제공한다. 첫 번째 계층은 화일 시스템 지향적인 동작으로 프로그램은 화일 시스템을 열고 닫을 수 있고, 비트맵을 읽고 쓸 수 있으며, 디스크 상에 새로운 화일시스템을 만들 수 있다. 화일 시스템상의 bad block 리스트를 조작하는 함수의 호출도 가능하다.
두 번째 계층은 디렉토리에 영향을 미친다. ext2fs 라이브러리 호출 자는 디렉토리를 만들고 확장할 수 있으며 엔트리를 추가 삭제할 수 있다.
inode 번호에 대한 패스 명을 결정하는 함수와 번호가 주어진 inode에 대한 패스명을 결정할 수 있는 함수를 제공한다.
마지막 계층은 inode 주변에 관계되는데 inode 테이블을 검색하고 inode를 읽고 쓰고 inode의 모든 블럭을 검색할 수 있게 해준다. 할당과 회수 루틴도 가능하고 사용자 모드 프로그램에서 블럭과 inode의 할당과 제거도 가능하게 한다.
6. Ext2fs tools
ext2fs에는 강력한 유지보수용 툴들이 있다. 이 유틸리티는 ext2fs의 생성, 수정, 에러 복구등에 사용된다. mke2fs는 파티션을 빈 ext2fs로 초기화 시킨다.
tune2fs는 fs의 파라미터를 조정하는데 쓰인다. 4.3절에서 설명대로 error behavior와 최대 마운트 계수, 최대 체크 간격, 수퍼 유저를 위한 논리블럭의 예약 갯수 등을 바꿀 수 있다. 그 중 가장 흥미있는 것은 화일 시스템 검사기(fs checker)이다. e2fsck는 시스템의 완전하지 못한 셧다운 후 화일 시스템의 에러를 복구하도록 한다. e2fsck의 초기버전은 미닉스를 위한 Linuz Torvald의 프로그램에 바탕을 두었지만 최근 버전은 ext2fs 라이브러리를 사용 다시 쓰여졌다. 그래서 초기 버전보다 훨씬 빠르게 동작한다.
e2fsck는 최대한 신속히 동작하도록 설계되었다. 화일 시스템 검사기는 디스크-바운드되는 경향이 있다. 이것은 e2fsck에 의해 최적화 알고리즘을 씀으로서 극복이 가능하다. 게다가 검사될 inode와 디렉토리의 순서가 블럭번호로 정렬됨으로써 디스크 검색 시간을 줄일 수 있다.
패스 1에서 e2fsck는 화일 시스템내의 모든 inode에 대해 반복적으로 각 inode에 대해 연결되지 않은 객체가 있는지 검사한다. 이 검사는 다른 화일 시스템 객체에 대한 검사(cross-check)를 하지 않는다. 이런 검사의 예로써 화일 모드가 적당한지 inode의 모든 블럭이 타당한 블럭 번호를 갖는지 등이다. 패스 1 동안 어떤 블럭과 inode가 사용중인지 나타내는 비트맵(bitmap)이 컴파일 된다.
만약 e2fsck가 데이타 블럭이 하나 이상의 inode에 연결되면 패스 1B에서 1D동안 이 문제를 해결하거나 공유블럭의 복사본을 가지게 되거나 inode의 할당을 해제 시킨다.
패스 1은 실행시간이 가장 길다. 왜냐하면 모든 inode가 메모리에 읽혀지고 검사되기 때문이다. 다음 패스의 I/O시간을 줄이기 위해 중요한 정보는 메모리에 캐쉬된다.
이 기술의 가장 중요한 예제는 화일 시스템의 모든 디렉토리 블럭의 위치이다. 이것은 패스 2에서 이러한 정보를 얻기 위해 디렉토리 inode구조를 다시 읽어야 하는 필요를 없애준다.
패스 2에서는 연결이 끊어진 디렉토리를 검사한다. 디렉토리 엔트리는 디스크 블럭에 퍼져 있지 않으므로 다른 블럭을 참조하지 않고도 독립적으로 검사가 가능하다. 이것은 e2fsck가 디렉토리 블럭을 블럭번호로 정렬시킬수 있도록 해주고 오름차순으로 디렉토리 블럭을 검사한다. 그럼으로써 디스크 검색 시간을 줄일 수 있다. 디렉토리 블럭은 엔트리가 타당한지 사용중인 inode번호를 참조하는지 여부로 검사된다.
각 디렉토리 inode의 디렉토리 블럭 중 가장 먼저 '.', '..' 엔트리가 존재하는지 사한다. '.' 엔트리의 inode번호가 현 디렉토리에 적합한 것인지 검사한다. ('..' 엔트리의 inode번호는 패스 3에서 검사된다.)
패스 2에서는 또한 각 디렉토리에 링크된 부모 디렉토리에 대한 정보를 캐쉬한다. (만약 어떤 디렉토리가 한개의 디렉토리 이상에서 참조되면, 두번째로 참조한 디렉토리는 적당하지 못한 hard link로 간주되고 제거된다.)
패스 2의 마지막 부분에서 거의 모든 디스크 I/O가 수행된다는 것은 주목할 만한 가치가 있다. 패스 3, 4, 5에서 필요한 정보는 메모리에 캐쉬되고 나머지 작업은 대부분 CPU-bound된다. 이것은 e2fsck의 총 작업량의 5-10%밖에 되지 않는다.
패스 3에서 디렉토리의 연결성이 검사된다. e2fsck는 패스 2에서 캐쉬된 정보를 가지고 각 디렉토리의 뒤에서 루트로 각 패스를 추적한다. 이때 각 디렉토리의 '..' 엔트리가 타당한 것인지 검사한다. 이 추적이 실패한 피렉토리는 /lost+found 디렉토리에 링크된다.
패스 4에서는 패스 2,3에서 계산된 내부 계수와 비교하면서 모든 inode와 링크 계수를 반복적으로 비교를 함으로써 모든 inode의 참조 계수를 검사한다. 0의 링크 계수를 가지면서 지워지지 않은 화일은 /lost+found에 링크된다.
마지막으로 패스 5에서는 e2fsck는 화일 시스템의 요약 점보를 가지고 타당성을 검사한다. 실제 화일 시스템의 비트맵과 이전 패스에서 생성된 블럭, inode 비트맵을 비교 검사한다. 필요에 따라 디스크 상의 복사가 이루어 진다.
화일 시스템 디버거 또한 유용한 툴이다. debugfs는 화일 시스템의 상태를 조사하고 변경시키는 매우 강력한 프로그램이다. 기본적으로 ext2fs 라이브러리의 반복적인 인터페이스를 보여준다. 다시 말하면 사용자가 명령을 키인하면 라이브러리 루틴을 호출할 수 있다.
debugfs는 화일 시스템의 내부구조를 검사하거나 파괴된 화일 시스템을 복구하거나 e2fsck를 위한 검사 예제를 만들 때 쓰인다. 불행하게도 사용자가 자신이 무얼해야 할지 모르고 사용하면 매우 위험하다. 즉 이것으로 화일 시스템을 파괴하는 것은 매우 쉽다는 것이다. 이런 이유로 debugfs는 디폴트로 화일 시스템을 읽기 전용으로 개방한다. 사용자는 읽기/쓰기 모드로 개방하기 위해서는 -w 플래그를 명시적으로 표시해 주어야 한다.
7. 성능 평가
(생략)
8. 결론
ext2fs는 리눅스에서 가장 널리 쓰이는 화일 시스템이다. 이것은 표준 유닉스의 의미와 보다 향상된 모습을 동시에 제공한다. 게다가 커널 코드에 포함된 최적화 알고리즘 덕분에 굉장히 견고하고 뛰어난 성능을 제공한다.
ext2fs는 발전을 염두에 두고 개발 되었기 때문에 새로운 기능을 포함할 수 있는 환경을 가지고 있다. 어떤 사람들은 현 화일 시스템을 확장하기 위해 일하고 있다. Posix의 처리 제어 리스트, 삭제복구, 화일 압축 등이 그것이다.
ext2fs가 처음 개발 되었을 때는 리눅스 커널에만 통합되었지만 지금은 다른 o/s에도 활발히 적용되고 있다. GNU Hurd에서 동작하는 ext2fs서버가 구현 되었고 Mach microkernel에서 동작하는 LITES 서버와 VSTa o/s에도 동작하도록 하고 있다. 마지막으로 지금 개발 중인 Masix에서도 중요한 역할을 하고 있다.
참고문헌
- [AnV] Peter Anvia, Linux device 목록, 리눅스 장치의 최대와 최소의 장치수의 리스트
- [Cha] Crahar Chapman, Boot disk 사용법, 이용할 수 있는 HOWTO'의 다른 것.
- [Qui 95] Daniel Qainlan, 리눅스 파일 시스템의 구조 - 1,2판 March 1995.
일반적으로 나타나는 makingfile에 의해 리눅스 시스템 관리자와 팩키지 소프트웨어에게서 쉽게 디렉토리 트리를 만들게 하기 위해서 표준 리눅스 디렉토리 tree에 대한 제한과 서술을 함. 전통적인 유닉스 연습에 밀접하게 공정히 따랐고 다수의 리눅스 배포판에 해당된다.
ftp, .funet.if에 의해 FTP에 의하여 이용할 수 있는 것 ; directory /pab/Linux/doc/fssfind - [TV] Stephen Tvreedie와 Alexei Vovenko. 리눅스 파일 시스템 최적화. 전자메일은 ftp://Sunsite.Unc.deu/pab/Linux/System/Filesystems/defrag-06.6.tongs로 이동할 수 있다.
언제함 날 잡아서 정독 해야것다..ㅡ.,ㅡ;;
댓글 없음:
댓글 쓰기