파일시스템디버깅 툴 debugfs를 활용한 삭제파일복구 실무

제목 : 파일시스템디버깅 툴 debugfs를 활용한 삭제파일복구 실무

 

debugfs의 실무사용과 삭제파일 복구 개론

 

자, 이제 조금 어렵게 느끼지도 모르는 debugfs에 대해서 알아보도록 하겠다. 먼저 debugfs는 ext2와 ext3파일시스템을 대상으로 디버깅을 할 수 있는 대화형 파일시스템 디버깅툴이다. debugfs의 정식 이름은 ext2/ext3 파일시스템 디버거”(ext2/ext3 file system debugger)이다.  참고로 레드햇리눅스9버전까지의 debugfs는 ext2전용이었지만 현재 Fedora버전 이상에서는 ext2와 ext3 모두에서 사용가능 한다.

 

하지만 현재 debugfs에서 ext3저널링파일시스템을 대상으로 작업하려면 debugfs의 logdump명령어(man page : Dump  the contents of the ext3 journal)를 사용하셔야 한다. 솔직히 아직까지는 debugfs는 ext2에서 제기능을 발휘한다라고 할 수 있다.

 

쉽게 말씀드려서 debugfs의 버전이 1.35이상 버전에서만 ext2와 ext3를 모두 지원한다. 즉, debugfs는 ext2/ext3로 생성된 파일시스템을  대상으로 디버깅하거나 삭제파일을 복구하는 용도로 사용된다.  쉽게 말씀드려서 debugfs란 ext2/ext3파일시스템에서 사용되는 파일시스템을 검사하고 변경할 수 있는 유틸리티라는 것이다. debugfs로 삭제된 파일을 복구할 수도 있으며(100%는 아님) 수퍼블럭(superblock)의 상태를 확인할 수도 있고 inode를 대상으로 물리적인 측면에서의 파일조작작업도 할 수가 있다. 한마디로 말씀드린다면 debugfs는 특정 파일시스템 내부의 inode를 대상으로 파일작업을 하는 것이라고 할 수 있다.  흔히 debugfs가 파일을 복구하는 유틸리티라고 생각하시지만 파일복구는 debugfs로 할 수 있는 여러가지 작업중의 하나일 뿐이다. 즉, 약 50여개에 가까운 debugfs전용명령어 가운데 dump 또는 dump_inode라는 명령어에 의하여 삭제된 파일의 inode와 파일명을 연결함으로써 복구하는 것이다. 

 

따라서 debugfs 전용명령어가 매우 많으므로 그 용도와 역할을 정확하게 이해하고 실무에서의 활용법을 익혀두기 바란다.

 

이번 절에서는 debugfs에 대한 전반적인 활용법을 실무에서 사용되는 예를 중심으로 설명하도록 하겠다.

[주의사항] debugfs수행시 주의사항 1. debugfs는 root전용명령어이다. 따라서 일반사용자는 사용할 수 없다. 2. debugfs는 파일시스템의 수퍼블럭과 inode를 조작할 수 있으므로 파일시스템에 대한 전문적인 지식없이 함부로 작업하면 파일시스템의 손상으로 인하여 데이터유실 및 복구불능상태가 될 수도 있다. 3. 따라서 debugfs로 파일시스템 작업을 할 때에는 사전에 파일시스템에 대한 지식을 먼저 습득한 후에 사용하셔야 한다.

 

사용방법  : debugfs [-b blocksize][-s superblock][-f cmd_file][-R request][-V][[-w][-c][-i][장치명]]

