파일 검사&수리 명령어(fsck, e2fsck)과 파일 시스템 손상 상황 등+ 관련 문제

오늘 배워볼 명령어는 파일 검사 및 수리 명령어입니다.

fsck와 e2fsck

요 명령어들은 파일을 검사하거나 수리해주는 명령어예요

사실 파일 검사는 부팅할 때 자동으로 리눅스가 파일 시스템을 점검해줘요. 그리고 손상된게 있으면 알아서 자동으로 복구도 해줍니다..

서버를 운영하지 않는 사람들은 딱히 쓸일은 많지 않지만.. 서버에서는 비상사태를 복구하는 것만큼 중요한게 없죠

중요한 명령어입니다 :)

fsck

(filesystem check )

리눅스 파일 시스템을 검사하고 수리하는 명령어

e2fsck = fsck의 확장 명령어

# fsck [option] 장치명

# e2fsck [option] 장치명

e2fsck가 확장버전이기 때문에 실질적으로 현재 리눅스 배포판에서 fsck명령 실행하면 e2fsck가 실행돼요.

fask명령은 손상된 디렉터리나 파일을 수정할 때 임시로  /lost+found 디렉터리에서 작업을 수행하고 정상적인 복구가 되면 사라집니다.

fsck 명령어를 수행하면 내부적으로 동작 단계는 다음과 같습니다.

시작

단계1 - 블록들과 파일 크기 검사

단계2a - 중복된 이름이 있는지 검사

단계2b - 경로명 검사

단계3 - 연결성 검사

단계3b - Shadows/ACLs 인증

단계4 - 참조 수 검사

단계5 - 싸이클 그룹 검사

그릏구나~~ 대강 어느 단계에서 어떤 걸 점검하면서 이상 유무를 확인하는 과정입니다.

자세한 내용이 더 필요한 사람은 fsck 명령어의 수행 과정 문서 참조 (링크)

fsck 실행 시 중요한거!

fack/e2fsck 명령어를 사용할 때는 마운트된 드라이브에서는 절대절대 사용하면 안됩니다. 만약에 마운트된 드라이브에 fsck를 수행하면 그 드라이브는 평생 망가질 확률이 높다고 보면 돼요.

그러므로 fsck를 수행하기 전에는 꼭! unmount작업을 해준 후 수행합시다.

fsck를 한 번 사용해볼까요?

자 먼저 df 명령어로 마운트 되어있는지 확인하고

재부팅으로 마운트가 현재 연결되지 않은 /dev/sdb1의 디스크에 fsck를 수행했어요

마지막 줄에 clean이라고 떴죠? 에러가 없다는 전혀 손상되지 않고 잘 있다는(?) 뜻입니다.

에러코드의 종류와 의미는 이러해요

에러가 있을 경우는 clean부문이 'error 2,'처럼 error + 숫자 형식으로 뜹니다.

마운트 되어 있을 경우에 수행하면 어떻게 뜰까요? (마운트가 무엇인지? 어떻게 마운트 하는지는 이전 포스팅을 참고해주세요)

저번에 파티션 및 포맷 설정은 다 해줬으니 mount 명령어를 이용해서 재부팅으로 초기화된 마운트를 다시 연결해줬어요

df 명령어가 마운트가 잘 됐음을 보여주네요

우분투에서 fsck를 실행해줬더니!! 마운트되어있기 때문에 할 수 없다고 나옵니다

실제에서는 이러다가 망가지면 큰일나니 왠만하면 마운트된 상태에서는 하지 맙시다 !

이렇게 마운트되어 있을 경우 umount 해준 후 진행하기! 

umount 하니까 fsck 명령어가 잘 작동된 것을 확인할 수 있습니다.

자 그러면 어떤 상황에 주로 파일이 손상될까요?

1) 시스템이 갑자기 shutdown! 갑자기 서버가 중지됐을 때, 전원이 나가버렸을 때 등등 이럴 때 파일 시스템이 손상을 입을 수 있습니다. 이럴 경우 서버의 갑작스런 종료로 인해 생겨난 파일 시스템 이상으로 재부팅시 파일시스템이 마운트되지 않는 경우가 종종 발생합니다. 이럴 경우 다시 시스템을 부팅하여 사용하기 이전에 fsck명령을 사용해 시스템상의 모든 파일 시스템을 점검하여 조치를 취해야 합니다.

하지만 요새 경우는 최신 저널링 파일 시스템 덕분에 충돌나서 다운되도 사실 fsck 안해줘도 된다네요. 좋아진 세상 ㅎㅎ

(저널링 파일 시스템은 파일 시스템에 대한 변경사항을 반영하기 전에 저널이라 부르는 로그에 변경사항을 저장하여 추적이 가능하게 만든 파일 시스템입니다.)

2) Clearing group locks improperly

- 두 프로세스가 인지하지 못한채 동시에 서로 내부 구조나 내용을 변경했을 때 (lock이 제대로 안된 상황에 발생되겠죠)

3) Overriding the built-in file protection mechanisms

다른 프로세스에 의해서 한 파일이 열려있는 상태인데 그 상황에서 다른 프로세스가 그 파일을 삭제하려고 할 때

4) System debugger when used incorrectly

시스템 디버거가 잘못쓰여졌을 때

등등

이런 사항들에서 파일 손상이 일어날 수 있다네요 ㅎ 이해가 안가면 그냥 그러려니 읽고 넘어가면 됩니다.

옵션 알아보기

두 명령어의 옵션은 다음과 같습니다

옵션	내용
-a	명령 수행에 대한 확인 질문 없이 무조건 수행한다. (권장하지 않음)
-v	점검 내역 상세 보기 , 자세한 출력
-y	모든 응답을 다 yes로 해서 자동으로 실행하는 거  Attempt to fix detected problems automatically
-n	모든 질문에 대한 응답을 no로 취급한다 (체크만 하는 거)  Avoid Repair, but Report Problems to Stdout
-f	파일 시스템이 이상 유무에 상관 없이 강제적으로 파일 시스템을 체크   Force a Filesystem Check Even if it's Clean

더 많은 명령어가 있지만 그 외 명령어는 메뉴얼을 참조하도록 합시다

-f옵션을 사용한 것

fsck -f /dev/sdb1와 같아요

문제

2016년 1회 리눅스마스터 기출

다음 ( 괄호 )안에 들어갈 내용으로 알맞은 것은?

---------------------------------------------------------------------------

fsck 명령은 리눅스 파일 시스템을 검사하고 수리하는 명령이다. fsck 명령은 손상된 디렉터리나 파일을 수정할 때 임시로 ( 괄호 ) 디렉터리에 작업을 수행하고 정상적인 복구가 되면 사라진다.

---------------------------------------------------------------------------

1. /found

2. /lost+found

3. /lost

4. /lost-found