Journaling Filesystem & XFS

글의 원활한 작성을 위해 존칭은 생략합니다..(남들도 그렇게 하더군요 )
이문서로 인해 발생하는 문제에는 책임을 질수가 없습니다.
복구해드릴수도 실력도 없습니다. 각자 알아서 잘 사용하시기 바랍니다..

# Journaling Filesystem 소개

#XFS
http://oss.sgi.com/projects/xfs/
silicon graphics에서 만든 대용량 파일시스템이다.
SGI의 IRIX서버를 위한 파일시스템인데 현재 리눅스용으로 포팅되었다.
기타 여러 저널링 파일시스템도 있지만 개인적으로 IBM의 JFS를 제외하고
모두 사용해봤지만 개인적인 평가에선 가장 높은 점수를 주고싶다.
현재는 리눅스로 포팅되어 kernel 2.4.x를 위한 패치를 제공한다.

#ReiserFS
http://www.namesys.com/

ReiserFS는 작은 파일들이 많은 시스템엔 적당하지만
큰파일들의 이동이 많거나 부하가 많이 걸릴때는 성능저하가 심했다.
(물론 본인서버에서서의 사용에서 말이다.튜닝을 잘못했거나 설정상의 문제일수도 있다. )
독일의 한스 라이져(Hans Reiser)가 만들고 SUSE Linux가 스폰서를 하고있다.
정식 커널 2.4.x에 포함되어있을만큼 충분히 안정화되어있는 저널링 파일시스템이다.

# EXT3
http://people.spoiled.org/jha/ext3-faq.html

예전에 개발되다가 잠시 중단된후 저널링 파일시스템의 필요성을 느낀 Redhat의 후원(?)으로 현재 활기있는

개발이 이루어지고 있다.
현재 2.4.x정식 커널에 들어가있다(물론 베타상태이다.)
EXT3의 가장 매력적인점은 EXT2 <->EXT3변환이 순식간에 그리고 데이타손실없이
이루어진다.(필자는 EXT3파일시스템의 오류로 고생한적이있다.- 물론 설정상의 미스나
오류일수도 있다. )

# JFS
http://oss.software.ibm.com/developerworks/opensource/jfs/index.html

