한빛출판네트워크

by 마이클 루카스, 역 한빛리포터 2기 신동섭 일상적인 메시지는 파티션이 가득 차 가고 있다는 것을 보여준다. (여러분은 일상적인 상황 메일을 정말로 읽고 있나요? 물론 읽고 일겠지만…) 다양한 데스크 탑 환경은 디스크 공간의 상황을 정확히 보여주는90포인트 앤 클릭 인터페이스를 가지는 반면에 GUI가 없는 서버는 문제를 야기시키기 시작할 때 도움이 되질 않는다. 우리는 디스크 공간 중 몇 기가바이트가 손실되었는지를 발견하기 위해 몇 개의 기본적인 디스크 관리 도구를 살펴볼 예정이다. 우선 파티션별 공간이 얼마나 많이 남았는지를 살펴볼 필요가 있다. df(1)은 여기에 가장 적합한 도구이다. vanilla df 명령을 통한 결과를 읽어 내는 것은 쉬운일이 아니다. 하드디스크가 10MB 또는 40MB 정도에서 최고치를 벗어나는 것도 그렇게 나쁜 상황은 아니다. 하지만 디스크가 100GB에 이르게 되면 변환 소수점으로 인해 여러분의 눈이 휘둥그렇게 될 것이다. -h와 -H 플래그 둘 다 df와 함께 사용함으로써 읽을 수 있는 결과치를 나타낼 수 있다. 소문자 h는 1,024byte 메가바이트를 생성하기 위해 base 2를 사용하는 반면에 대문자 H는 1,000byte 메가바이트를 생성하기 위해 base 10을 사용한다. 대부분의 FreeBSD 도구들은 base 10을 사용하기 위한 옵션을 제공하진 않는다(컴퓨터 세계에서 base 2는 의심할 여지 없이 더 정확하다. 그래서 우리들은 예제를 위해 이것을 사용할 것이다). 우리는 하나의 파티션에서 가능한 inode를 점검해야 한다. inode를 다 소진하여 더 이상 파일을 생성할 수 없다면 많은 디스크 공간을 가지는 것에 대해 충분히 논의할 가치가 있다. -i 옵션을 사용하면 그 정보를 얻을 수 있다. 따라서 현재 디스크 사용정보는 아래와 같이 표시된다:

#df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s1a 97M 43M 46M 48% 1368 23718 5% / /dev/ad0s1f 4.9G 2.7G 1.8G 60% 184468 1117034 14% /usr /dev/ad0s1e 194M 12M 166M 7% 794 49380 2% /var procfs 4.0K 4.0K 0B 100% 41 1003 4% /proc #

만약 내가 2GB 파일을 랩탑으로 복사할 필요가 없다면 이것만으로도 충분할 수 있다. 얼마 전까지만 해도 2GB 하드 드라이버가 최고의 사양이었으나 오늘날에는 몇몇 큰 상용 소프트웨어 패키지들 중에는 2GB에 이르는 것들도 많다. 나는 충분한 공간을 가지고 있다. 가장 큰 문제는 쓸데없는 것들이 동작하고 있는 곳이 어딘지를 발견하는 것이다. 만약 여러분의 시스템이 내 것과 같다면 다소 확실치 않은 이유 하에서도 계속해서 디스크가 사용되고 있을 수 있다. 여러분은 디렉토리 대 디렉토리 기반으로 각각의 큰 파일들을 구별하기위해 ls -l을 사용할 수 있지만 시스템의 모든 디렉토리에 이것을 사용하는 것은 비실용적이다. 무엇을 보존해야 하고 무엇을 지워야 하는지에 관한 명확한 결정은 아주 개인적인 일 일수 있지만 가장 큰 프로그램과 디렉토리를 구별하도록 도와줄 수 있는 더 향상된 도구들이 있다는 것도 알아둘 필요가 있다. 첫번째 도구는 du(1)으로 디스크 사용정도를 표시해준다. 초기 결과정보만으로는 좀 두려움이 있지만 새 시스템 관리자가 두려움을 느낄 필요 없을 정도로 유용하다.