debugfs의 맨페이지를 보면 실행방법이 위와 같이 표시되어 있다. 실행방법이 좀 복잡한 것처럼 보이지만 뒤에서 설명하는 예를 보면 실제사용은 아주 간단하다는 것을 알 수 있다.  여기서 장치명(device)은 반드시 /dev/hda3 나 /dev/sda5등과 같이 실제 디바이스 장치명을 지정하셔야 한다. 그리고 debugfs 사용시 파일시스템은 기본적으로 읽기전용모드로 열리게 된다. 하지만 w옵션을 사용하면 읽기와 쓰기모드로 파일시스템을 오픈할 수 있다. 또한 debugfs는 대화형 디버거이며 명령어 하나씩을 처리한다.

 

 

debugfs 읽기전용모드, 쓰기모드로 실행, 그리고 종료하기

 

debugfs 를 실행하는 방법에는 크게 두가지가 있다.  앞서 보셨던 방법은 아무런 옵션없이 그냥 “debugfs “를 실행시킨 것이고 이번에는 debugfs를 실행하면서 작업대상이 되는 파일시스템을 지정하여 동시에 오픈하는 방법으로 debugfs를 실행해 보도록 하겠다.

 

아래의 예는 /dev/hdb라는 파일시스템을 오픈하면서 debugfs를 실행한 것이다. 이때 -w옵션을 사용하지 않았기 때문에 /dev/hdb파일시스템은 읽기전용(read-only, 기본값)으로 열려지게 된다. 바로 다음의 예에서 설명드리겠지만 -w옵션을 함께 사용하면 파일시스템을 쓰기모드로 오픈하게 된다.

 

다음의 예는 /dev/hdb파일시스템을 오픈하면서 debugfs를 실행한 후에 ls로 파일리스트를 확인 하였다.  그리고 quit으로 debugfs모드를 종료한 것이다.

 

 

 

이번에는 debugfs를 실행하면서 /dev/sda3이라는 파일시스템을 오픈한 것이다.

 

 

 

debugfs 는 기본설정으로 -w 옵션없이 파일시스템과 함께 실행을 시키면 읽기전용(Read Only)모드로 파일시스템을 오픈한다. 일종의 안전장치인 셈이다. 만약 읽기/쓰기(read/write)모드로 파일시스템을 오픈 하려고 한다면 -w옵션을 사용하여 실행을 하도록 하십시오.

 

다음은 쓰기모드로 파일시스템을 오픈하면서 debugfs를 실행한 것이다. 이렇게 쓰기 모드로 오픈하게 되면 파일시스템의 변경이 가능하므로 각별한 주의가 필요한다.

 

[주의사항] debugfs를 이용한 파일복구시에 -w옵션 자제 꼭 필요한 경우가 아니라면 debugfs작업시 -w옵션 사용은 자제하는 것이 안전을 위하여 좋을 것이다.

 

아래의 예는 쓰기모드로 /dev/hdb라는 파일시스템을 오픈하면서 debugfs를 실행한 것이다. 그리고 ls로 파일리스트를 확인한 후에 quit으로 debugfs모드를 종료한 것이다.

 

 

 

 

debugfs를 이용한 삭제된 파일복구하기

 

자, 그럼 이제 debugfs를 이용한 삭제된 파일의 복구 방법의 실제 예를 보여 드리도록 하겠다.  필자가 선택한 파일은 아파치 설정파일인 httpd.conf파일로써 실제로 이 파일을 rm명령어로 삭제한 후에 debugfs로 복구하는 예를 들 것이다. 먼저 아래와 같이 rm명령어로 httpd.conf파일을 쉘상태에서 직접 삭제 하였다.

 

 

 

그리고 debugfs로 삭제된 httpd.conf파일을 복구하기 위하여 임시장소(/tmp)로 이동하였다. (가능한 debugfs의 실제작업은 /tmp 또는 임시 장소를 만들어서 작업 하기 바란다.)

 

 