IBM에서 내놓은 파일시스템으로 필자가 써보지 않은 파일시스템이다.
역시 대규모 서버용 파일시스템이다.(OS/2 와 IBM의 서버용 파일시스템인데
현재 리눅스로 포팅되었다.

# XFS사용하기
커널 컴파일에 자신이 없거나 혹은 편리하게(?)사용할 분들은
http://rpmfind.net 에서 kernel로 검색을 하면 sgi에서 배포하는
xfs패치된 2.4.x커널을 받을수있다..
rpm파일들이니 설치후 기존 파일시스템을 xfs로 변경하는부분만 이글을 참고해서
변경후 사용해도 무방하겠다.

경고!!
파일시스템의 변환은 기존파일시스템을 변경하는 중요한 작업이므로 반드시 필요한 지식을
익혀두고 필요한 자료를 받아두고 시작하기 바란다.물론 데이타 백업은 필수다..
리눅스의 하드디스크 파티션이 2개이상(스왑 파티션제외)일때를 가정하고 작업한다.
- 파티션이 하나일때는 데이타를 백업하고 커널에 xfs패치를 한뒤 새커널로 부팅후에(부트 디스켓등으로)
기존파티션을 삭제후에 새로 xfs파티션을 만드는게 더 빠르고 편할수 있다.

ftp://oss.sgi.com/project/xfs 에서 해당커널에 맞는 패치를 다운받는다.
cmd_rpms/i386/디렉토리에서 모든 rpm을 받아서 설치한다(모두 할필요는 없지만 편의상 모두설치한다.)
xfs 파일시스템 작성 및 기타 여러유틸이 포함된 rpm이다.
커널패치를 하기전에 혹시라도 잊어먹을지 모르니 위에서 받은 rpm들을 먼저 설치한다.

xfs파일시스템 최근버전은 1.0.2이지만 커널패치가 2.4.14까지 밖에 없기때문에
beta버전을 받아야 최근커널 패치가 있으니 각자 책임하에 작업하기 바란다.
패치파일이 여러개있는데 readme문서엔 필요한 패치만 하기를 권하고 있다.
하지만 자세한것을 모른다면 xfs-kernel_version-all-i386.bz2를 받아서 커널소스를 푼곳(/usr/src/linux-2.4.x)에넣고 bunzip xfs-kernel_version-all-i386.bz2로 압축을 풀고
patch -p1 < xfs-xfs-kernel_version-all-i386.patch로 커널소스(순수 바닐라 커널소스를 말한다.)
를 패치한다.이제 각자 시스템과 취향에 맞게 make menuconfig , make config , make xconfig등을
해서커널 컴파일메뉴로 들어간다.
Code maturity level options ---> 부분에서
Prompt for development and/or incomplete code/drivers에 체크.

File systems ---> SGI XFS filesystem support에 체크
Enable XFS Realtime support
Enable XFS Quota
Enable XFS DMAPI 부분에는 필요에 따라 체크하거나 해제한다.(해당 부분은 커널컴파일시 해당
옵션의 도움말을 참고하기 바람)

커널을 무사히 컴파일하고 설치했다면 이제 xfs파일시스템으로의 변환을 해야한다.

파티션이 여러개일때는 일단 /var 파티션등의 모든파일을 다른곳에 복사한뒤
컴퓨터를 리부팅하고 부팅시 linux single모드로 부팅해 최소한의 데몬만을 띄운뒤
/var(본인의 경우)파티션을 xfs파일시스템으로 새로 만들어준다.
mkfs -t xfs -f /dev/hdx
-f 명령으로 기존 파일시스템을 강제로 xfs로 포멧한다.모든 데이타는 삭제되니 신중히 실행할것.
새로 포멧한 파티션을 xfs로 마운트를 시도해본다.
mount -t xfs /dev/hdxx /var
문제가 없다면 아무런 메세지가 없을것이다.
/var파티션의 데이타백업본을 다시 /var에 카피한다..

이제 /etc/fstab을 수정.
/dev/hdxx / ext2 defaults 1 1

위의 부분을 위에서 변경한 파티션으로 바꿈..
/dev/hdxx / xfs defaults 1 1

이제 리부팅을 하면 기존의 /var 파티션이 시스템 루트가됨..
이제 다시 원래의 루트파티션에 있는 모든데이타를(/proc디렉토리는 제외) 다른곳에
백업해둔뒤 다시 xfs파일시스템으로 변경

mkfs -t xfs -f /dev/hdx

카피가 끝났으면 반드시 /새파티션/proc디렉토리를 생성해야한다. 그렇지 않으면/proc디렉토리를
마운트 하지 못해 에러를 내고 부팅에 실패하게 된다.
위에서 한 파티션 데이타 복원작업을 반복한다..
첨부파일은 리눅스 커널 2.4.0에 xfs패치가 된 디스크의 이미지이다..
압축파일안에 포함된 문서를 읽어보고 디스크를 만들기 바란다.

첨부파일의 다운로드 주소 - ftp://ftp.astro.umn.edu/pub/users/carde
관련 사이트 - http://www.astro.umn.edu/~carde/

XFS FAQ - http://oss.sgi.com/projects/xfs/faq.html

  1. first4you 2002.03.25 00:06

    잘못된점이나 고칠것이 있으면 알려주시면 감사하겠습니다.
    ^^;
    위 글과 관련 질문은... 당연히 받습니다. :)

    * kernel 2.6 이상은 xfs가 포함되어 있습니다. 별도의 패치는 필요하지 않습니다..

single모드로 들어가거나 혹은 정전등으로 인해
리부팅됐을때는 다음 부팅시 파티션 체크를 하게되는데
조금(?)심각하다고 판단될때는 루트의 패스워드를 물어보고
직접 수정하라고 합니다.
이때는 파티션이 읽기전용으로 마운트 되기때문에
/etc/fstab등의 오류나 오타등으로 인한 문제를 해결하기가
쉽지 않습니다.
이때는 mount의 remount 옵션으로 파티션을 읽기 쓰기모드로
다시 마운트해서 파일을 수정한뒤 리부팅을 하면 해결이 가능합니다.

mount -o remount,rw /dev/hdx
or mount -o remount,rw / (루트파티션 일때)

파일을 수정후엔 파티션을 다시 읽기 전용으로 마운트한뒤
리부팅을 하면 됩니다.
mount의 자세한 옵션은 man mount 하거나
아래링크를 참고하세요.

http://man.kldp.org/man/man8/mount.8.html

관련 링크: http://man.kldp.org/man/man8/mount.8.html

  1. 바다사랑 2002.05.21 01:48

    존 팁 감솸돠~
    꾸벅,,

    바다사랑 드림

  2. first4you 2002.05.21 21:51

    예전에 무지 고생했던거라서요..^^;;

글쓴이 : 최장욱

출처 : http://kltp.kldp.org/stories.php?story=01/11/01/7561951

며칠 전에 약 1주일이 넘도록 힘들게 만들어 놓은 작업 데이타를 어쩌다가(지운 과정도 상당히 복잡하지만 생략) 결국 "rm -rf"로 지워 버리고 말았습니다. 결국 이틀이 걸려 제가 찾으려던 텍스트 화일 두개(크기는 각각 약 8KB, 97KB)를 복구하였습니다. 제가 한 과정을 요약해서 올립니다. (제 피씨는 wow 7.1 파란입니다.)

