파일시스템
파일시스템이란 무엇인가?
파일시스템(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메가바이트의 절약이 있을 수 있음을 볼 수 있었다. 그러나 측정에 사용된 시스템은 비교적 프로그램이 거의 없고 데이타베이스파일이 없다.
풍부한 파일시스템
리눅스는 몇가지 파일시스템을 지원한다. 이 글을 쓰고 있는 시점에서 중요한 파일시스템은 다음과 같다.
- minix
가장 오래되었고 가장 신용할만 하다고 가정되나, 특징에서 다소 제한이 있고(몇몇 time stamp가 유실되고, 파일이름은 최대 30문자이다), 성능에 제한이 있다(파일시스템당 최대 64메가바이트).
- xia
파일이름과 파일시스템 크기 한계를 끌어올린 minix 파일시스템을 수정한 버전이나, 새로운 특징은 없다. 매우 유명하지는 않으나 매우 잘 작동한다고 보고된다.
- ext2
리눅스 파일시스템 본연의 대부분의 기능을 가지고 있고, 현재 가장 유명한 파일시스템. 쉽게 호환되면서 업되게 설계되어 있어서, 새 파일시스템 버전때문에 존재하는 파일시스템을 다시 만들 필요가 없다.
- ext
상위 호환성이 없던 ext2의 구 버전. 설치시에 거의 사용하지 않고, 대부분의 사람들은 ext2로 전환했다.
여기에, 다른 운영체제와 파일 교환을 쉽게 하기 위해, 몇가지 외부의 파일시스템을 지원한다. 이 외부 파일시스템들은 유닉스 특징이 부족하다던가, 심각한 제한이 있다던가, 아니면 다른 특별한 점이 있는 경우를 제외하고 리눅스 파티션처럼 작동한다.
- msdos
MS-DOS(OS/2와 Windows NT) FAT파일시스템과 호환
- usmdos
msdos파일시스템을 리눅스상에서 긴 파일명, 소유자, 접근권한, 링크와 장치파일들을 지원하도록 확장한 것. umsdos는 보통의 msdos파일시스템이 리눅스 파일시스템처럼 사용되도록 하기 때문에, 리눅스를 위해 파티션을 나눌 필요를 없앤다.
- iso9660
CD-ROM 표준 파일시스템. 시디롬 표준에 좀더 긴 파일명을 쓸 수 있는 확장한 유명한 록 릿지(Rock Ridge)가 자동으로 지원된다.
- nfs
많은 컴퓨터들이 컴퓨터들의 파일에 서로 쉽게 접근하기 위해 컴퓨터들이 서로 파일시스템을 공유하도록 하는 네트웍 파일시스템(Nework FileSystem)
- hpfs
OS/2 파일시스템
- sysv
SystemV/386과 SystemV/386에서 나온 것들과 Xenix의 파일시스템
파일시스템의 선택은 상황에 따라 다르다. 호환성과 다른 이유로 리눅스 본래의 파일시스템이 아닌 것 중 하나가 필요하다면, 그것은 반드시 사용되어야 한다. 만약 자유롭게 고를 수 있다면 아마도 ext2를 사용하는 것이 가장 현명할 것이다. ext2는 모든 특성을 가지고 있고 수행능력이 부족해서 고생하지 않기 때문이다.
proc파일시스템이라는 것도 존재하는데, 보통 /proc 디렉토리로 접근할 수 있다. proc파일시스템은 파일시스템같이 보일지라도 실제로 전혀 파일시스템이 아니다. proc파일시스템은 프로세스 리스트(process list, proc파일시스템의 이름의 유래)같은 일정한 커널 데이타 구조에 접근하기 쉽게 한다. proc파일시스템은 이런한 데이타 구조를 파일시스템처럼 만들어버리고, 이러한 파일시스템은 모든 평범한 파일도구로 다룰 수 있다. 예를 들어 모든 프로세스 리스트를 얻기 위해 다음 명령을 내릴 수 있다.
$ ls -l /proc total 0 dr-xr-xr-x 4 root root 0 Jan 31 20:37 1 dr-xr-xr-x 4 liw users 0 Jan 31 20:37 63 dr-xr-xr-x 4 liw users 0 Jan 31 20:37 94 dr-xr-xr-x 4 liw users 0 Jan 31 20:37 95 dr-xr-xr-x 4 root users 0 Jan 31 20:37 98 dr-xr-xr-x 4 liw users 0 Jan 31 20:37 99 -r--r--r-- 1 root root 0 Jan 31 20:37 devices -r--r--r-- 1 root root 0 Jan 31 20:37 dma -r--r--r-- 1 root root 0 Jan 31 20:37 filesystems -r--r--r-- 1 root root 0 Jan 31 20:37 interrupts -r-------- 1 root root 8654848 Jan 31 20:37 kcore -r--r--r-- 1 root root 0 Jan 31 11:50 kmsg -r--r--r-- 1 root root 0 Jan 31 20:37 ksyms -r--r--r-- 1 root root 0 Jan 31 11:51 loadavg -r--r--r-- 1 root root 0 Jan 31 20:37 meminfo -r--r--r-- 1 root root 0 Jan 31 20:37 modules dr-xr-xr-x 2 root root 0 Jan 31 20:37 net dr-xr-xr-x 4 root root 0 Jan 31 20:37 self -r--r--r-- 1 root root 0 Jan 31 20:37 stat -r--r--r-- 1 root root 0 Jan 31 20:37 uptime -r--r--r-- 1 root root 0 Jan 31 20:37 version $ |
파일시스템이지만 proc파일시스템의 어느 것도 디스크를 건드리지 않는다는 것을 유의해라. proc파일시스템은 오로지 커널의 상상속에서만 존재한다. 누군가가 proc 파일시스템의 어떤 부분을 보려고 한다면, 커널은 실제로 존재하지는 않지만, 마치 어딘가에 존재하는 것처럼 보이게 한다. /proc/kcore 파일이 있을지라도, 디스크 공간을 차지하지는 않는다.
어떤 파일시스템을 사용할 것인가?
보통 많은 다른 파일시스템을 사용하는데는 조그만 이유가 있을 것이다. 현재는 ext2fs가 가장 유명한 파일시스템이고, ext2fs가 가장 현명한 선택일 것이다. 파일구조를 기록하기 위한 부하, 속도, (파악된) 안정성, 호환성과 여러가지 다른 이유에 의해서, 다른 파일시스템을 사용하는 것도 추천할만 할지도 모른다. 파일시스템을 고르는 것은 각각의 경우에 따라 결정될 필요가 있다.
파일시스템 만들기
파일시스템은 mkfs 명령으로 만들어진다. 즉 초기화되는 것이다. 실제로 각 파일시스템마다 다른 프로그램이 있다. mkfs는 단지 원하는 파일시스템의 형식에 따라 적절한 프로그램을 돌리는 전위 프로그램이다. 파일시스템 형식은 -t fstype 옵션으로 선택되어진다.
mkfs라 불리는 프로그램들은 약간 다른 명령어 인터페이스를 가진다. 일반적이고 가장 중요한 옵션들은 아래에 요약되어 있다. 더 자세한 것은 메뉴얼 페이지를 보아라.
- -t fstype
파일시스템의 형식을 선택한다.
- -c
배드블럭을 조사하고 조사한 결과에 따라 배드블럭 리스트를 초기화한다.
- -l filename
filename이라는 파일로부터 초기의 배드블럭리스트를 읽어들인다.
ext2파일시스템을 플로피에 만들기 위해, 다음과 같은 명령을 내릴 것이다.
$ fdformat -n /dev/fd0H1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done $ badblocks /dev/fd0H1440 1440 $>$ bad-blocks $ mkfs -t ext2 -l bad-blocks /dev/fd0H1440 mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 360 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done $ |
badblocks와 배드블럭리스트 대신에 -c 옵션이 mkfs와 함께 사용될 수도 있을 것이다. 예는 아래와 같다.
$ mkfs -t ext2 -c /dev/fd0H1440 mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 360 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Checking for bad blocks (read-only test): done Writing inode tables: done Writing superblocks and filesystem accounting information: done $ |
포맷하는 것이 불필요한 것을 제외하고, 하드디스크나 파티션에 파일시스템을 만드는 과정은 플로피와 같다.
마운트하기와 마운트 풀기
파일시스템을 사용하기 전에, 마운트되어야 한다. 그리고나서, 운영체제는 모든 것이 잘 작동하는지 확실히 하기 위해 여러가지 기록하는 작업을 한다. 유닉스안의 모든 파일들은 단일 디렉토리 트리안에 있으므로, 마운트 작업은 새로운 파일시스템의 내용이 이미 어딘가에 마운트된 파일시스템의 존재하는 하위디렉토리의 내용으로 보이게 할 것이다.
예를 들어, Figure 4-3은 각각 고유의 루트 디렉토리를 지니는 세개의 다른 파일시스템을 보여준다. 마지막 두 파일시스템이 첫째 파일시스템의 /home과 /usr에 각각 마운트되었을 때, Figure 4-4처럼 단일 디렉토리 트리를 얻을 수 있다.
마운트는 다음과 같이 행해질 수 있다.
$ mount /dev/hda2 /home $ mount /dev/hda3 /usr $ |
리눅스는 많은 파일시스템 형식을 지원한다. mount는 파일시스템의 형식을 추측하려고 할 것이다. 형식을 바로 지정하기 위해 -t fstype 옵션을 사용할 수 있다. -t fstype은 때때로 필요하다. mount가 사용하는 추론이 항상 동작하는 것은 아니기 때문이다. 예를 들어, MS-DOS플로피를 마운트하기 위해, 다음 명령을 내릴 수 있다.
$ mount -t msdos /dev/fd0 /floppy $ |
마운트할 디렉토리는 반드시 존재해야 하지만 비어있을 필요는 없다. 그러나, 그 안에 있는 어떤 파일이라도 파일시스템이 마운트되어 있는 동안은 이름으로는 접근할 수 없을 것이다.(이미 열려있던 어떤 파일들은 여전히 접근 가능할 것이다. 다른 디렉토리에 하드링크되어 있는 파일들은 그 이름을 가지고 접근할 수 있을 것이다.) 그렇게 한다고해서 해가 되지 않고, 심지어 필요할 수도 있다. 예를 들어, 어떤 사람들은 /tmp와 /var/tmp를 같게 사용하는 것을 좋아해서, /tmp를 /var/tmp로 심볼릭링크시킨다. 시스템이 부팅될 때, /usr 파일시스템이 마운트되기 전, 루트 파일시스템에 들어있는 /var/tmp 디렉토리가 대신 사용된다. /usr이 마운트되었을 때, 루트 파일시스템에 있는 /var/tmp 디렉토리는 접근불가능이 될 것이다. 만약 /var/tmp가 루트파일시스템에 존재하지 않는다면 /var을 마운트하기 전에는 임시파일들은 사용하는 것이 불가능할 것이다.
만약 파일시스템에 어떤 것도 기록할 생각이 없다면, 읽기전용 마운트를 하기 위해 mount에 -r 스위치를 사용해라. 읽기전용 마운트는 커널이 파일시스템에 기록하려고 하는 어떤 시도도 중지하도록 할 것이고, 커널이 inode안에 있는 파일 접근 시간을 갱신하는 것도 방해할 것이다. 읽기전용 마운트는 쓸 수 없는 미디어, 예를 들어 시디롬에 필요하다.
기민한 독자들은 벌써 약간의 논리적인 문제가 있다는 것을 눈치챘다. 분명 다른 파일시스템에 마운트될 수 없는데, 첫번째 파일시스템(루트 디렉토리를 포함하기 때문에, root 파일시스템이라 불린다.)은 어떤게 마운트되는가? 글쎄 답은 마술에 의해 이루어진다이다. [1] 루트 파일시스템은 마술같이 부트타임에 마운트되고, 루트 파일시스템이 항상 마운트될 것이라고 믿을 수 있다. 루트 파일시스템이 마운트될 수 없다면, 시스템은 부팅되지 않는다. 루트로 마술처럼 마운트되는 파일시스템의 이름은 커널에 컴파일되어 들어가거나, LILO나 rdev를 이용해서 지정한다.
보통 루트 파일시스템은 처음에 읽기만 되도록 마운트된다. 그리고나서,시작 스크립트는 루트 파일시스템의 타당성을 검증하기 위해 fsck를 실행할 것이고, 만약 문제가 없다면, 시작스크립트는 루트 파일시스템을 쓰기가 허용되도록 루트 파일시스템을 다시 마운트할 것이다. fsck는 마운트된 파일시스템에서는 행해지면 안된다. fsck가 돌아가는 동안에 파일시스템에 어떤 변화가 있으면 문제를 일으킬 것이기 때문이다. 루트 파일시스템이 체크되는 동안에 루트파일시스템은 읽기전용으로 마운트되어 있기 때문에, fsck는 걱정없이 어떤 문제라도 고칠 수 있다. 다시 마운트하는 작업은 파일시스템이 메모리에 저장했던 어떤 중간에 생긴 데이타라도 방출해 버릴 것이다.
많은 시스템에는 부팅시간에 자동으로 마운트되어야할 다른 파일시스템이 있다. 그런 파일시스템들은 /etc/fstab 파일에 명시되어 있다. 형식에 대한 자세한 것을 위해서는 fstab메뉴얼페이지를 봐라. 여분의 파일시스템이 마운트될 때 정확한 세부사항들은 많은 인수에 의존하고, 필요하다면 각 관리자에 의해 설정될 수 있다. 이에 대한 자세한 내용은 Chapter 6을 보기 바란다.
파일시스템이 더 이상 마운트될 필요가 없을 때, umount라는 명령으로 마운트를 풀 수 있다. [2] umount는 한개의 인수를 취한다. 장치파일이나 마운트된 곳이다. 예를 들어 전 예에서 마운트한 디렉토리들의 마운트를 풀고 싶다면, 다음 명령을 사용할 수 있다.
$ umount /dev/hda2 $ umount /usr $ |
명령을 어떻게 사용하지는 더 많은 지시들을 원하면 메뉴얼페이지를 봐라. 항상 마운트된 플로피의 마운트를 풀어야하는 것은 꼭 해야할 일이다. 드라이브에서 플로피를 그냥 꺼내지 마라! 디스크 캐쉬때문에 플로피를 마운트 풀기 전까지 데이타가 플로피에 기록될 필요는 없어서, 드라이브에서 플로피를 너무 빨리 제거하는 것은 플로피 내용이 왜곡되게 할지도 모른다. 만약 플로피에서 읽기만 했다면, 그렇지 않겠지만, 만약 기록했다면, 우연일지라도, 결과는 재앙일지도 모른다.
마운트하기와 마운트 풀기는 슈퍼유저 권한을 필요로 한다. 즉 오로지 root만 할 수 있다. 만약 어떤 유저가 플로피를 어떤 디렉토리에 마운트할 수 있다면, /bin/sh이나 어떤 때때로 사용되는 다른 프로그램으로 위장된 트로이의 목마를 넣어 플로피를 만드는 것이 다소 쉬워지기 때문이다. 하지만 때때로 사용자들에게 플로피를 사용하도록 허가하는 것이 필요하고, 몇가지 방법이 있다.
사용자들에게 루트패스워드를 알려준다. 분명 보안상 나쁘지만, 가장 쉬운 방법이다. 어쨌든 보안이 필요없다면 잘 작동할 것이고, 많은 네트웍에 연결이 안되어 있는 개인 시스템들의 경우이다.
사용자들이 마운트를 할 수 있도록 sudo같은 프로그램을 사용한다. 역시 보안상 나쁘지만, 슈퍼유저 권한을 모든 사람들에게 직접 주지 않는다. [3]
사용자들에게 mtools를 사용하게 한다. 플로피를 마운트하지 않고 MS-DOS파일시스템을 다루는 패키지이다. 만약 MS-DOS플로피가 필요한 모든 것이라면 잘 작동하지만, 그렇지 않다면, 다소 곤란하다.
/etc/fstab 안에 적당한 옵션과 함께 플로피 장치와 허용가능한 마운트 지점을 함께 적어둔다.
/dev/fd0 /floppy msdos user,noauto 0 0 |
noauto 옵션은 시스템이 시작할 때 마운트가 자동으로 되는 것을 막는다(즉, mount -a로 마운트하려고 하는 것을 막는다.). user 옵션은 어떤 사용자라도 파일시스템을 마운트하게 하지만, 보안 때문에, 프로그램(보통 프로그램이나 setuid된 프로그램)의 실행과 마운트된 파일시스템에서 장치파일들을 해석하는 것을 막는다. 위와같이 하고나면, 어떤 사용자라도 다음 명령으로 msdos파일시스템을 가지고 있는 플로피를 마운트 할 수 있다.
$ mount /floppy $ |
만약 몇가지 형식의 플로피에 접근을 제공하길 원한다면, 몇개의 마운트 지점을 줄 필요가 있다. 설정은 각 마운트 지점마다 다를 수 있다. 예를 들어, MS-DOS와 ext2 플로피 모두에 접근하게 하려고 한다면, /etc/fstab에 다음과 같은 줄을 첨가할 수 있다.
/dev/fd0 /dosfloppy msdos user,noauto 0 0 /dev/fd0 /ext2floppy ext2 user,noauto 0 0 |
fsck로 파일시스템 완전성(integrity) 체크하기
파일시스템은 복잡한 창조물이고, 창조물이 그렇듯이, 어딘지 문제를 일으키는 경향이 있다. 파일시스템의 정확성과 타당성은 fsck를 통해 체크될 수 있다. fsck가 발견하는 어떤 작은 문제들을 해결하고 , 수리할 수 없는 어떤 문제가 있으면 사용자에게 경고하기 위해 명령을 내릴 수 있다. 다행히도, 파일시스템을 이루는 코드는 다소 효율적으로 디버깅되어서, 좀처럼 어떤 문제도 없고, 전원이 꺼진다던가, 하드웨어가 잘못되었던가, 운영자가 실수했다던가 하는 이유로 문제가 발생한다. 예를 들어 시스템을 적절히 종료시키지 않으면 문제가 발생한다.
대부분의 시스템들은 fsck를 부팅할 때 자동적으로 실행하도록 설정되어, 시스템이 사용되기 전에 어떤 에러라도 발견된다(그리고 다행히도 고쳐진다.). 망가진 파일시스템을 사용하는 것은 일을 더 나쁘게 만드는 경향이 있다. 만약 자료구조가 한번 뒤집히면, 파일시스템을 사용하는 것은 아마도 더 많은 자료 손실을 일으키며, 파일시스템을 더욱더 뒤집어지게 만들 것이다. 그러나 fsck는 큰 파일시스템에서 돌아가는데 약간 시간이 걸릴 수 있으며, 만약 시스템이 적절히 종료되었다면 문제는 거의 절대 일어나지 않기 때문에, 다음과 같은 경우에 체크를 피하기 위해 몇가지 트릭이 사용된다. 첫째로 /etc/fastboot라는 파일이 있다면, 체크를 하지 않는다. 둘째로 ext2파일시스템은 파일시스템의 슈퍼블럭안에 파일시스템이 이전 마운트 후에 적절히 마운트를 풀었는지 알려주는 특별한 표시를 가지고 있다. 만약 표시가 마운트가 풀어졌음을 가리킨다면(적절하게 마운트를 푼다는 것은 문제가 없음을 가리킨다라고 가정), 이 표시는 e2fsck(ext2 파일시스템을 위한 fsck버전)가 파일시스템을 점검하는 것을 피하게 한다. /etc/fastboot 방법이 시스템에서 작동하는지 않하는지는 시작스크립트에 달려있지만, ext2방법은 e2fsck를 사용하는 모든 경우에 작동한다. 피하려면 e2fsck를 옵션을 주어 명백하게 통과해야 한다.(어떻게 하는지 자세한 것을 원하면 e2fsck 매뉴얼페이지를 봐라.)
자동 체크는 부팅시에 자동으로 마운트되는 파일시스템에서만 작동한다. 다른 파일시스템들, 예를 들어 플로피를 체크하려면 fsck를 수동으로 사용해라.
만약 fsck가 복구할 수 없는 문제를 발견하면, 파일시스템이 일반적으로 동작하는 방법과 특히 망가진 파일시스템의 형식에 대한 깊은 지식이 필요하거나, 백업을 잘 하는 것이 필요하다. 후자는 해결하기 쉽고(비록 때때로 지겹지만), 전자는 만약 당신 자신이 하는 방법을 모른다면, 때때로 친구, 리눅스 뉴스그룹, 메일링리스트나 다른 지원책을 통해 해결될 수 있다. 더 말해주길 원하지만, 교육과 경험의 부족으로 힘들다. Theodore T'so가 만든 debugfs 프로그램이 유용할 것이다.
fsck는 마운트가 안된 파일시스템에서만 행해져야 하고, 마운트된 파일시스템에서는 해서는 안된다(시작시 읽기전용으로 마운트된 root를 제외하고). fsck가 원시디스크를 건드려서, 운영체제의 인지없이 파일시스템을 수정할 수 있기 때문이다. 만약 운영체제가 혼동한다면 문제가 있을 것이다.
badblocks로 디스크 에러를 검사하기
주기적으로 배드블럭을 검사하는 것은 좋은 생각일 수 있다. badblocks 명령으로 행해진다. badblocks는 찾아낼 수 있는 모든 배드블럭의 번호 리스트를 결과로 내놓는다. 배드블럭리스트는 파일시스템 데이타 구조안에 저장되기 위해 fsck로 입력될 수 있어서 운영체제는 데이타를 저장하기 위해 배드블럭을 사용하려고 하지 않을 것이다. 다음 예는 어떻게 행해지는지 보여줄 것이다.
$ badblocks /dev/fd0H1440 1440 > bad-blocks $ fsck -t ext2 -l bad-blocks /dev/fd0H1440 Parallelizing fsck version 0.5a (5-Apr-94) e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Check reference counts. Pass 5: Checking group summary information. /dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED ***** /dev/fd0H1440: 11/360 files, 63/1440 blocks $ |
디스크가 조각나는 것과 싸우기
디스크에 한 파일이 쓰여질 때, 파일이 항상 연속되는 블럭에 쓰여질 수는 없다. 연속적인 블럭에 저장되지 않은 파일은 조각난(fragmented) 것이다. 조각난 파일을 읽는 것은 약간 시간이 더 걸린다. 디스크의 읽기쓰기 헤드가 더 많이 움직여야 할 것이기 때문이다. 미리 읽기 기능을 가진 좋은 버퍼캐쉬를 지닌 시스템안에서는 문제가 작아지지만, 조각나는 것을 피하는것이 바람직하다.
블럭들이 연속되는 섹터안에 저장되지 못할지라도, 파일안의 모든 블럭이 같이 가까이 있도록 하면서, ext2파일시스템은 조각나는 것을 최소로 유지하려고 시도할 것이다. ext2는 효율적으로 항상 파일의 다른 블럭에 가장 가까운 여분의 블럭들 할당할 것이다. 그래서 ext2를 위해선 좀처럼 조각나는 것에 대해 걱정할 필요가 없다. ext2파일시스템 조각모으기를 위한 프로그램이 있기는 하다.
조각난 것을 제거하기 위해 블럭들을 파일시스템 둘레로 옮기는 많은 MS-DOS 조각모으기 프로그램들이 있다. 다른 파일시스템을 위해서는 조각모으기는 파일시스템을 백업하고, 다시 만들고, 백업한 것에서 파일들을 다시 저장하는 과정을 통해 이루어져야 한다. 조각모으기 전에 파일시스템을 백업하는 것은 모든 파일시스템에 좋은 생각이다. 조각모으기를 하는 동안 많은 것들이 잘못될 수 있기 때문이다.
모든 파일시스템들을 위한 다른 도구들
약간의 다른 도구들 역시 파일시스템들을 다루는데 쓸모있다. df는 하나 혹은 더 많은 파일시스템들의 여분의 디스크공간을 보여준다. du는 얼마나 많은 디스크공간이 디렉토리와 디렉토리안의 파일들이 포함하고 있는가를 보여준다. 이런 것들은 디스크공간을 낭비하는 것들을 잡아낼 때 사용할 수 있다.
sync는 버퍼캐쉬(the section called 버퍼 캐쉬 in Chapter 5을 보라.) 안의 모든 기록되지 않은 블럭들이 디스크에 기록되도록 한다. 수동으로 하는 것은 좀처럼 필요치 않다. 데몬 작업인 update가 자동으로 해준다. 큰 문제가 있을 경우, 예를 들어 update나 update를 도와주는 작업인 bdflush가 죽었다거나, 전원을 당장 꺼야 하는데 update가 돌아갈 시간까지 기다릴 수 없다면, 쓸모 있을 것이다.
ext2파일시스템을 위한 다른 도구들
직접적 혹은 파일시스템 형식에 독립적인 전위 프로그램을 통해서 접근할 수 있는 파일시스템 만드는 도구(mke2fs)와 파일시스템을 검사하는 도구(e2fsck) 외에도 ext2파일시스템은 사용할 수 있는 약간의 추가되는 도구를 가지고 있다.
tune2fs는 파일시스템 매개변수를 조절한다. 재미있는 매개변수들 중 일부는 다음과 같다.
최대 마운트 수. e2fsck는 슈퍼블럭에 있는 표시가 깨끗하더라도(역자 주: 즉 지난 번 마운트한 후 마운트가 적절히 풀어졌더라도) 파일시스템이 너무 많이 마운트되었으면 검사하도록 한다. 개발이나 시스템을 테스트하기 위해 사용되는 시스템이라면, 이 제한을 줄이는 것이 좋을 지도 모른다.
검사 사이의 최대 시간. e2fsck는 표시가 깨끗하고, 파일시스템이 매우 가끔씩 마운트되지 않는다면, 두번의 검사사이의 최대 시간을 요구한다. 하지만 못하게 할 수도 있다.
root를 위해 남겨둔 블럭 수. 파일시스템이 다 찬다면 어떤 것들을 지울 필요없이 시스템관리가 여전히 가능하게 하기 위해 ext2는 루트를 위해 약간의 블럭을 남겨둔다. 남겨둔 양은 기본적으로 5%인데, 대부분의 디스크에서 낭비하기에 충분하지 않다. 그러나, 플로피에는 남겨둘 블럭이 아주 조금도 없다.
dumpe2fs는 대개 슈퍼블럭으로부터, ext2파일시스템에 대한 정보를 보여준다. Figure 4-5는 한가지 실례이다. 실행 결과안의 어떤 정보는 기술적이고 파일시스템이 어떻게 작동하는지에 대한 이해가 필요하지만, 많은 양이 쉽게 이해할 수 있다.
Figure 4-5. dumpe2fs가 보여주는 출력의 한 예
dumpe2fs 0.5b, 11-Mar-95 for EXT2 FS 0.5a, 94/10/23
Filesystem magic number: 0xEF53
Filesystem state: clean
Errors behavior: Continue
Inode count: 360
Block count: 1440
Reserved block count: 72
Free blocks: 1133
Free inodes: 326
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 360
Last mount time: Tue Aug 8 01:52:52 1995
Last write time: Tue Aug 8 01:53:28 1995
Mount count: 3
Maximum mount count: 20
Last checked: Tue Aug 8 01:06:31 1995
Check interval: 0
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
Group 0:
Block bitmap at 3, Inode bitmap at 4, Inode table at 5
1133 free blocks, 326 free inodes, 2 directories
Free blocks: 307-1439
Free inodes: 35-360
debugfs는 파일시스템 디버거이다. 디스크에 저장된 파일시스템 데이타구조에 직접 접근하는 것을 허용해서 너무 깨져서 fsck가 자동으로 수리할 수 없는 디스크를 수리하는데 사용될 수 있다. 지워진 파일들을 복구하는데에도 사용되는 것으로도 알려져 있다. 그러나, debugfs는 하는 작업을 이해할 것을 너무 많이 요구한다. 이해하지 못하는 것은 모든 데이타를 파괴할 수 있다.
dump와 restore는 ext2파일시스템을 백업하는데 사용될 수 있다. dump와 restore는 전통적인 UNIX 백업툴들의 ext2 특유의 버전들이다. 백업에 대해 더 많은 정보를 원하면 Chapter 10를 보기 바란다.