debugfs를 이용하여 삭제된 파일을 복구하실 경우에는 삭제된 위치에서 복구작업을 하지 마십시오. 삭제된 위치에서 복구작업을 하실 경우에 다른파일들의 덮어쓰기로 인하여 원하는 실제파일이 영구적으로 삭제되어 버릴 수 있기 때문이다.  위의 예와 같이 /tmp가 아니라 하더라도 반드시 임시장소를 마련하여 복구작업을 하도록 하십시오. 그리고 원하는 파일을 복구한 후에는 생성날짜와 사이즈등을 삭제되기 전의 파일과 비교하여 원래있던 위치로 복사를 하거나 이동시키는 것이 올바른 방법임을 꼭 기억하기 바란다.

 

그리고 앞서 설명드렸던 바와 같이 삭제된 파일이 있었던 파일시스템을 대상으로 “debugfs -w /dev/sda1”과 같이 debugfs를 실행하기 바란다. 자, 여기서 앞서 배웠던 “lsdel”라는 debugfs명령어를 이용하여 아래 예와 같이 삭제된 파일들의 inode를 확인하실 수 있다.

 

 

 

실제로 서비스를 하고있던 리눅스서버라면 “lsdel”의 결과가 수없이 많을 수도 있다. 좀 황당 하시겠지만 수많은 이들 결과 중에서 삭제된 httpd.conf파일의 inode를 찾아내어서 복구해야 한다.

 

하지만 너무 비관적으로 생각하실 필요는 없다. 위의 예를 보시는 바와같이 inode에는 우리가 원하는 파일을 쉽게 유추할 수 있는 몇가지 유용한 정보들이 있다. 즉, 다음과 같은 정보들을 위의 결과에서 보실 수 있을 것이다.

 

        debugfs에서 제공되는 inode정보들

- Inode값

- 파일 소유자정보(UID)

                - 파일모드(Mode)

                - 파일사이즈(Size)

                - 위치한 블록(Blocks)

                - 파일이 삭제된 년,일,시(Time deleted)

 

“lsdel”로 출력되는 수많은 리스트들 중에서 위의 정보 중 삭제된 년,일,시 및 파일사이즈등과 같은 정보를 이용하여 복구하고자하는 파일(httpd.conf)의 inode값을 나름대로 유추가 가능하기 때문이다. 우리는 이들 정보를 이용하여 어떤 inode가 복구하고자하는(조금 전에 삭제하였던) 파일(httpd.conf)의 inode였는가를 유추하여 알아내야 한다.

 

필자의 경우 유용하게 사용하는 정보는 파일소유자(UID)와 파일사이즈(Size) 그리고 삭제된 년,일,시(Time deleted)이다.

 

위의 예에서 삭제한 파일(httpd.conf)의 삭제시간을 확인한 결과 삭제한 파일의 Inode값이 위의 결과 중 맨 마지막에 있는 “197794”임을 확인할 수 있었다. 실수로 삭제했던 파일을 복구할 때에는 거의 대부분 inode의 값이 최근 것이므로 삭제된 파일의 inode를 찾는데는 크게 어려움이 없다.

또한  필자가 삭제한 날짜에 해당하는 파일의 갯수가  8개 존재함을 알 수 있었다.

 

이렇게 복구할 inode를 찾았다면 이제 dump만 하면 된다.

아래와 같이 “dump_inode”라는 debugfs명령어를 이용하여 dump를 하였다.

 

 

위의 예를 보시는 바와 같이 dump하는 명령형식은 다음과 같다.

 

        dump_inode  <찾은inode번호>  “복구할 위치 및 파일명”

        또는

        dump  <찾은inode번호>  “복구할 위치 및 파일명”

 

위의 예에서 dump결과로 생성할 파일명(temp001.file)은 필자가 임의로 지정한 것이다.

위의 결과 inode번호 197794의 파일이 /tmp/temp001.file로 dump되어 /tmp에 저장된다.

그리고 앞서 배웠던 quit이란  debugfs명령어를 이용하여 debugfs모드에서 빠져 나왔습니다.

이제 다음과 같이 /tmp 디렉토리에서 다음과 같이 확인해 보면 temp001.file이라는 것이 생성되어 있으며 이 파일을 ls로 확인한 것이다.

 

 