"적수네 동네"와 kldp.org에서 "rm -rf"로 지운 화일을 복구하는 데에 대해서 검색을 해 봤는데 우선 적수네 동네 질답게시판에서 tct라는 프로그램으로 복구할 수 있다는 말이 있었습니다. 그리고 kldp.org에서는 화일복구에 대한 mini-howto가 있었는데 저는 mini-howto를 쫓아 하다가 거기에 나오는 툴들이 시스템에 안 깔려 있길래 그냥 tct를 사용해서 복구를 했습니다.

tct는 http://www.fish.com/tct 에서 다운받을 수 있습니다. 프로그램의 설명서는 http://www.fish.com/tct/help-recovering-file 이 화일입니다.

제 경우는 홈디렉토리를 지웠습니다. 설명서에 보면 지운 화일이 속한 파티션에 더이상의 쓰기는 하지 말고 umount를 하라고 되어 있습니다. 저의 경우는 홈디렉토리가 루트디렉토리(/)에 있어서 umount를 하지는 못했고, 마침 안 쓰고 있던 파티션이 있었는데 거기에서 지금부터 하는 작업 모두를 해서 화일이 삭제된 파티션을 더이상 쓰지 않았습니다.

tct를 사용하려면 화일이 지워진 파티션의 빈 공간(저의 경우 2.5GB)보다 2.2배 정도의 빈 공간이 다른 파티션에 필요합니다. 저는 마침 6.7GB의 빈 공간이 되는 파티션이 있었는데, 정말 tct로 작업을 다 하니 6.7GB가 정말 다 차 버렸습니다.

이제 복구를 하는데 물론 root로 합니다. tct를 받아서 빈 파티션에 풀고 컴파일했습니다. (./configure를 하고 make all 만 하고 make install은 안 했습니다.) 복구는 두 단계로 나뉩니다. 작업은 tct를 압축풀은 바로 그 디렉토리에서 합니다.

1. 먼저 unrm으로 해당 파티션의 빈 공간을 하나의 커다란 화일로 덤프합니다.
$ bin/unrm /dev/hda7 > dump

2. 그 다음 lazarus로 덤프된 큰 화일을 지워지기 전엔 하나의 화일이었다 생각되는데로 화일단위로 쪼갭니다. (설명서에 보면 시간이 많이 걸린다고 되어 있는데 이 작업이 저의 경우 약 24시간은 걸린 것 같습니다.)
$ bin/lazarus -h dump

lazarus를 백그라운드로 돌려 놓고 보면 blocks라는 디렉토리와 www라는 디렉토리가 생기고 html 화일들이 세 개 생깁니다. 실제 blocks라는 화일에 덤프화일이 조각조각 쪼개져 저장이 됩니다. 운이 좋으면 초기에 쪼개져 나온 화일들 중에서 grep으로 잃어 버린 화일을 찾을 수도 있습니다.

예를 들어 지운 화일에 아주 특이한 단어가 들어 있다면(예를 들어 자기 이름) 그것으로 grep 하면 금방 찾을 수가 있습니다. 저의 경우는 운이 없었는지 해당 화일이 하드디스크 뒷부분에 있었는지 24시간이 다 지난 다음에야 찾을 수 있었습니다.

참고로 dump화일이 2GB가 넘으면 리눅스 커널과 펄(lazarus가 사용함)이 모두 2GB를 지원해야 lazarus가 실행이 됩니다. 제 덤프화일은 3.5GB여서 역시 처리를 못했는데 펄을 다시 최신 소스를 받아다 설치를 하니(물론 지워진 파티션에 설치하면 안 됨) lazarus가 그제서야 실행이 되었습니다(lazarus화일을 열어 첫 줄의 perl 위치를 바꿔줘야 함).

그리고 blocks안의 화일이 너무 많으면 grep도 화일이 너무 많다고 해서 동작을 못하는데(저의 경우도 역시 이랬습니다.) 이럴 때는
$ grep 문자열 1????.txt
$ grep 문자열 2????.txt
$ grep 문자열 3????.txt
...

이런 식으로 나누어서 grep 해주면 됩니다.

사실 시간이 총 이틀 정도 걸렸는데(백그라운드로 돌려 놓고 대부분 다른 일을 하긴 했지만) 이 방법이 아니라, inode 관련한 mini-howto 방법은 더 빠를지 저도 잘 모르겠구요. 시간이 좀 걸리더라도 중요한 화일을 꼭 복구해야 하는 분은 한번 시도해 보세요. 물론 덤프된 화일 사이즈가 작다면 시간은 그렇게까지 많이 걸리지는 않을 것입니다.

관련 링크: http://kltp.kldp.org/stories.php?story=01/11/01/7561951

글의 출처 : http://www.phpschool.com

원문출처 : http://network.hanbitbook.co.kr/view_news_print.htm?serial=282
http://user-mode-linux.sourceforge.net