# cd $HOME # du 1 ./bin/RCS 21459 ./bin/wp/shbin10 5786 ./bin/wp/shlib10/fonts 13011 ./bin/wp/shlib10 19 ./bin/wp/wpbin/.wprc 7922 ./bin/wp/wpbin 2 ./bin/wp/wpexpdocs 1 ./bin/wp/wpgraphics 2 ./bin/wp/wplearn 10123 ./bin/wp/wplib 673 ./bin/wp/wpmacros/us 681 ./bin/wp/wpmacros 53202 ./bin/wp 53336 ./bin 5 ./.kde/share/applnk/staroffice_52 6 ./.kde/share/applnk ...

이 명령어로 서브 디렉토리들을 표시해주고 블록 크기를 나타내어준다. 내가 쓰는 시스템에서 $BLOCKSIZE은 k로 설정되어있다. 이 명령어로 각 서브 디렉토리의 모든 것이 나타난다. 예를 들어 $HOME/bin 내용의 총 크기는 53,336KB(또는 대략 52MB)이며 그 중에서 $HOME/bin/wp 디렉토리는 53,202 블록을 가지고 있다. 나는 모든 디렉토리와 하부 디렉토리를 du를 통해 리스트 할 수도 있으나 실제로는 정말 내가 원하는 것 이상의 정보를 찾아내야 한다. 특히 블록이 왼쪽정렬로 프리트되지 않았을 때 블록은 그렇게 편리하게 측정되어지지 않는다. 그렇다면 먼저 이것부터 확실히 해두자. du는 df와 같은 플래그 -h를 지원한다.

# du -h 1.0K ./bin/RCS 21M ./bin/wp/shbin10 5.7M ./bin/wp/shlib10/fonts 13M ./bin/wp/shlib10 19K ./bin/wp/wpbin/.wprc 7.7M ./bin/wp/wpbin 2.0K ./bin/wp/wpexpdocs 1.0K ./bin/wp/wpgraphics 2.0K ./bin/wp/wplearn 9.9M ./bin/wp/wplib 673K ./bin/wp/wpmacros/us 681K ./bin/wp/wpmacros 52M ./bin/wp 52M ./bin 5.0K ./.kde/share/applnk/staroffice_52 ...

이것이 조금 더 괜찮아 보이지 않는가? 그렇지만 나는 각 하부 디렉토리의 항목까지 볼 필요는 없다. 현재 디렉토리에 있는 모든 것에 대한 총 크기로도 적당할 것이다. du의 -d 플래그로 표시하고자 하는 만큼 디렉토리를 조절할 수 있으며 -d는 하나의 플래그를 가지며 여러분이 보여주길 원하는 디렉토리 수를 조절할 수 있다. -o는 하나의 디렉토리안에 있는 파일들의 간단한 소계를 보여 줄 수 있을 것이다.

#du -h -d0 $HOME 1.0G /home/mwlucas #

내 홈 디렉토리안에 1GB가 있는가? 좀 더 자세히 레이어를 살펴보고 도대체 그것이 어디에 있는지를 보도록 하자.

#du -h -d 1 52M ./bin 1.4M ./.kde 24K ./pr 40K ./.ssh 2.0K ./.cvsup 812M ./mp3 1.0K ./.links 5.0K ./.moonshine ...

여기서 큰 장애는 mp3 디렉토리이다. 모… 딱히 내가 해야만 한다면 다른 장비로 복사할 수도 있다. 어쨌든 이것은 홈 디렉토리를 깨끗이 할 수 있는 좋은 기회다. 나는 한 주 동안 KDE를 시도했다. 여전히 싫어하지만 그때의 고생덕분에 지금은 .kde를 적용할 수 있다. 그래서 .moonshine는 물론 이와 관련된 것을 적용할 수 있다. 이 작업을 완료했을 때쯤이면 홈 디렉토리는 약 200KB로 줄어들어 있을 것이다. 훨씬 좋게 말이다. 이제부터는 비정상적으로 용량이 큰 무언가가 숨어있는지 알아보기 위해 주요 /usr과 /var 디렉토리를 살펴보자.