그리고 다음으로 이 파일의 사이즈를 확인한 결과 삭제하기 전의 httpd.conf파일임을 확인하고  이 파일명을 httpd.conf로 변경한 후에 원래 있던 위치로 복사한 것이다.

 

 

 

이렇게 debugfs를 이용하면 실수로 삭제한 파일은 거의 대부분 삭제직후에 복구가 가능하다. 하지만 실제로 오래 전에 삭제된 파일을 복구할 수 있는 확률은 매우 낮으며 또한 확인하는 작업 또한 매우 번거롭습니다.

 

 

debugfs모드에서 삭제된 특정 디렉토리전체를 복구하기

 

이번에는 특정 파일이 아니라 삭제된 특정 디렉토리 전체를 원래 파일시스템으로 복구(dump)하는 예를 보도록 하겠다.  즉, debugfs의 rdump명령어를 이용하면 특정 디렉토리 전체를 원래파일시스템으로 dump할 수 있다. 앞의 예에서 debugfs로 오픈하였던 /dev/hdb라는 파일시스템에서 ls로 현재 위치의 파일리스트를 확인한 것이다. 그리고 이중에서 testdir이라는 디렉토리를 복구하기 위하여 “rdump testdir /tmp/testdir”이라고 한 것이다.  testdir은 대상디렉토리이며 /tmp/testdir은 복구되어 생성된 위치이다.

 

여기서 한가지 주의하실 것은 /tmp/testdir로 지정된 위치는 rdump하기 전에 미리 생성되어 있어야 한다.

 

 

 

그리고 이렇게 디렉토리전체가 복구된 것을 확인하기 위하여 debugfs모드에서 빠져나 온 후에 /tmp디렉토리를 살펴본 것이다.

 

여기까지의 설명은 debugfs를 이용한 삭제된 파일과 삭제된 디렉토리를 복구하는 방법에 대한 설명이다. 이후부터는 debugfs의 여러가지 기능들에 대한 설명이다. 앞에서 말씀드렸듯이 debugfs에는 삭제된 파일을 복구하는 기능만 있는 것이 아니라 파일시스템을 디버깅할 수 있는 여러가지 기능들이 있다. 이후 부터의 설명은 debugfs의 여러가지 기능들에 대한 설명이다.

 

 

debugfs모드에서 대상 파일시스템 쓰기모드로 오픈하기

 

debugfs를 실행 한 후에 특정 파일시스템을 오픈 할 수 있다. 아래의 예는 아무런 옵션없이 debugfs를 실행한 후에 /dev/hdb라는 파일시스템을 쓰기모드로 오픈한 것이다.  그런 다음 ls라는 debugfs명령어로 파일리스트를 확인한 것이다. (여기서의 ls명령어는 쉘 명령어상태에서의 ls가 아님. 즉 debugfs전용명령어로서의 ls이며  뒤에서 자세히 설명함)

 

 

 

 

debugfs모드에서 열려진 파일시스템 닫기

 

바로 앞의 예에서 debugfs모드에서 특정 파일시스템을 쓰기모드로 오픈 하였다. 이렇게 오픈된 파일시스템에 대한 debugfs작업을 마무리 하였다면 파일시스템을 닫아야 한다.  열려진 파일시스템을 닫기 위해서는 아래의 예와 같이 “close_filesys”라고 하면 된다.

 

 

 

파일시스템이 닫혀지기 전에는 debugfs 모드에서 ls라고 하면 파일리스트를 보여줍니다. 하지만 열려져 있던 파일시스템을 닫은 후에 ls라고 하면 “Filesystem not open”이라는 메시지와 함께 파일시스템이 열려져 있지않기 때문에 파일리스트를 출력할 수 없다라고 나옵니다.

 

 

debugfs모드에서 현재 작업디렉토리 출력하기

 