시스템 재해 복구 연습 해보기

저자: 제프 다이크(Jeff Dike)

유저-모드 리눅스(UML)는 '소프트웨어' 머신의 일종으로 리눅스를 부팅하는 리눅스에서 돌아가는 리눅스 가상 머신이다. 이것은 가상 머신이기 때문에 프로그램의 생성 및 파괴가 용이하며 사실상 물리적인 시스템과 거의 똑 같은 수준으로 프로그램을 수행할 수 있다. 이와 같은 UML의 능력으로 인해 UML의 용도는 과거에 비해 훨씬 다양해졌다. 나는 이 기사에서 당연히 주목 받아야 하지만 주목 대상의 근처에도 가보지 못한 애플리케이션에 대해 이야기 하려고 한다.

UML 가상 머신은 설정 및 부팅이 아주 쉽다는 점을 제외하고는 실제 물리적 머신과 아주 흡사하다. 따라서 시스템 관리자들을 훈련하고 연습시키는 데에는 아주 이상적인 도구라고 할 수 있다. 특히 관리자들이 최악의 상태를 생성해내고 그 재해 복구 연습을 해보는 데 아주 적합하도록 만들어졌다. 나는 세 가지 재해 상황을 만들어내고 그것을 복구하는 방법에 대해 기술할 것이다. 보너스로 재해만 만들고 복구는 하지 않은 네 번째 상황도 연출해 낼 것이다.

우선 여러분이 가장 먼저 해야 할 일은 UML을 다운받아서 설치하는 것이다. http://user-mode-linux.sourceforge.net/dl-sf.html에 가면 UML RPM과 deb을 다운받을 수 있다. 이것들 중 여러분의 시스템에 적합한 것을 골라서 설치하면 된다. 다운로드 받은 프로그램에는 UML뿐만 아니라 추가로 여러 가지 다른 유틸리티도 있을 것이다. UML을 부팅시키려면 파일시스템 이미지도 필요한데 이것도 역시 같은 페이지에서 다운 받을 수 있다. 참고로 이 기사의 예제는 데비안 루트 파일시스템을 사용하여 만든 것이다. 만약 시스템이 데비안 루트 파일시스템을 다운 받기에 대역폭이 너무 짧으면 대신에 tomsrtbt 파일시스템을 다운받아도 된다.

그 모든 파일들이 어디로 갔지?

여러분이 UML을 사용하는 것에 익숙해지도록 특별하게 재해부터 설명하는 것으로 이 기사를 시작할 것이다. 그리고 그 재해를 복구해보지는 않을 생각이다. 여러분이 숙련된 UML 유저라 할지라도 어떻게 해서든지 평소에는 정말 해보고 싶었던 것이기 때문에 아마 이와 같은 재해 상황을 모두 따라 해볼 것이라 생각된다.

그냥 무슨 일이 일어날지 알아보기 위해 rm -rf /를 실행해 보자.

그러면 UML은 다음과 같이 시작된다.

% linux ubd0=cow,root_fs

이것은 UML이 root_fs 파일에서 cow 파일과 함께 부팅되었다는 것을 말하는 것으로 cow 파일은 root_fs 파일 상위의 copy-on-write (COW) 층을 뜻한다. 파일명 cow는 임의적인 것이며 자동적으로 생성된 것이므로 일관성을 유지하는 한 다른 파일명을 사용할 수도 있다. 우리는 이것과 관련된 유틸리티를 나중에 살펴볼 것이다. 압축을 풀면 root_fs_debian2.2_small 또는 root_fs_tomrtbt_1.7.205 중에서 하나로 루트 파일시스템의 이름이 붙여질 것이다. 이 이름 역시 축약형인 root_fs로 이름을 바꾸어 실제 이름처럼 사용할 수 있다.

부팅이 되면 콘솔 출력으로 아래와 같이 보이는 라인을 적어넣어 보자.

mconsole initialized on /tmp/uml/d4oIw6/mconsole

로그인 프롬프트에 루트(패스워드 'root')로 로그인 하여 아래와 같이 실행해 보자.

usermode:~# cd /

usermode:/# rm -rf /

모든 것들이 심각하게 망가질 때까지 단계를 높여서 계속해 보자. UML 사이트로부터 데비안 파일시스템과 함께 결국은 아래와 같은 메시지를 받을 것이다.

rm: cannot remove directory '//dev/pty': Directory not empty

rm: WARNING: Circular directory structure.

This almost certainly means that you have a corrupted file system.

NOTIFY YOUR SYSTEM MANAGER.

The following two directories have the same inode number:

//dev

//dev/pts

여러분이 병적인 타입이라면 포기하지 않고 여전히 취할 수 있는 조치가 있는지 살펴볼 것이다. 여러분이 자주 사용하는 유틸리티들이 없어졌을지도 모르기 때문에 아마도 내장 bash가 필요할 것이다.