#cd /usr #du -h -d1 11M ./bin 7.5M ./include 34M ./lib 9.6M ./libdata 15M ./libexec 571M ./local 6.3M ./sbin 39M ./share 289M ./src 119M ./ports 57M ./compat 1.5M ./games 323M ./obj 1.0K ./tmp 234M ./X11R6 1004M ./home 11M ./sup 36M ./doc 2.7G . #

이 결과는 아주 일반적인 것이다. GB 중 다른 공간을 확보하기 위해 쉽게 지울 수 있는 것이 /usr/obj에 323MB정도 있다. 참고로 나는 비어있는 /var 파일시스템의 결과를 첨부하고 있다. 시스템 목적에 따라 다른 /var 디렉토리가 많이 생성될 수 있다. 그러나 놀랍게도 /var안의 데이터는 얼마되지 않는다.

# du -h -d1 1.0K ./account 3.0K ./at 8.0K ./backups 2.0K ./crash 2.0K ./cron 4.3M ./db 434K ./log 7.3M ./mail 2.0K ./msgs 1.0K ./preserve 54K ./run 1.0K ./rwho 18K ./spool 10.0K ./tmp 20K ./yp 62K ./games 2.0K ./lib 4.0K ./ucd-snmp 1.0K ./heimdal 12M . #

채워져 있는 /var를 발견한 다음에 여러분은 여기서 가지고 있어야 하는 디렉토리 구조를 비교할 수 있고 적어도 작은 시스템에서 일반적인 것이 무엇인가에 대한 좋은 아이디어를 가질 수도 있다. 나는 du(1)을 파일 시스템 전체를 브라우징하기 위해 사용할 수 있으며 불필요한 데이터가 주로 어디에 있는지 볼 수 있다. 시스템의 나머지 공간에 불필요한 데이터가 생기는 가장 큰 이유는 설치된 소프트웨어와 사용자 데이터 때문이다. 위의 예에서 /usr/local은 1GB의 절반 이상을 소비한다. 사용자 데이터를 지우는 것이 좋은 생각은 아니지만 여러분은 pkg_info(1)에 -s 플래그를 사용해서 큰 용량의 패키지를 쉽게 찾아낼 수 있다.

# cd /var/db/pkg # pkg_info -s * Information for Hermes-1.3.2: Package Size: 449 (1K-blocks) Information for Mesa-3.4.1: Package Size: 2507 (1K-blocks) ...

만약 시스템에 인스톨된 패키지가 많다면 이것은 거대한 양의 결과를 생성할 수 있다. 예를 들어 내가 사용하는 랩탑에는 수 많은 패키지 중에 134라는 것이 있다. 큰 용량의 패키지들을 찾기 위해 이것을 사용하여 검색하라.

Information for emacs-20.7: Package Size: 43800 (1K-blocks)

		Learning the Unix Operating System, 5th Edition

Emacs는 43MB인가? 그래, 그래, 나는 알고있다. vi를 사용하라. 많은 포트가 꼭 필요한 것일수도 있지만 나는 쉽게 설치할 수 있거나 필수적이지 않은 몇몇 포트를 발견할 수도 있게 된다. 예를 들어 /usr/ports/textproc/docproj에 의존적인 100MB정도의 teTex가 있다. 그것은 최근의 FreeBSD release로부터 대신할 수 있을 정도로 충분하며 teTex는 가장 최신의 빌드를 요구할 정도로 빠르게 변화하지는 않는다. TeTex와 /usr/obj를 제거함으로서 나는 랩탑에 이 거대한 파일을 복사할 충분한 공간을 얻을 수 있다. du와 pkg_info는 $HOME/mp3안에 있는 사용자 데이터를 망치지 않고 내가 지울 파일을 안전하게 선택할 수 있도록 필요한 정보를 제공한다. 결국 무엇보다도 중요한 것은 데이터이기 때문이다. 마이클 루카스(Michael Lucas)는 아내 리즈와 함께 다양한 설치류동물들과 다수의 물고기를 키우면서 미시간주 디트로이트시에 살고 있다. 그가 가진 모든 문제가 Great Lakes Technologies Group이라고 말하지만 어쨌든 그곳에서 네트워크 설계자로 일하고 있다.