debugfs모드에서 파일시스템 작업을 하다보면 현재 어떤 위치에 있는가를 확인해야 할 필요성이 있다. 쉘명령어와 마찬가지로 debugfs모드에서도 pwd라고만 하면 현재 위치를 알려줍니다.  아래의 예는 파일시스템 내부에서 현재 위치를 확인하기 위하여 “pwd”라는 debugfs전용명령어를 사용한 것이다.

 

 

 

 

debugfs 모드에서 디렉토리 관련 작업하기

 

debugfs모드에서 현재위치의 디렉토리리스트를 확인하고자 한다면 “ls”라고 하면 된다. 아래의 예는 파일시스템내에서의 디렉토리리스트를 확인하기 위하여 ls라는 명령어를 이용한 것이다.

 

 

 

다음은 debugfs모드에서 파일시스템 내에서의 디렉토리를 생성할 수 있다. 아래의 예는 현재 오픈된 파일시스템에서 testdir이라는 디렉토리를 생성한 예이다.

 

 

 

위와 같이 특정 파일시스템 내부에서 디렉토리를 생성하려면 debugfs실행시에 파일시스템을 -w옵션을 이용하여 쓰기모드로 오픈해야 한다.

 

다음과 같이 debugfs모드에서 현재 작업위치를 변경할 수 있다. 특정 파일시스템내에서 현재 작업 디렉토리를 변경하고자 한다면 쉘명령어와 마찬가지로 “cd 디렉토리명”이라고 하면 된다.  아래의 예는 바로 앞에서 생성한 testdir이라는 디렉토리로 작업디렉토리를 변경한 예이다. 현재 작업디렉토리를 testdir로 변경한 후에 pwd라는 debugfs명령어로 현재 위치를 확인한 것이며 현재위치가 /testdir로 변경된 것을 확인하실 수 있다.

 

 

 

위의 cd명령어는 “change_working_directory”로 사용하셔도 동일한 결과를 얻을 수 있다.

 

debugfs모드는 파일시스템을 대상으로 행해지는 작업이므로 debugfs를 실행하기 이전의 쉘프롬프트상태의 위치를 “native filesystem위치”라고 한다.  즉, “native filesystem위치”란 흔히 일반적으로 말하는 쉘프롬프트가 존재하는 디렉토리경로를 의미한다.

 

즉, 다음과 예와 같이 debugfs명령어상태에서 쉘명령어로 빠져나가지 않고서 이 “native filesystem위치”를 변경할 수 있다. 즉, “lcd  변경할위치”라고 하면 된다.  (ftp로 원격서버로 접속한 후에 로컬서버의 위치를 변경하기 위해 lcd를 사용하는 것을 기억하신다면 이해가 빠를 것이다.)  아래의 예는 debugfs모드에서 “native filesystem위치”를 /tmp로 변경한 것이다.

 

 

 

 

debugfs모드에서 파일시스템 내부의  특정 디렉토리 삭제하기

 

debugfs로 특정 파일시스템 내의 디렉토리를 삭제할 수 있다. 쉘 명령어와 마찬가지로 “rmdir”이라는 debugfs 명령어를 이용하면 된다. 아래의 예는 현재의 파일시스템 내부에 위치하는 파일리스트를 확인한 후에 testdir이라는 디렉토리를 삭제한 것이다. 그리고 testdir의 삭제확인을 위하여 ls를 이용한 것이다.

 

 

 

위의 결과를 보면 삭제 전의 testdir이라는 디렉토리 앞의 inode가 11에서 삭제된 후에는 0로 변해있음을 알 수 있다.  이로써 debugfs모드에서 파일시스템 내부 작업으로 삭제된 파일이나 디렉토리는 inode가 0이 된다는 것을 알 수 있다.

 

debugfs모드에서 파일시스템 내부의  특정 파일 삭제하기

 