시스템을 휴지통처럼 완전히 망쳐놓았다면 확실하게 시스템을 닫아야 한다. halt가 작동하지 않기 때문에 최선의 방법은 시스템을 중지시키는 uml_mconsole 유틸리티를 사용하는 것이다. 호스트에서 uml_mconsole를 실행시키고 부팅될 때 주의 깊은 메모를 남길 수 있는 디렉토리 이름을 부여한다. 그러면 그것은 UML을 중지시킬 것을 명령할 것이다.

% uml_mconsole d4oIw6

(d4oIw6) halt

OK

이제 여러분은 우리가 왜 COW 파일을 사용했는지 눈치챘을 것이다. 파일시스템에 입힌 피해는 모두 COW 파일 내에 있는 것들과 연관되어 있다. COW 파일 하부에 있는 root_fs 파일에는 어떠한 피해도 가지 않은 상태이다. 이것을 보기위해 COW 파일을 끄집어낼 수 있다.

% rm cow

그리고 방금 여러분이 했던 대로 UML을 부팅시켜보자.

% linux ubd0=cow,root_fs

여러분은 부팅이 성공적으로 실행되고 파일시스템이 전혀 손상되지 않은 것을 발견할 것이다. 우리는 실제 파일시스템에는 돌이킬 수 없는 손상을 입히지 않고 재해를 생성해 낼 경우 이와 같은 기술을 사용할 수 있다.

패스워드 파일을 잃어버린 경우

이제부터는 상대적으로 간단한 재해상황을 연출하여 그것을 복구해보도록 할 것이다.

% rm cow

% linux ubd0=cow,root_fs

패스워드 파일을 없앤 후에 머신을 중지시켜보자.

usermode:~# rm /etc/passwd

usermode:~# halt

You don't exist. Go away.

halt는 이제 더 이상 작동하지 않는다. 따라서 우리는 mconsole에서 닫아야 한다.

uml_mconsole zJwanV

(zJwanV) sysrq u

OK

(zJwanV) halt

OK

sysrq u는 파일시스템을 디스크로 비우고 그것들을 읽기 전용으로 재탑재할 것이다. 이것은 다음 부팅에 대비하여 우리가 fsck를 저장하도록 해줄 것이다. 다시 부팅해보자. 이번에는 명령 라인에 cow 파일만을 기입할 것이다.

% linux ubd0=cow

이제 우리는 패스워드 파일 없이도 리눅스가 얼마나 잘 작동하는지를 볼 것이다.

Debian GNU/Linux 2.2 usermode ttys/0

usermode login: root

Password:

Login incorrect

부팅은 성공적으로 실행되었지만 놀랍게도 로그인은 할 수 없다. 따라서 이것을 mconsole에서 다시 한 번 닫은 후 고쳐보도록 하자.

uml_mconsole b9cpus

(b9cpus) sysrq u

OK

(b9cpus) halt

OK

우리는 단일 유저로만 부팅하여 루트가 로그인 할 수 있게 패스워드 파일을 잠시 쉬게 할 것이다.

% linux ubd0=cow single

분포는 single의 해석에 따라 달라진다. single로 셸을 얻을 수 없다면 대신에 emergency를 시도해 보자. 데비안 파일시스템은 두 가지 모두 셸을 제공한다.

/etc/passwd: No such file or directory

Give root password for maintenance

(or type Control-D for normal startup):

리턴을 치는 것을 포함하여 여기 있는 모든 것들이 실행되는 것처럼 보인다.

sh-2.03# cat > /etc/passwd

sh: /etc/passwd: Read-only file system

하지만 여기에도 문제는 있으며 그 첫번째는 다음과 같다. 우리는 이외에 어떤 것을 실행하기 전에 루트 파일시스템 읽기/쓰기를 리마운트 할 필요가 있다.

sh-2.03# mount / -o remount

이제 예정된 재해로 돌아가보자. 우리는 여기서 cat을 사용할 수 있다. 하지만 vi를 더 선호한다면 vi를 사용해도 된다.

sh-2.03# cat > /etc/passwd

root::0:0:root:/root:/bin/bash

^D

지금까지 잘 해왔다. 유틸리티가 패스워드 파일을 좋게 생각하는지 확실히 해두기 위해 점검을 해보자.

sh-2.03# whoami

root

점검 결과도 좋으니 이제 기존의 단일 유저 셸로 부팅을 해보자.

sh-2.03# exit

그리고 루트로 로그인 할 수 있는지 알아보자.

Debian GNU/Linux 2.2 usermode ttys/0

usermode login: root

Last login: Tue Nov 13 18:28:32 2001 on ttys/0

Linux usermode 2.4.13-1um #2 Fri Oct 26 15:42:47 EDT 2001 i686 unknown

usermode:~#

