유닉스나 리눅스 서버에서 서버의 이상이나 갑작스런 종료로 인해서 시스템의
파일시스템 이상으로 재부팅시 파일시스템이 마운트 되지 않는 경우가 종종 발생합니다.
위와 같은 경우 가장 많이 사용하는 명령어인 fsck에 관한 자세한 설명 입니다.
1. 파일시스템 점검 및 복구
부적절한 시스템의 중지(shutdown을 이용하지 않고 시스템 을 강제 종료하거나 정전에 의한 시스템의 예기치 않은 정지등의 이유)나 하드웨어상의 문제 발생시 파일시스템은 손상을 입게 된다. 이러한 경우 다시 시스템을 부팅하여 사용하기 이전에 "fsck" 명령 을 사용하여 시스템상의 모든 파일시스템을 점검하여 조치를 취하여야 한다.
* fsck 명령어의 점검사항
fsck 명령어는 다음과 같은 사항을 점검한다. fsck가 점검하는 부분이, 파일 시스템 전 체를 점검하기 때문에 fsck는 각 부분의 점검 (super block, i-node, indirect block, data block. free block 등)을 단계별로 나누어서 점검하게 된다. 비정상적인 시스템의 종료로 인한 정상적인 파일 시스템의 관리가 진행되지 못하였을 때는 이의 복구를 우선하여야 한다. 이러한 일련의 점검은 그 효 율을 증대하기 위하여 부분별로 나누어져 각 단계별로 진행된다.
| haitai# fsck /dev/rdsk/c0t3d0s7
| ** /dev/rdsk/c0t3d0s7
| ** Currentyly Mountes on /home
| ** Phase 1 - Check Blocks and Size
| ** Phase 2 - Check Pathnames
| ** Phase 3 - Check Connectivity
| ** Phase 4 - Check Reference Counts
| ** Phase 5 - Check Cly groups
| 314 file,14585 free (82 frags, 172 blocks, 0.3% fragmentation)
*phase 1 - Check Blocks and Sizes
파일시스템에 존재하는 파일에 대한 정보를 담고 있는 i-node 영역을 점검하는 단계로서 파일 유형의 이상 유무, 파일의 내용이 있는 디스크 블록의 주소, 파일의 크기, 파일의 링크여부를 점 검한다.
| Haitai# fsck /dev/rdsk/c0t3d0s7
| ** Last Mounted on /home
| ** Phase 1 - Check Blocks and Sizes
| PARTIALLY ALLOCATED INODE I=5
| CLEAR? Y
|
| UNKNOWN FILE TYPE I=768
| CLEAR? Y
|
| 5 DUP I=2306
| 6 DUP I=2306
| 7 DUP I=2306
| 8 DUP I=2306
| 9 DUP I=2306
부적절하게 할당된 i-node를 점검한다. 즉, i-node 리스트들이 점검되어진다.
파일 유형이 없을때 (i-node 768, 종종 디렉토리에서 발생) fsck는 파일시스템에 존재하는 파일에 대하여 i-node의 정보중 링크 계수가 '0'인 경우는 다음과 같은 메세지를 내보낸다.
| LINK COUNT TABLE OVERFLOW
| CONTINUE?
i- node에 의해 요구되어진 블록을 점검하는 동안 불량블럭, 중복 블록등이 발견될 경우 다음 메시지를 출력한 다.
| xxx BAD I=I 또는 yy DUP I=L
여기서 xxx은 잘못된 블록 주소 로서 이러한 잘못된 데이터 디스크 블록을 가지고 있는 파일을 점검할 때 나타난다. 여기에서 는 단지 메시지 출력만 있을 뿐 운용자에게 응답을 요구하지 않는다. 그러나 운용자는 이 i-node 번 호를 기억해 두는 것이 좋다.
나중에 중복 블록에 대한 파일의 점검시에 제거할 수 있는 파일을 결정해야하기 때문이다.
*Phase 2 - Check Pathname
화일시스템에 디렉토리 를 점검한다. 루트 디렉토리하의 모든 디렉토리에 대하여 디렉토리의
구조를 점검하여 각 화일 들의 이름과 i-node 링크에 대한 이상 유무를 검진한다.
| - Phase 2 - Check Pathname
| UNALLOCATED I=768 OWNER=root MODE=0
| SIZE=0 MTIME=Jul 15 16:18 1992
| NAME=/test
|
| REMOVE? y
디렉토리 엔트리들이 점검되어진다. 루트 디렉토리부터 시작하여 각 디렉토리 엔트리를 계층적으로 점검해 나간다. Phase 1에서 수집한 정보와 여기서 디렉토리 엔트리를 점검한 정보와 비교하면서 비교에서 어긋남이 있으면 에러 메세지 를 출력한다. 점검을 시작하는 i-node는 2번(root directory)부터 시작한다. 루트 파일시스템의 i- node 모드와 상태, 디렉토리 파일 내용의 이상 유무, 잘못된 i-node 링크수 등을 검사한다.
비 록 할당된 i-node를 가지고 있을지라도 루트가 디렉토리 유형이 아니고 일반적인 파일의 유형이라던 지 다른 4가지 형태라면 계층구조인 화일시스템에서는 각 경로들을 찾아갈수가 없을 것이다. 이러한 경우 출력되는 메세지는 다음과 같다.
| ROOT INODE NOT DIRECTORY
| FIX?
이러한 경우의 선택은 당연히 'y'가 되어야 할것이다. 그러면 fsck는 루트의 파일 유형을 디렉토리 파일의 유형으로 변환시켜 줄것이다. 이 상황에서 루트 i-node 에 문제가 발생했다면 다음 메시지를 출력시킨다.
| DUPS/BAD IN ROOT INODE
| CONTINUE?
Phase 1과 Phase 1B에서 루트 i-node에서 이 중블럭이나 잘못된 블록이 발견 되어진 결과로 발생하는 메시지이다. 여기서 'y' 라고 입력하 여 그것을 없애 버린다.
Phase 2 동안 계층적으로 찾아 들어가고 있는 동안 Phase 1에서 나타났던 잘못된 블록이나 중복된 블록을 가지고 있는 i-node를 발견시 그때의 메시지 출현은 다음 과 같다.
| DUP/BAK I=00 OWNER=0 MODE=M SIZE=S
| MTIME=T FILE=/important
| REMOVE?
Phase 1에서 불량/중복 블록 주소를 기록하지 않았다면 이 i-node가 불량인지 중복인지 구별할 수가 없다. 여기 서 운영자는 신중한 결정을 해야한다. 데이터를 보존하여 둔 것이 있었으면 당연히 없애버리고 다시 회복 시킬수가 있지만 그렇지 않을 경우에는 'n'이라고 입력한 뒤에 백업을 받고 fsck를 다시 실행시 키는 것이 좋을 것 같다.
그것이 잘못된 블록이라면 cp명령어가 소용 없게 된다. cp명령어는 잘 못된 블록의 주소를 가지고는 더 이상 진행하지 못하기 때문이다.
만일 fsck 수행중 i-node넘버 만 알 수 있고 그 파일의 이름을 모르는 경우에는 ncheck 명령으로써 파일 이름을 확인할 수있 다.
*Phase 3 - Check connentivity
파일시스템에 디렉토리를 점검하여 만약 디렉토 리의 구조가 잘못되어 파일 이름과 i-node 링크 항목의 디렉토리 항목이 없을시 이를 복구한 다.
| **Phase 3 - Check Connectivity
| UNFER DIR - =769 OWNER=root MODE=40775
| SIZE=512 MTIME=May 12 15:27 1991
| RECONNECT? Y
|
| DIR I=769 CONNECTED. PATENT WAS I=768
| UNFER DIR I=1536 OWNER=root MODE=40775
| SIZE=512 MTIME=Jun 8 10:42 1991
| RECONNECT? Y
|
| DIR I=1536 CONNECTED. PARENT WAS I=768
|
| DUP/BAD I=2306 OWNER=987 MODE=100640
| SIZE=4096 MTIME=May 11 10:43 1991
| FILE/lost+found#1536/ASA/test11
| REMOVE? Y
Phase 2 에서 계층적으로 찾아들어가는 동안 발견 못했던 디렉토리 i-node에 대한 이름 을 만드는 즉, 디렉토리 연결자체와 관계되는 부분이다. 참조할 수 없는 디렉토리 또는 lost+found 디 렉토리에 연결할 수 없는 것 등에 의한 오류등이다.
i- node에 대해 디렉토리 엔트리를 더 한다. 그러한 i-node를 발견하였을 때의 메시지는 다음과 같다.
| UNREF DIR I=769 OWNER=root MODE=40775
| SIZE=512 MTIME=May 12 15:27 1991
| RECONNECT?
여기서 'n'라고 입력하면 현 오류상태가 무시된 다. 이때는 항상 다음 Phase에서 UNFER 오류를 발생한다. 되도록 'y'라고 답하는 것 이 좋을 것이다.
만일 그 i-node가 비어있다면 요구상황 없이 그 파일을 없애버린 다.
Lost+found 디렉토리에 연결이 무사히 진행되었으면 CONNECTED라고 메시지가 다음과 같 이 출력된다. 추후에 lost+found 디렉토리를 점검하여 조치를 취해야 한다.
| DIR I=769 CONNECTED. PARENT WAS I=768
*Phase 4 - Check Reference Counts
파일시스템 관리 정보를 담고 있는 슈퍼 블록내의 파일 할당 수와 디렉토리 들을 점검하여 조사된 파일들의 수를 비교, 이상 유무를 검진하여 복구한다.
| Phase 4 - Check Reference Counts
| LINK COUNT DIR I=2 OWNER=root MODE=40775
| SIZE=512 MTIME=May 13 15:53 1991
| COUNT 4 SHOULD BE 3
| ADJUST? Y
|
| UNREF DIR I=787 OWNER=root MODE=100644
| SIZE=728 MTIME=Jun 13 13:42 1991
| REVONNECT? Y
|
| UNREF DIR I=788 OWNER=root MODE=100644
| SIZE=1126 MTIME=Apr 23 09:31 1991
| RECONNECT? Y
|
| DUP/BAD I=2306 OWINER=987 MODE=100640
| SIZE=4096 MTIME=May 11 10:43 1991
| FILE=/lost+found/#1536/ASA/test11
| CLEAR? y
이 과정은 Phase 2 에서 디렉토리 엔트리를 찾아가면서 계산되 어진 링크계수와 각각의 i-node에 있는 링크 카운터 값과 일치하여야 하는데 값이 같지 않을 경우 오 류 메시지를 출력하는 것이다.
0이 아난 링크 카운트를 가지지만 디렉토리 엔트리를 계층적으로 찾아갈 때 발견하지 못한 i-node를 발견하였다면 그것을 lost-found 디렉토리에 연결할 것인지 물을 것이다.
(그 i-node가 비워 있지 않을 경우에) fsck는 Phase 2,3 동안 실제 디렉토리 엔트리의 링크 카운트를 계산한다. 두 값의 비교로 같으면 상관없지만 틀릴경우 메시지는 다음과 같 다.
| LINK COUNT DIR I=2 OWNER=root MODE=40775
| SIZE=512 MTIME=May 13 15:53 1991
| SOUNT 4 SHOULD BE 3
| ADJUST?
여기서는 'y'를 입력하여 틀린 링크 카운트를 정확하게 맞추어야 한다.
Phase 4 수행도중 다음과 같은 오류 메시지가 발견되었다고 가정해 보 자.
| UNREF DIR I=787 OWNER=root MODE=100644
| SIZE=728 MTIME=Jun 13 13:42 1991
| RECONNECT?
이 메시지는 디렉토리 엔트리에 의해 참조되지 않은 파일이 존재 한다는 것이다. 즉, i- node 수치가 787인 파일이 디렉토리 엔트리에 연결되어 있지 않는 경우이다.
다시 재연결할것인 지 묻는 것은 이 파일을 lost-found 디렉토리에 연결 시킬것인가를 묻는 것이다. 'y'라는 대답으로 일 단은 lost+found에 옮겨 놓는 것이 좋다.
*Phase 5 - Check Cyl groups :
슈퍼 블록에서 관리하고 있는 프리 블록 리스트(파일의 데이터 생성내지 추가시 할당을 받을 수 있는 파 일 시스템 영역)과 현재 파일의 데이터가 점유하고 있는 디스크 블록들이 중복되는지를 점검하여 진 행한다.
| ** Phase 5 - Check Cyl groups:
| FREE BLK COUNT(S) WRONG IN SUPERBLK
| SALVAGE? Y
|
| 10744 files, 143872 used, 18518 free
| (1422 frage, 2137 blocks, 0.9% fragmentation)
| ***** FILE SYSTEM WAS MODIFIED*****
여 기서의 주임무가 프리블럭 리스트를 점검하는 단계다.
모든 블록들은 i-node에서 주소로 기록되 어 있거나 아니면 free block list에 기록되어 있어야 한다. 프리블럭 리스트 내의 비정상적인 블록 정 보, 프리 블록 리스트의 블록과 파일에 할당된 데이터 블록과의 중복등의 사항을 점검한다. 만약 Phase 4 동안에 어떤 i-node를 제거시켰을 때는 그 i-node를 제거시켰을 때는 그 i-node는 현재 파 일이 있지도 않고 프리블럭 리스트에도 등록이 되어 있지도 않을 것이다.
이럴 경우 하나의 에 러 메시지가 출현할 수 있는 요소가 된다.
1 BAD BLKS IN FREE LIST
중복블럭 이 발생했을 경우도 마찬가지로 진행되며 메시지의 출현은 다음과 같다.
2. DUP BLKS IN FREE LIST
만일 비어있지않는 i-node를 지워버릴 경우에는(fsck에서나 또는 clri를 통하 여) i-node의 주소비트에서 할당되지도 않았고 free block list에도 할당되지 않는 경우가 발생될 수 있다.
그럴 경우에 출현될 수 있는 메시지는 다음과 같다.
00 BLK(S) MISSING
슈퍼 블록내의 프리 블록 리스트를 관리하고 있는 내용이 잘못된 경우 다음과 같 이 나올 수 있다.
| FREE BLK COUNT(S) WRONG IN SUPERBLK
| SALVAGE?
이런 메시지를 발견 했을 경우의 대답은 되도록이면 'y'라고 답 하는 것이 좋다.
슈퍼 블록에 저장되어 있는 free list에서 범위를 벗어난 블록이나 중복된 블록 이 fsck 프로그램에서 허용, 정의한 10개가 초과 했을 경우는 bad, dup block이 excessive(초과) 했 다는 메시지가 출현된다.
| EXCESSIVE BAD BLKS IN FREE LIST
| EXCESSIVE DUP BLKS IN FREE LIST
| CONTINUE?
이때에는 'y'를 선택하면 free block list의 나머지가 무시되고 fsck는 계속 진행된 다.
Phase 5에서 발견된 프리 블록 리스트의 비정상적인 블록, 중복 블록, 중복되지 않은 프리블 럭등에 의해 발생되는 에러에 의하여 항상 나타나는 메세지로서 만일 '-q' 옵션을 지정하면 프리블 럭 리스트는 자동적으로 제거된다.
그렇지 않는 경우는 다음과 같이 나타난다.
| BAD FREE LIST
| SALVAGE?
여기에서 'y'를 입력하 면 실제의 free block list가 새롭게 free block list로 등록된다