debugfs로 특정 파일시스템 내의 파일을 삭제할 수 있다. 쉘 명령어와 마찬가지로 “rm”이라는 debugfs 명령어를 이용하면 된다. 아래의 예는 현재의 파일시스템 내부에 위치하는 파일리스트를 확인한 후에 srm.conf라는 파일을 삭제한 것이다. 그리고 srm.conf 파일의 삭제를 확인하기 위하여 ls를 실행한 것이다.

 

 

위의 결과를 보면 앞의 예에서 보았던 디렉토리삭제와 마찬가지로 삭제 전의 srm.conf라는 파일 앞의 inode가 15에서 삭제된 후에는 0로 변해있음을 알 수 있다.

 

 

debugfs모드에서 쉘위치의 파일 복사하기

 

앞서 설명드렸던 “native filesystem위치”, 즉 쉘프롬프트 상태에 있던 파일을 debugfs모드에서 write라는 명령어를 이용하여 복사할 수 있다. 아래의 예는 “native filesystem위치”에 위치한 testfile을 복사하여 testfile.cp라는 파일로 가져온 것이다.

 

 

 

먼저, debugfs를 실행하기 전의 쉘상태에서 testfile을 확인 하였다. 그리고 /dev/hdb를 쓰기모드로 debugfs를 실행 하였다. 그런 다음 “write testfile testfile.cp”라는 debugfs명령어를 실행한 것이다.  여기서 testfile은 쉘상태에 있던 파일이며 testfile.cp는 쉘상태에 있던 testfile이 복사된 파일명 이다. 그 결과 testfile.cp라는 파일명으로 inode 11번에 할당되었음을 알 수가 있다.

 

 

리눅스에서 삭제된 파일들의 inode목록을 확인하기

 

debugfs모드에서 쉘에서 삭제된 파일들의 리스트를 확인할 수 있다. 쉘에서 rm명령어로 파일을 삭제하면 실제로 삭제된 파일의 block데이터를 삭제하는 것이 아니라 파일시스템에서 그 파일에 대한 inode링크를 삭제해 버린다. 따라서 삭제된 파일명은 알 수가 없지만 삭제된 파일의 inode정보만 알고 있다면 삭제된 파일을 원래 상태로 복구할 수도 있다. 하지만 오래된 파일이나 디스크에 빈번한 access(읽고 쓰기)가 일어나는 경우라면 복구될 확률이 현저하게 떨어지게 된다.

 

아래의 예는 쉘에서 삭제했던 파일들의 inode정보를 debugfs모드에서 확인한 예이다.

즉, debugfs모드에서 쉘에서 삭제하였던 파일의 inode정보등을 확인하려면 “lsdel”이라고 하면 된다.

 

 

 

위의 예에서는 현재 5개의 삭제된 파일의 inode 가 존재함을 알 수 있다. 삭제된 날짜, 파일사이즈등을 비교해 보면서 복구를 할 수도 있다. 파일 복구에 대해서는 뒤에서 자세히 다루고 있다. lsdel이라는 debugfs명령어 대신에 list_deleted_inodes라는 명령어를 이용하셔도 삭제된 파일의 inode정보리스트를 확인할 수 있다.

 

특정 파일시스템의 수퍼블럭의 정보 및 상태 확인하기

 

stats이라는 debugfs명령어를 이용하면 특정 파일시스템의 수퍼블럭의 정보 및 상태를 확인 할 수 있다. stats이라는 debugfs명령어로 확인할 수 있는 파일시스템의 정보는 다음과 같은 것들이 있다.

 