성공이다. 루트로 다시 로그인 할 수 있게 되었다. 만약 이것이 가상 머신이 아닌 실제 머신에서 발생한 일이라면 여러분이 다음에 할 일은 가장 최근의 백업 테잎을 추적하여 /etc/passwd에 다시 복원하는 것이다.

셸이 없는 경우

이번에는 단일 사용자 모드로 부팅한다 해도 수정될 수 없는 bash를 제거해 보자.

러닝 리눅스, 3판

이 기사를 작성중일 때 나는 UML 블록 드라이버에 버그가 있다는 사실을 발견했다. 이것은 COW 파일이 루트 파일시스템으로 마운트되지 않았을 경우 COW 파일의 실행을 부적절하게 만들어 준다. 따라서 우리는 잠시동안 이것을 사용하지 않을 것이다.

root_fs을 no_bash으로 복사하여 부팅하고 로그인 한 후 bash를 삭제하자.

% cp root_fs no_bash

% linux ubd0=no_bash

usermode:~# rm /bin/bash

usermode:~# halt

만일 정지되는 것이 지연되면 mconsole로 UML을 중단시키자. 다시 부팅시키고 셸 없이 어떻게 실행하는지 살펴보자.

linux ubd0=no_bash

부팅은 아주 빨리 되었으며 로그인도 불가능하게 되었다.

INIT: cannot execute "/etc/init.d/rcS"

INIT: Entering runlevel: 2

INIT: cannot execute "/etc/init.d/rc"

Debian GNU/Linux 2.2 (none) ttys/0

(none) login: root

Unable to determine your tty name.

따라서 우리는 이제 mconsole로 닫아야만 하고 어떻게 고칠 지에 대해 생각해보아야 한다.

우리는 구조 디스크에서 부팅을 시뮬레이션 할 것이다. 우리는 구조 디스크로서 root_fs을 사용할 것이며 디스크 0으로 할당할 것이다. 그리고 손상된 파일시스템은 디스크 1로 옮길 것이다.

% linux ubd0=root_fs ubd1=no_bash

그러면 이제 로그인하여 /mnt에 손상된 파일시스템을 마운트하고 bash를 없애도록 하자.

usermode:~# mount /dev/ubd/1 /mnt

usermode:~# ls /mnt/bin/bash

ls: /mnt/bin/bash: No such file or directory

이제 훨씬 고치기 쉬워진 것을 발견할 수 있을 것이다. 그리고 여러분은 다음과 같이 구조 디스크에서 셸을 복사할 수 있다.

usermode:~# cp -p /bin/bash /mnt/bin/bash

usermode:~# ls -l /bin/bash /mnt/bin/bash

-rwxr-xr-x 1 root root 461400 Feb 20 2000 /bin/bash

-rwxr-xr-x 1 root root 461400 Feb 20 2000 /mnt/bin/bash

이제 여러분은 UML을 중지할 수 있으며 no_bash에서 다시 OK를 부팅한다는 것을 확인하기 위해 부팅할 수 있다.

백업! 백업! 백업!

이제 마지막으로 파일시스템을 백업하고 백업한 것의 대부분을 파괴하여 백업한 것을 복원함으로써 수정하는 작업을 실시해 볼 것이다. 백업 장치는 파일시스템을 가지기에 충분할 정도로 거대한 빈 파일이 될 것이다.

% dd if=/dev/zero of=backup seek=600 bs=$((1024*1024)) count=1

내 파일시스템은 이제 막 500 메가바이트를 넘어섰기 때문에 나는 백업 포맷의 오버헤드를 수용할 수 있는 600 메가바이트짜리 백업 파일을 만들었다. 따라서 위 라인에서 보이는 seek=600은 여러분에게 적합하게끔 그 사이즈를 여러분이 조정할 수 있다. 이제 root_fs를 trashed에 복사하고 디스크1의 backup으로 복사하여라.

% cp root_fs trashed

% linux ubd0=trashed ubd1=backup

로그인 하여 /dev/ubd/1에서 백업하여라. 여기서 나는 tar를 사용할 것이다. 만약 여러분이 자주 사용하는 다른 백업 도구가 있다면 그것을 사용해도 상관없다. 우리가 이 디바이스에 파일시스템을 만드는 것이 아니라는 점만 명심하기 바란다. 그것은 테잎이 사용된 것과 아주 똑같은 방법으로 처리하지 않은 데이터 디바이스로 사용되었다.

만약 I/O 에러로 인해 실패했다면 여러분이 만든 백업 파일이 너무 작다는 뜻이다. 이때는 단순히 더 큰 seek 인자와 함께 파일에 dd를 실행시키고 백업을 재시도함으로써 확장할 수 있다.

usermode:~# tar clf /dev/ubd/1 /

tar: Removing leading '/' from member names

tar: Removing leading '/' from link names

이 작업이 다 끝나면 우리는 그 이름에 딱 맞는 'trashed(휴지들)'를 만들게 될 것이다.

usermode:~# rm -rf /bin /lib /usr/lib

여러분이 없애고 싶은 것을 삭제해라. 여기서도 마찬가지로 여러분이 내키는 대로 파일을 망가뜨려 놓을 수 있다. 신나게 망치는 작업을 하고 난 후 필요하다면 mconsole을 사용하여 시스템을 닫아보자.

백업을 사용해 재해를 복구할 시간이다. 구조 디스크의 root_fs, 또다시 디스크 1의 backup, 디스크 2의 trashed로 UML을 부팅시키자.

% linux ubd0=root_fs ubd1=backup ubd2=trashed

로그인하여 /mnt, cd에 손상된 파일시스템을 마운트하고 백업한 것을 복원하자.

usermode:~# mount /dev/ubd/2 /mnt

usermode:~# cd /mnt

usermode:/mnt# tar xpf /dev/ubd/1

tar: : Cannot mkdir: No such file or directory

tar: Error exit delayed from previous errors

에러가 발생했음에도 불구하고 성공했다.

usermode:/mnt# ls bin

arch dd fgrep ls pidof run-parts touch

...

이제 우리는 UML을 중단하고 'trashed'에서 다시 부팅함으로써 재해를 복구할 수 있다는 것을 점검할 수 있다.

linux ubd0=trashed

결론

다행스럽게도 이 기사는 UML이 귀중한 시스템 관리 도구가 될 수 있음을 알려주고 있다. 이 기사에서 나는 다양한 종류의 시스템 관리 재해 상황을 연출해내고 또 복구하는 과정을 설명했다.

명백하게도 여기에서 제시된 예들은 실재 상황에서 발생할 수 있는 여러 가지 재해 중 아주 작은 부분만을 보여준 것에 불과하다. 하지만 여기에서처럼 재해를 만들어 그것을 고쳐보려고 노력하는 과정이야말로 실재 재해에 미리 대비하는 가장 좋은 방법이라고 확신한다. 이러한 재해 상황 연출과 재해 복구를 실제 머신에서 일어나게 하는 것은 불가능하지만 UML로 시뮬레이션 시켜볼 수 있기 때문에 이 방법이야 말로 아주 편리하고 실제 머신에서와 거의 똑같이 실습해볼 수 있는 기회라는 것은 확실하다. 이 디바이스는 이름은 다를지 몰라도 그 실행절차는 실제 머신과 아주 똑같기 때문이다.

이 기사를 발표함과 동시에 나는 http://user-mode-linux.sourceforge.net/sdotm.html라는 UML 웹사이트에 이 달의 시스템 관리 재해를 개시하고 있다. 나는 그곳에서 각종 재해상황을 발표하고 해결방법을 모을 것이다. 그리고 독창성, 정교함, 간결성, 절제성과 같은 내가 선정한 기준에 근거하여 매달 수상자를 발표할 것이다. 물론 제시된 재해에 대한 감수도 받을 것이다. 만약 여러분이 꾸며보고 싶은 재해가 있다면 제시된 해결책을 따라 그것을 감수해 보도록 하여라.

'System' 카테고리의 다른 글

readonly 파티션 rw로 다시 마운트하기?  (2) 2002.02.20
실수로 삭제한 화일 tct로 복구하기  (0) 2002.01.28
시스템 재해 복구 연습 해보기  (0) 2002.01.20
여러 가지 커널 팁 #2  (0) 2001.12.26
여러 가지 커널 팁 #1  (1) 2001.12.26
iptables 에러..  (0) 2001.12.13

글쓴이: Dave Jones <dave [at] ext2 [dot] net>
옮긴이: 임종균 <hermes44 [at] secsm [dot] org>
원문: http://ext2.linuxberg.com/99/07/kernel/070699-kernel1.shtml

내가 받은 편지로 판단해 볼 때, System.map 파일은 여전히 사람들에게는
어려운 것 같다. 그래서 커널 메일링 리스트에서 그 파일에 대한 긴나긴 토론들을
읽어보았다.

Q. 그것은 어떤 용도로 사용됩니까?
A. 만약 커널 oops가 발생하면, 화면에 여러 가지 레지스터들과 그 16진수 내용에
대한 한 페이지의 정보가 출력될 것입니다. 만약 System.map이 있다면, klogd는
16진수 주소를 그 주소가 나타내는 함수 이름으로 변환할 것입니다.
이 정보로부터 정확히 어느 위치에서 커널이 문제를 일으켰는지 판단할 수
있습니다. System.map이 없다면, 완전히 쓸모없는 16진수 주소들만을 떠맡게
될 것입니다. 이 값들은 각 기계마다 다르고, 커널 설정마다 다르기 때문입니다.