. 파일시스템(Filesystem) UUID  . 파일시스템(Filesystem) magic number  . 파일시스템(Filesystem) revision  . 파일시스템(Filesystem) features  . 파일시스템(Filesystem) state  . Errors behavior  . 파일시스템(Filesystem) OS type  . Inode 갯수(count)  . Block 갯수(count)  . 사용유보된 블럭 갯수(Reserved block count)  . 미사용 블럭수(Free blocks)  . 미사용 inodes(Free inodes)  . 블럭 크기(Block size)  . 프레그먼트 크기(Fragment size)  . 블럭그룹 당 블럭수(Blocks per group)  . 블럭그룹 당 프레그먼트수(Fragments per group)  . 블럭그룹 당 Inode수(Inodes per group)  . 블럭그룹 당 Inode블럭수(Inode blocks per group)  . 파일시스템(Filesystem) 생성날짜  . 최종 마운트시간  . 최종 저장시간  . 마운트 횟수  . 마지막 점검시간  . 각블럭의 상세정보      - Primary superblock      - Group descriptors      - Block bitmap      - Inode bitmap      - Inode table      - free blocks      - free inodes      - directories

 

다음 예는 앞의 예에서 오픈하였던 /dev/hdb파일시스템의 정보를 확인한 것이다.

 

 

 

특정 파일시스템의 수퍼블럭의 정보를 확인하는 방법은 stats대신에 show_super_ststs를 이용하셔도 동일한 결과를 얻을 수 있다. 또한 수퍼블럭정보를 확인하는 또 다른 방법으로는 “dumpe2fs”라는 리눅스 쉘명령어를 이용하실 수 있다.

 

 

특정파일시스템내에 존재하는 특정파일의 inode 상세정보 확인하기

 

특정 파일시스템에 존재하고 있는 파일의 inode의 상세정보를 확인하고자 한다면 debugfs모드에서 “show_inode_info 파일명”이라고 하면 된다.

 

확인가능한 특정파일의 inode정보로는 다음과 같은 것들이 있다.

 

        - Inode번호

        - Type

        - Mode

        - Flag

        - Generation

        - User

        - Group

        - Size

        - File ACL

        - Directory ACL

        - Links

        - Blockcount

        - Fragment정보

        - 사용된 블록번호

        - 사용된 총 사용블럭수

 

아래의 예는 debugfs모드에서 특정파일시스템내에 존재하는 httpd.conf라는 파일에 대한 inode의 상세정보를 확인한 것이다.

 

 

 

위의 정보로 알 수 있는 것은 httpd.conf라는 파일의 inode정보로서 inode 13번에 할당되어 있으며, 파일타입이 regular Type이라는 것과 0644모드, 그리고 실제 하드디스크상에서 httpd.conf파일은 517번 Block부터 525번 블록까지 모두 9개의 블록을 사용하고 있음을 알 수가 있다.

 

 

현재상태에서 사용가능한 debugfs명령어 확인

 

파일시스템 내부의 debugfs모드에서의 사용가능한 명령어를 확인할 수 있다. 간단히 lr라고만 하면 가능한 debugfs명령어를 보여줍니다. 아래의 예는 /dev/hdb파일시스템을 오픈한 상태에서 현재 사용가능한 debugfs명령어들을 확인한 것이다.

 

 

 

출력결과가 많아서 뒷부분은 생략하였다. 참고로 lr대신 list_requests를 사용하셔도 동일한 결과를 얻을 수 있다.

 

 

특정 파일시스템 내부의 현재위치에서 가장 가까운 빈 블록찾기

 

특정 파일시스템 내부에서 debugfs의 ffb라는 명령어로 현재위치에서 부터 시작하여 가장 가까운 빈 블록을 찾아서 할당할 수 있다. 아래의 예는 앞의 예에서 오픈하였던 /dev/hdb파일시스템 내부에서의 현재위치에서 가장 가까운 비어있는 블럭을 찾기위하여 ffb라는 debugfs명령어를 사용한 것이다.

 

 

그 결과 530번이라는 빈 블록을 찾은 결과를 출력한 것이다.  참고로 ffb명령어대신 find_free_block를 사용해도 빈 블록을 찾을 수 있다.

 

 