Q. 그렇다면 그 파일 없이도 살 수 있습니까?
A. 리눅스는 System.map 없이 부팅할 것입니다. 그러나 시스템에 문제가
발생할 때, 주어지는 정보는 당신에게나 커널 개발자에게도 무엇이 문제인지에
대한 어떠한 단서도 주지 못 할 것이라는 경고를 합니다. System.map은
몇 백 Kb밖에 안 되고, 일단 설치한 후에는 완전히 잊어버리고 있어도 됩니다.

Q. 심볼릭 링크를 만들고 하는 모든 작업들이 너무 혼란스럽습니다.
A. Jeff Garzik께서 x86에서 사용자는 'make install' 할 수 있는다는 언급을
하신 편지를 보내주셨습니다. 이는 vmlinuz-VERSION과 System.map-VERSION을
/boot로 복사하고 lilo를 실행합니다. 미리 /etc/lilo.conf가 변경되어 있어야
합니다. (그리고 klogd의 시작 스크립트에서
'klogd -k /boot/System.map-`uname -r`'을 사용해야 합니다.)

또 몇몇 사람들은 명령행에 '-j n'을 추가하는 것에 (즉 `make -j 32 bzImage`)
대한 메세지를 보고 편지를 보냈다. 어떤 사람들은 단일 프로세서 시스템에서
그것의 유효성에 대해 질문했다.

난 64MB RAM의 K6-233 시스템에서 테스트를 했다. 작업의 수를 바꿔가면서 커널을
컴파일을 하였다. 동시 빌드의 수를 늘리면 커널 빌드는 더 빨라진다.
한계는 -j32로 보인다. (빌드 시간을 거의 1분 정도 줄였다.) 이 이상은 거의
향상이 없는 것 같다. SMP 시스템에서 더 많은 이득을 볼 수 있는 것이 맞지만,
테스트는 단일 프로세서 시스템에서도 역시 -j는 유효한 팁이란 것을 보여준다.

Liviu Sas은 'nice --20 make bzImage' 또한 컴파일 속도를 높이는 유용한
팁이라는 제안을 보내주었다.

John Slee는 lilo.conf 자동 생성기를 보내주었다. 이 작은 스크립트는 /boot에서
모든 안정 커널을 찾아서 lilo.conf를 만든다. 가장 높은 버전의 커널을
기본값으로 잡는다.

기본으로 필요한 작업은 모든 lilo.conf에 포함될 옵션들을 가지고 있는 /etc/lilo.conf.static 파일을 만드는 것이다.
그 후, 아무 인자없이 스크립트를 실행하기만 하면 된다. lilo.conf를 만들고
새 부트로더를 설치한다.

내가 보기에 한 가지 단점은 부트 항목별로 옵션을 넣을 수 없다는 것이다.

#!/bin/bash

umask 772
kernel_dir=/boot

# lilo assumes the default image is the first one in lilo.conf, so
# we sort the kernel images backwards, hence the highest-version'd kernel
# will be the default.
images=`cd $kernel_dir && ls -1 vmlinuz-*
| egrep "vmlinuz-([0-9]+).([0-9]+).([0-9]+)[^-]*$"
| sort -rn`

cp -f /etc/lilo.conf.static /tmp/lilo.conf

# three lines per entry, 3 x 19 images = 57
( for img in $images ; do
label=`echo $img | sed 's/vmlinuz/linux/ ; s/-//g ; s/.//g'`
echo "image=$kernel_dir/$img"
echo "label=$label"
echo ""
done ) | head -57 >> /tmp/lilo.conf

if /sbin/lilo -C /tmp/lilo.conf ; then
mv -f /etc/lilo.conf /etc/lilo.conf.last
cp -f /tmp/lilo.conf /etc/lilo.conf
echo successfully installed new bootloader.
rm -f /tmp/lilo.conf
exit 0
else
echo eek, lilo barfed
rm -f /tmp/lilo.conf
exit 1
fi

내가 받았던 편지에서 또 다른 흔한 주제는 커널 패치에 대한 기사에 관련된
것이다. 특히, 많은 사람들이 옛날 커널을 위해 작성된 패치를 새 커널에
적용하려는 데서 문제를 겪고 있다. 대부분의 경우, 패치 과정중에 어떤 경고
메세지를 받았고 패치가 어떻게 동작하는지 완전히 이해하지 못 한다면,
그 패치의 관리자에게 연락을 해서, 문제점에 대해 말해주어야 한다.
만약 'offset 31 lines'나 이 비슷한 메세지가 나왔다면, 이는 문제가 아니다.
파일에서 패치하려하는 루틴의 코드가 약간 변경되어지만, 목표 루틴은 발견되어
패치되었다는 것을 의미한다.

관련 링크: http://kldp.org/Translations/html/Kernel_Tip_2-KLDP/Kernel_Tip_2-KLDP.html

+ Recent posts