특정 파일시스템 내부의 현재위치에서  빈 inode찾기

 

특정 파일시스템 내부에서 debugfs의 ffi라는 명령어로 빈 inode를 찾을 수 있다.

아래의 예는 앞의 예에서 오픈하였던 /dev/hdb파일시스템 내부에서의 ffi라는 debugfs명령어를 이용하여 빈 inode를 찾은 예로서 결과 inode 13번이라는 빈 inode를 찾은 것이다.

 

 

참고로 ffi대신 find_free_inode를 이용해도 빈 inode를 찾을 수 있다.

 

 

파일시스템 디버거 debugfs모드에서 파일링크 삭제하기

 

특정 파일시스템 내부에서 debugfs의 unlink명령어로 링크를 삭제할 수 있다. 아래의 예는 inode번호 12번에 할당된 access.conf라는 파일의 링크를 삭제한 것이다. 삭제를 하기 전에 ls라는 debugfs 명령어로 현재 위치에서의 파일리스트를 확인하였으며 링크삭제를 위하여 “unlink access.conf”를 실행 하였다.

 

 

 

삭제한 후에 ls로 다시 확인한 결과 access.conf파일에 대한 inode가 0로 된 것을 확인할 수 있다.

 

 

파일시스템 디버거 debugfs모드에서 파일링크 생성하기

 

특정 파일시스템 내부에서 debugfs의 ln명령어로 특정 파일의 inode를 할당하여 링크를 생성할 수 있다. 아래의 예는 mime.types라는 파일을 원본으로하는 mime.types2라는 파일에 대한 링크를 생성한 것이다.  생성을 하기 전에 먼저 debugfs의 ls명령어로 현재의 파일리스트를 확인하였다. 그리고 “ln mime.types mime.types2”명령어로 mime.types2라는 이름으로 링크를 생성한 것이다.

 

 

 

그리고 생성된 mime.types에 대한 링크를 확인하기 위하여 ls를 한 결과 inode 24번에 mime.types2라는 파일이 링크된 것을 확인 할 수 있다.

 

 

debugfs로 특정 파일시스템 초기화하기

 

[주의사항] debugfs의 init_filesys명령어 실행 주의 이번에 예를드는 init_filesys를 실무에 함부로 적용하지 마십시요. 여러분들의 파일시스템이 초기화되어 데이터가 사라지게 된다.  이번 절의 설명은 학습용으로만 참고하기 바란다.

 

이번에는 debugfs의 많은 명령어들 중 가장 위험한 명령어인 init_filesys명령어를 설명하고자 한다.  init_filesys명령어는 지정된 파일시스템을 완전히 초기화 시키는 것으로 이 명령이 실행되고 나면 파일시스템의 모든 정보가 초기화된다.  사용하는 형식은 다음과 같다.

 

사용형식 : init_filesys  <장치명>  <블록크기>

 

한가지 주의하실 것은 이 명령을 수행하기 전에 초기화 대상 파일시스템은 close된 상태이어야 한다는 것이다.  즉 open된 상태에서는 이 명령어가 수행되지 않는다.

 

아래의 예는 /dev/hdb라는 파일시스템을 초기화 한 예이다.

 

먼저 “init_filesys /dev/hdb 8192”로 파일시스템을 초기화하려고 하였으나 /dev/hdb파일시스템이 open된 상태이기 때문에 실행되지 않았습니다.

 

 

 

그리고 “close_filesys”를 실행하여 /dev/hdb파일시스템을 닫은 후에 다시 “init_filesys /dev/hdb 8192”를 수행하여 완전히 초기화 하였다. 초기화 한 후에 ls라는 debugfs명령어를 사용하였으나 아무런 정보가 없으므로 정상적인 실행이 되지 않은 것을 보이고 있다. 거듭 당부드리지만 초기화는 모든 데이터를 완전히 삭제하는 것이므로 주의하기 바란다.