추상적인:E2fsck는 이 옵션을 오류 없이 찾았 -n
지만 -p
잘못되었습니다. 오류를 수정했지만 오류 메시지는 표시되지 않았습니다. 오류는 종료 코드에 의해서만 반영됩니다. 이것을 어떻게 설명할 것인가?
저는 Ext2 파일 시스템이 있는 USB 하드 드라이브를 사용하여 여러 시스템의 백업을 저장합니다. 최근에 이 드라이브에서 엄청난 데이터 처리량이 발생했기 때문에 추가 파일 시스템 검사를 수행하기로 결정했습니다. 전체적으로 저는 e2fsck
다양한 옵션을 사용하여 4번의 실행을 수행했습니다. 다음은 루트로 사용한 명령과 그 출력입니다 e2fsck
. 불행하게도 일부 문구는 독일어로 현지화되어 있지만 (아마도) 중요한 문구는 영어로 되어 있습니다.
처음 실행, 읽기 전용:
# e2fsck -nv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0
읽기 전용을 강제하려면 두 번째 실행:
# e2fsck -nfv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
709312 inodes used (1.16%)
95492 non-contiguous inodes (13.5%)
# von Inodes mit ind/dind/tind Blöcken: 109958/2429/7
96258851 blocks used (39.42%)
0 bad blocks
8 large files
564029 regular files
121351 directories
0 character device files
0 block device files
11 fifos
506224 links
23073 symbolic links (19397 fast symbolic links)
839 sockets
--------
1215527 files
0
세 번째 실행, 마무리:
# e2fsck -pv /dev/sdb1; echo $?
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0
네 번째 실행, 강제 정렬:
# e2fsck -pfv /dev/sdb1; echo $?
709312 inodes used (1.16%)
95492 non-contiguous inodes (13.5%)
# von Inodes mit ind/dind/tind Blöcken: 109958/2429/7
96258853 blocks used (39.42%)
0 bad blocks
8 large files
564029 regular files
121351 directories
0 character device files
0 block device files
11 fifos
506224 links
23073 symbolic links (19397 fast symbolic links)
839 sockets
--------
1215527 files
1
이러한 명령은 사이에 다른 것을 건드리지 않고 하나씩 직접 실행됩니다.
차이점을 참고하세요:
처음 두 실행에서는 파일 시스템이 읽기 전용으로 열렸으며(
-n
옵션), 마지막 두 실행에서는 정리 실행이었습니다(-p
옵션).1차와 3차는 필수가 아니며, 2차와 최종차는 (
-f
)입니다.한 가지 예외를 제외하면 모든 실행에서 일관된 파일 시스템 데이터가 보고되었습니다. 마지막 실행(
-pfv
)에서는 "사용된 블록" 수가 다르게 보고되었습니다.마지막 실행을 제외한 모든 실행은 상태 0으로 종료되며,
-pfv
이는 상태 1( )로 종료됩니다.
분명히 마지막 강제 조각 모음 실행( -pfv
)에서는 다른 실행에서 찾을 수 없는 파일 시스템 오류를 발견하고 수정했습니다. 불행하게도 출력 오류에 대한 어떠한 힌트도 제공하지 않습니다.
이제 내 질문에 답해 보겠습니다.
그곳에서 어떤 오류가 발견되어 수정되었나요? 사용된 블록을 잘못 계산하는 것만큼 간단합니까?
이 오류의 원인은 무엇입니까? 파일 시스템은 항상 깔끔하게 마운트 해제됩니다.
파일 시스템 오류는 결국 수정되었습니다
e2fsck
. 하지만 그 안에 저장된 데이터를 믿을 수 있을까요? 처음에 파일 시스템 오류를 일으킨 원인이 디스크의 데이터도 손상시켰습니까? 이렇게 하면 디스크의 모든 데이터가 쓸모 없게 됩니다. 아니면 편집증인가요? 왜?
마지막 질문은 파일 시스템과 데이터를 구별합니다. 이와 관련하여,미켈의 답변도착하다"정전 후에도 로그 파일 시스템이 손상되지 않는다고 보장할 수 있습니까?”는 관련성이 매우 높지만 저널링 파일 시스템에 중점을 두기 때문에 Ext2에서는 작동하지 않습니다.
반품자일스의 대답도착하다"fsck로 완료된 파일 시스템 수정을 테스트하는 방법” 잘 읽어보세요. 이에 따르면 fsck
파일 시스템은 반드시 최신 상태가 아닌 일관된 상태만 보장됩니다.
업데이트 1
그의논평Luciano Andress Martini는 관찰된 명백히 당황스러운 동작이 e2fsck
실행기의 RAM 오류로 인해 발생할 수 있다고 제안했습니다. 이것은 유사한 상황에서 매우 관련성이 높은 측면이지만 여기에는 적용되지 않는 것 같습니다. 밤새 "memtest86+"로 RAM을 확인했고 오류 없이 16번의 패스를 완료했습니다. 또한 다른 컴퓨터(다른 하드웨어, 커널 및 버전)를 사용하여 테스트 드라이브에서 e2fsck -nfv
, , 을 실행했습니다 e2fsck -pfv
. 이는 파일 시스템 오류를 나타내지 않았으며 위에 표시된 마지막 명령에서 보고된 파일 시스템 데이터, 특히 사용된 블록 수를 확인했습니다. 추가적으로, 비필수 점검에서 보고된 총 블록 수(244182016)도 확인되었습니다.e2fsck -fv
e2fsck
e2fsck
업데이트 2
텔레콤의 답변e2fsck
관찰된 동작은 매우 오래된 파일 시스템을 처리할 때 파일 시스템 기능 설정의 변경으로 설명 될 수 있다고 제안됩니다 . e2fsck
불행하게도 이 매우 일관된 설명은 여기에 적용되지 않습니다. 파일 시스템은 실제로 , , , , mke2fs
기능이 활성화된 최신 버전(1.42.8)을 사용하여 생성되었습니다. 위의 실행은 이를 변경하지 않았습니다.ext_attr
resize_inode
dir_index
filetype
sparse_super
large_file
e2fsck
업데이트 3
한편, USB 드라이브는 비파괴 읽기 및 쓰기 불량 블록 테스트(3일이 걸렸습니다. 예: 지정된 블록 크기( -b
) 및 블록 수( -c
)가 중요함)와 여러 오프라인 SMART 테스트를 성공적으로 통과했습니다.
답변1
내 질문에 유용한 기여를 추가하기 위해 나는 스스로 몇 가지 조사를 했습니다. 일부 결과는 일반적인 의미를 가질 수도 있으므로 이 자가 답변에 요약합니다.
참고: 문제 정의에 따르면 아래의 모든 내용은 e2fsck
버전 1.41.1을 참조하며 저널이 없는 Ext2 파일 시스템에 중점을 둡니다. 그러나 이러한 일반 용어는 최신 버전의 프로그램 및 파일 시스템에도 어느 정도 적용됩니다.
교훈을 얻으세요
헤드라인부터 시작해 보겠습니다. 그 이유는 다음과 같습니다.
예를 들어 다음과 같이 C 언어 환경에서 실행합니다
e2fsck
.LC_ALL=C e2fsck ...
이렇게 하면 영어로 메시지를 받을 수 있어 온라인에서 특정 도움말을 더 쉽게 찾을 수 있습니다.
이
-y
옵션은 주의해서 사용하십시오.e2fsck
나타나는 모든 프롬프트에 자동으로 "예"라고 대답합니다. 이러한 질문에는 항상 "이 오류를 수정하시겠습니까?"와 같은 질문이 포함되는 것은 아니며, "영향을 받는 파일을 삭제하시겠습니까?"라는 질문도 있습니다.파일 시스템을 일부 변경
e2fsck
하고 상태 1(또는 3)로 종료한다고 해서 파일 시스템 오류(손상)가 있음을 의미하는 것은 아닙니다.e2fsck
핸들SIGINT
(Ctrl-C) 그러나 나는 그것에 의지하지 않을 것입니다. (개인적인 생각입니다.)
다음 사항에 중점을 둡니다.정보당신은 e2fsck
:
e2fsck
파일 시스템에 포함될 수 있는 오류와 이를 처리하는 방법을 알고 싶다면-p
(손질) 옵션을 사용하지 마세요.대화형으로(즉, , , ,
e2fsck
옵션 없이 ) 실행하면 읽기 전용( ) 또는 대조( ) 실행보다 찾은 오류에 대한 더 많은 메시지가 출력 됩니다. 의 별칭입니다 . "예" 실행( )을 통해 기본적으로 대화형으로 실행하는 것과 동일한 정보를 얻을 수 있습니다.-n
-p
-a
-y
-n
-p
-a
-p
-y
매우 유사하지만 이 옵션은
-n
대화형의 정확한 테스트 실행을 생성하지 않습니다.이 옵션을 사용하지 않으면 직접 확인해야
-f
할 가능성이 높습니다 .e2fsck
그렇게 하면 결정을 추론할 수 있는 추가 정보가 제공됩니다. 예:... primary superblock features different from backup, check forced.
이것을 놓치고 싶지 않다면 해당 옵션을 사용하지 않고 시작 하고 파일 시스템이 깨끗해 보여 검사가 거부된
-f
경우 두 번째 시도에서만 사용하십시오 .e2fsck
e2fsck
전체 그림을 보려면 종료 코드를 확인하는 것을 잊지 마세요echo $?
.
수표 종류
인터렉티브:-n
옵션 및 -p
를 사용하지 않으면 -a
대화형 파일 시스템 검사가 수행됩니다. 즉, 모든 단계에서 무엇을 하고 싶은지 물어볼 것입니다. 이를 통해 프로세스를 최대한 제어할 수 있습니다.-y
e2fsck
경고: 파일 시스템의 크기와 상태에 따라 이는 금방 지루해질 수 있습니다. inode 다음에 inode를 수정해야 한다고 상상해 보십시오. 그러한 회의는 몇 시간 동안 지속될 수도 있고 그보다 더 악화될 수도 있습니다.
게다가 문제가 자신이 익숙하지 않은 방향으로 흘러가면 상황이 정말 무서울 수 있습니다.
방해하다:이런 식으로 대화형 검사가 불가능해지면 e2fsck
핸들 (Ctrl-C)을 아는 것이 SIGINT
더 나을 수 있습니다 .
실제로 몇 가지 고무적인 보고서가 있습니다.매드 해터로그리고크리스. 하지만 이미 언급했듯이 저는 그러한 방해를 피하려고 노력합니다.
이유는 간단합니다. 파일 시스템을 검사하는 것은 복잡한 프로세스이고, 손상 복구는 일관된 방식으로 수행되어야 하며, 중단 처리는 훨씬 더 복잡합니다. 복잡한 소프트웨어와 마찬가지로 신호 처리기에도 버그가 있을 수 있습니다. 예시 보기이 게시물안드레아스 딜거 지음. 그렇다면 왜 위험을 감수합니까? 물론 타당한 이유가 있을 수 있지만 스스로 판단해 보세요.
읽기 전용:확인하려는 파일 시스템의 상태에 대해 거의 알지 못하는 경우 e2fsck
이 -n
옵션을 먼저 사용하는 것이 가장 좋습니다. 아래에서 볼 수 있듯이 이는 정확한 테스트 실행을 생성하지는 않지만 대화형 실행에서 무엇을 기대할 수 있는지에 대한 좋은 인상을 줍니다.
정돈하다: e2fsck
-p
이 옵션을 사용하면 파일 시스템의 조각 모음이 수행됩니다. 이것맨페이지 e2fsck(8)유망한 것 같습니다.
이 옵션을 사용하면 e2fsck가 수동 개입 없이 안전하게 복구할 수 있는 모든 파일 시스템 문제를 자동으로 복구하게 됩니다.
그러나 이는 일부 파일 시스템 오류만 수정한다는 의미이기도 합니다. 소스에서 볼 수 있듯이 안전하게 처리할 수 없는 오류가 감지 e2fsck
되면 -p
실행이 중지되고 나머지 작업은 단순히 정리하는 것이 아니라 후속 실행을 위해 남겨집니다.
또한 위에서 언급한 바와 같이 -p
오류 및 수정에 대한 정보는 더 적게 제공됩니다.
예:e2fsck
옵션으로 시작하면 -y
대화형 실행과 동일한 결과가 생성되며 대화형 실행에 대한 모든 질문에 "예"라고 대답됩니다. 이 접근 방식의 단점은 이미 위에서 언급했습니다.
예상되는:내가 아는 한이 섹션의의"Ext2fs 디렉토리 구조 삭제 취소 미니 HOWTO”, 이 프로그램을 사용하면 e2fsck의 질문에 보다 세부적인 수준으로 자동으로 답변할 수 있습니다.예상되는. 거기에서 e2fsck
다음 래퍼 스크립트를 사용합니다.
#!/usr/bin/expect -f
set timeout -1
spawn /sbin/e2fsck -f $argv
expect {
"Clear<y>? " { send "n" ; exp_continue }
"<y>? " { send "y" ; exp_continue }
}
그러면 "Clear?" 프롬프트("n" 사용)를 사용하는 모든 질문과 "y"를 사용하는 다른 모든 질문에 자동으로 대답합니다. 자세한 내용은 Expect 문서를 참조하세요. 바라보다이 문제By Wrothgarr 이것은 Expect for 를 사용하는 또 다른 예입니다 e2fsck
.
명확히 하자면, 저는 이 스크립트를 맹목적으로 사용하는 것을 권장하지 않습니다. 여기에는 "교육 목적"으로만 인용되었습니다.
이 아이디어를 취하고 자신의 필요에 맞게 사용자 정의하려는 사람들을 위해 e2fsck
소스 파일 e2fsck/problem.c의 시작 부분 근처에 prompt
이 배열은 총 20개의 e2fsck
사용된 힌트를 보유하도록 정의되어 있습니다. 그 중 일부는 내부적으로만 사용됩니다. 프롬프트와 파일 시스템 오류 간의 상호 관계는 아래에 자세히 설명되어 있습니다.
소스에서 배웠습니다.
대화:파일 시스템에서 발견된 대부분의 오류는 e2fsck
e2fsck/problem.c 파일에 정의된 함수를 참조하세요. fix_problem
이 기능은 주어진 옵션에 따라 각 오류에 대해 사용자와 적절한 대화를 수행합니다 e2fsck
.
이를 수행하려면 동일한 파일 e2fsck/problem.c에 이전에 정의된 fix_problem
배열에서 현재 오류 코드를 찾으십시오 . problem_table
이 배열은 각 오류 코드에 오류 메시지 템플릿, 사용자에게 질문하는 프롬프트, 오류 처리 세부 정보를 제어하는 비트마스크를 제공합니다. (일부 오류의 경우 "코드 숨김"이라는 추가 오류 코드도 참조되며, 이 코드의 대화 상자가 이후에 실행됩니다. 그러나 이는 우리에게 중요하지 않습니다.)
우리 문제에 중요한 두 가지 플래그가 이 비트마스크에 가끔 사용됩니다: PR_PREEN_NOMSG
및 PR_NO_NOMSG
. 설정되면 각각 -p
실행 및 실행 오류 메시지가 표시되지 않습니다 -n
. 따라서 이는 오류를 정의하고 -y
대화형 실행 또는 실행에 대한 자세한 정보를 얻을 수 있습니다.
의 정의는 problem_table
292개의 오류 코드를 지정하며 그 중 23개는 플래그가 지정 PR_PREEN_NOMSG
되고 1개만 플래그가 지정됩니다 PR_NO_NOMSG
. 그들 중 누구도 PR_PREEN_NOMSG
및 기호를 모두 가지고 있지 않습니다 PR_NO_NOMSG
.
또 다른 흥미로운 플래그 PR_PREEN_OK
: 이 플래그에 대한 오류는 preen(runs)에 의해 안전하게 처리될 수 있습니다 -p
. preen은 다른 오류도 처리할 수 있습니다. 아래의 "특수 사례"를 참조하세요. 그러나 이러한 오류가 대부분입니다. 배열의 82개 오류가 problem_table
표시되었습니다 PR_PREEN_OK
.
시작:Linux 버전 1.41.1의 경우 e2fsck/unix.c 파일의 함수로 e2fsck
실행이 시작됩니다 .main
패스 0:로그를 초기화하고 확인한 후(이 질문과 관련 없음) 파일 시스템에 대한 몇 가지 기본 확인 및 정리가 수행됩니다. 이를 패스 0이라고도 합니다. 주요 부분은 check_super_block
소스 파일 e2fsck/super.c의 함수로 완성됩니다.
이름에도 불구하고 이 함수는 슈퍼블록을 담당할 뿐만 아니라 블록 그룹 설명자를 확인합니다. 이를 통해 각 블록 그룹의 여유 블록 및 여유 inode 수를 합산하고 그 결과를 슈퍼블록의 전역 값과 비교합니다.
e2fsck
이러한 값이 일관되지 않으면 어떻게 됩니까 ? 명령줄 옵션 에 따라 다릅니다 . -n
파일 시스템은 실행에 유효하지 않은 것으로 간주되며 나중에 전체 검사가 강제로 수행됩니다. 다른 모든 경우( , 대화형 실행)에서는 -p
전체 -y
확인을 강제하지 않고 슈퍼블록의 총 개수가 자동으로 업데이트됩니다. 실제로 후자가 실행되어 다른 오류를 발견하지 못하면 이러한 자동 수정에도 불구하고 파일 시스템이 깨끗한 것으로 보고됩니다.
이 함수는 check_super_block
또한 inode 크기 조정 확인, 분리된 inode 정리, 로그 관리 등의 작업도 수행하지만 이는 우리 문제에서는 중요하지 않은 것 같습니다.
뛰어 넘다:옵션이 아직 전체 파일 시스템 검사를 강제하지 않은 -f
경우 전체 파일 시스템 검사 e2fsck
를 직접 수행하기로 결정했습니다 . 잘 알려진 기준은 마지막 확인 이후 설치 수, 완전히 제거되지 않음, 알려진 파일 오류 등입니다.
그러나 이 옵션이 사용되지 않는 경우에만 다른 기준도 적용됩니다 -n
. 즉, 다음 수량의 슈퍼 블록과 백업 간의 차이입니다.
large_file
,dir_nlink
, 를extent
제외한 파일 시스템 기능 활성화총 블록 수,
총 인덱스 노드 수,
파일 시스템 UUID.
표준에서 특정 파일 시스템 기능을 제외하는 이유는 커널이 필요에 따라 이러한 기능을 동적으로 설정할 수 있고 백업이 아닌 슈퍼블록에서만 이 작업을 수행할 수 있기 때문입니다. 예외적인 기능의 경우 이러한 차이점은 전체 검사를 보장할 만큼 중요한 것으로 간주되지 않습니다. 반대로 이 ext_attr
기능은 커널에 의해 동적으로 설정될 수도 있지만 이 경우 백업 업데이트가 중요하므로 이 기능도 예외는 아닙니다.
자체적으로 전체 검사를 강제하기로 결정 하면 e2fsck
불편함을 설명하는 메시지가 인쇄됩니다. 이것이 슈퍼블록과 해당 백업 간의 지정된 차이점 중 하나로 인해 발생하는 경우 다음 메시지가 표시됩니다.
... primary superblock features different from backup, check forced.
메시지에서 "기능"이라는 용어는 순전히 "파일 시스템 기능"보다 더 넓은 의미를 갖습니다. 예를 들어 총 블록 수도 포함합니다. 당신은 또한 볼 수 있습니다이 게시물저자: 에릭 산딘(Eric Sandin)이것이와 관련하여 Theodore Tso.
-n
그럼에도 불구하고 위에서 언급한 것처럼 이 경우 슈퍼블록 백업이 고려되지 않기 때문에 이 메시지는 즉시 표시되지 않습니다 .
전체 검사가 시행되지 않으면 by -f
또는 by에 관계없이 e2fsck
검사( e2fsck
사전)가 건너뜁니다. 이 경우 e2fsck
파일 시스템은 상태 0의 완전한 종료로 보고됩니다. 패스 0에서 일부 수정이 이루어진 경우에도 마찬가지입니다(예: 슈퍼블록의 총 여유 블록 수 수정).
패스 1~6:전체 검사에서는 e2fsck
각각 서로 다른 초점을 두고 파일 시스템에 대해 최소 5번의 전체 검사가 수행됩니다. 이는 소스 파일 e2fsck/pass1.c ~ e2fsck/pass5.c에 각각 정의된 함수에 의해 실행됩니다 e2fsck_pass1
.e2fsck_pass5
특별한 파일 시스템 손상을 처리해야 하는 경우 채널 1을 보완하는 추가 채널이 있을 수 있습니다. 이는 pass 1B에서 pass 1D로 라벨이 지정되어 있으며 해당 기능은 e2fsck/pass1b.c에 정의되어 pass1b
있습니다 .pass1d
디렉토리 재해시는 패스 3의 일부이며 e2fsck/rehash.c 파일의 함수에 의해 수행되며 e2fsck_rehash_directories
패스 3A로 간주됩니다.
또한 PR_6_RECREATE_JOURNAL
로그를 다시 생성해야 할 경우 오류 코드가 사용됩니다. 분명히 이는 별도의 패스(패스 6)를 구성하는 것으로 간주됩니다. 함수에서 실행됩니다 main
.
problem_table
배열에 정의된 대부분의 오류는 이러한 단계에서 확인됩니다. 각 오류에 대해 발생한 통과 횟수는 오류 코드 이름에서 확인할 수 있습니다. 숫자는 코드 이름의 첫 번째 밑줄 뒤에 있습니다. 예를 들어 오류는 PR_1_TOO_MANY_BAD_BLOCKS
패스 1에서 처리되고 PR_3A_OPTIMIZE_DIR_ERR
패스 3A에서 처리됩니다.
이 질문에서 특히 흥미로운 점은 패스 5가 시작될 때 사용 가능한 블록과 사용 가능한 inode의 총 개수가 다시 확인된다는 것입니다. 패스 0의 빠른 확인과 달리 블록 그룹 설명자에서 해당 값만 확인됩니다. 정리하면 이번에는 e2fsck
파일 시스템 프로세스 전반에 걸쳐 철저하게 수집된 데이터를 기반으로 개수를 계산하는데, 이때 각 블록과 각 아이노드의 역할을 개별적으로 분석한다. 이는 e2fsck/pass5.c 파일에 정의된 함수에 의해 check_block_bitmaps
수행 됩니다.check_inode_bitmaps
슈퍼블록의 값과 비교한 결과 값의 차이는 오류 PR_5_FREE_BLOCK_COUNT
합계 로 간주됩니다 PR_5_FREE_INODE_COUNT
. 그런데 이러한 오류는 플래그가 지정되어 PR_PREEN_NOMSG
collate() 중에 명시적으로 보고되지 않습니다 -p
.
특별한 경우:오류 디렉토리를 e2fsck
호출하거나 참조하지 않고도 파일 시스템에서 수행할 수 있는 몇 가지 수정 사항이 있습니다 . 이러한 수정은 옵션 없이만 수행되며 출력에는 알리지 않지만 종료 상태에서 수행될 수 있습니다. 소스에서 그 중 세 가지를 찾았습니다.fix_problem
problem_table
-n
-n
0(없음)이 전달되는 동안 수퍼블록의 총 사용 가능한 블록 및 사용 가능한 inode 수가 수정됩니다. 이것은 위에서 논의되었습니다.패스 1 동안 수퍼블록(없음
-n
)의 마지막 고아 필드가 설정되면 자동으로 지워집니다.인덱스 디렉터리의 inode에 저장된 링크 개수 값이 이전에 상한을 초과했음을 나타내고 현재 실제 개수가 이 한도 미만인 경우 inode의 값은 4단계에서 자동으로 수정됩니다(별도의 작업을 수행할 필요 없음). 그래서
-n
).
종료 상태:전체(강제) 검사의 경우 종료 코드는 main
검사가 완료된 후 후자의 결과를 분석하는 동안 함수에 의해 결정됩니다. 검사가 중간에 취소되지 않은 경우 지금까지 종료 상태는 0이 됩니다. , 파일 시스템에는 변경 사항이 발생하지 않습니다.
마지막 연락:검사가 중간에 취소되지 않으면 이 함수는 main
슈퍼블록의 마운트 수를 재설정하고 타임스탬프를 업데이트하여 e2fsck
향후 실행에서 다음 전체 검사를 강제로 수행해야 하는 시기를 알 수 있도록 합니다. 이는 종료 상태가 결정된 후 정리 프로세스 중에 수행되므로 이 변경 사항은 상태에 영향을 미치지 않습니다.
신호 처리기:PRS
main
e2fsck/unix.c에 정의된 호출 된 함수에서 e2fsck
, 및 에 대한 신호 처리기가 생성됩니다. 후자의 두 개는 다음에 설명된 대로 진행 정보를 전환하는 데 사용될 수 있습니다.SIGINT
SIGTERM
SIGUSR1
SIGUSR2
맨페이지 e2fsck(8).
분명히 전자는 안전한 중단 및 종료를 허용하도록 처리됩니다 e2fsck
.
테스트를 통해 알아보세요
질문에 표시된 동작을 재현하기 위해 e2fsck
테스트 Ext2 파일 시스템을 설정하고 용량의 최대 10%까지 더미 파일로 채운 다음 16진수 편집기를 사용하여 일부 인적 오류를 도입했습니다. 그런 다음 질문과 동일한 명령을 사용하여 해당 파일 시스템을 확인하여 출력 및 종료 상태를 비교하십시오 e2fsck
.
문제를 마지막으로 실행할 때 사용된 블록 수가 변경되었습니다. e2fsck
이 값은 사용 가능한 블록 수와 총 블록 수를 기준으로 명확하게 계산됩니다. 그래서 이 수량을 휴먼 에러의 대상으로 선택했습니다.
슈퍼블록의 여유 블록 수:슈퍼 블록의 데이터 구조는 다음과 같습니다.이 파일. (Ext4 파일 시스템을 설명하는 이 문서의 최신 버전은 다음에서 찾을 수 있습니다.여기.) 이를 바탕으로 Hex Editor를 사용하여 슈퍼블록의 여유 블록 수를 2개 줄였습니다.
이 인적 오류는 e2fsck -nv
( 없이 -f
) 감지되고 큰 소리로 불평하여 전체 확인을 강제하고 종료 상태 4로 종료됩니다.
또한 읽기 전용 실행( -nfv
)을 강제 실행하면 오류가 보고되고 상태 4로 종료됩니다.
후속 -pv
실행(하지 않음 -f
)에서는 파일 시스템이 깨끗한 것으로 확인되었으며 오류에 대한 알림을 제공하지 않았습니다. 그러나 에러를 수정하고 수정된 값을 기준으로 사용된 블록 개수를 출력하지만 상태 0으로 종료된다.
동일한 오류가 다시 발생한 후 강제 정리 실행( -pfv
)도 오류를 보고하지 않고 대신 오류를 수정하고 상태 1로 종료되었습니다.
e2fsck
이 동작은 위 소스에서 알려진 내용을 통해 잘 이해할 수 있습니다.
이는 질문에 설명된 검사 결과를 유발하는 다른 오류여야 함을 의미합니다. 그렇지 않으면 읽기 전용 실행에 의해 보고되고 첫 번째(비강제) 조각 모음에 의해 수정되어 마지막 실행에서 깨끗한 파일을 찾을 수 있습니다. 파일 시스템.
슈퍼 블록의 총 블록 수:Hex Editor를 사용하여 슈퍼블록의 총 블록 수를 2개 줄였습니다.
-nv
-f
이는 파일 시스템을 깨끗한 것으로 보고하고 상태 0으로 종료되는 (without) 을 실행하여 감지되지 않습니다 .
이 검사( -nfv
)를 강제로 수행하면 몇 가지 오류가 발견되었습니다. 즉, e2fsck
조작된 총 블록 수를 심각하게 고려했지만 마지막 블록 그룹과 슈퍼 블록의 사용 가능한 블록 수가 잘못되었음을 발견했습니다. 또한, 블록 비트맵 끝 부분의 패딩이 설정되지 않은 것으로 확인되었습니다. 종료 상태는 4입니다.
슈퍼블록과 해당 백업 간의 차이로 인해 후속 디플레이션( -pv
, 없음)은 전체 검사를 강제합니다. -f
이 과정에서 읽기 전용 실행을 강제하여 이전에 발견된 모든 "잘못된" 오류를 수정했습니다. 그러나 사용 가능한 블록 수에 대한 알림은 제공하지 않고 비트맵 채우기의 ("불량") 오류만 보고합니다. 마지막으로 상태 1로 종료됩니다.
동일한 버그를 다시 도입하는 force-collation( -pfv
)은 기본적으로 동일한 작업을 수행하지만, 슈퍼블록과 해당 백업(이전에 강제 검사의 이유로 제공됨) 간의 차이를 알리지 않는다는 점만 다릅니다.
이 동작은 e2fsck
위 소스의 논의에서도 이해할 수 있습니다. 그러나 이는 질문에 설명된 내용과 다릅니다. 그럼 또 다른 버그가 있는 게 틀림없어요.
백업의 여유 블록 수:슈퍼블록 백업의 블록 번호는 다음에서 확인할 수 있습니다.
LC_ALL=C dumpe2fs <device> | grep -i superblock
그러나 첫 번째 슈퍼블록 백업의 여유 블록 수는 완전히 무시됩니다 e2fsck
. 실제로 정말 깨끗한 파일 시스템에서도 메인 슈퍼블록에 있는 값과 값이 다른 것 같습니다. 실제로 생각해 보면 모든 백업에서 이 값을 지속적으로 동기화하는 것은 엄청난 오버헤드가 될 것입니다. 그래서 전혀 의미가 없다고 생각합니다.
백업의 총 블록 수:다시 Hex Editor를 사용하여 첫 번째 슈퍼블록 백업의 총 블록 수를 2개 줄였습니다.
e2fsck
읽기 전용 모드에서는 이 사람의 실수가 완전히 무시됩니다: -nv
및 -nfv
.
클린 실행( -pv
, 없이 -f
)은 전체 검사를 강제 실행하여 다음 메시지를 표시합니다.
... primary superblock features different from backup, check forced.
이 과정에서 오류를 수정하고 더 이상 관련된 메시지가 없으며 상태 1로 종료됩니다.
동일한 오류가 다시 발생한 후 forcecollation( -pfv
)은 동일한 작업을 수행했지만 오류 메시지는 표시되지 않았습니다.
다시 말하지만, 이 동작은 위 소스의 논의에서 잘 이해됩니다. 이는 질문에서 관찰되는 것과 다릅니다.
또한 e2fsck
질문에 설명된 강제 실행되지 않은 실행과 업데이트 1에 설명된 이후에 수행된 검사는 동일한 총 블록 수를 보고합니다. 따라서 값은 한 번의 실행에서 변경되지 않으므로 원하는 오류의 대상이 될 가능성이 없습니다.
이것이 질문에 대한 답으로 이어지는가?
간단히 말해서 : 아니요.
질문에 설명된 각 개별 실행에 대해 관찰된 동작을 유발할 수 있는 버그를 발견했습니다 e2fsck
. 그러나 시퀀스의 모든 실행에 대한 동작을 유발하는 버그를 찾지 못했습니다.
의 모든 오류는 실행 이나 실행 또는 둘 다에 의해 보고 problem_table
될 수 있으므로 제외됩니다 .-nfv
-pfv
위의 "특수 사례"를 고려하여 읽기 전용 실행에서는 사용 가능한 블록 또는 사용 가능한 inode 수가 잘못 보고됩니다. 그렇지 않다.
다른 "특별한 경우"로 인해 사용된 블록 수가 마지막 실행에서 관찰된 것과 변경되지 않습니다.
하지만 e2fsck
결국은 복잡한 소프트웨어이기 때문에 뭔가 간과했을 가능성이 있습니다.
결과
이러한 결과에 직면하여 다음 작업 흐름을 사용하면 대화형 부분에서 불쾌한 놀라움을 피하고 e2fsck
.
이는 하드웨어가 정상이라고 가정합니다! 특히 이와 관련하여 드라이브를 신뢰할 수 없는 경우 무조건 3단계(파일 시스템 백업)부터 시작하고 설명된 순서대로 나머지 단계를 계속 진행하세요.
달려보세요
-nv
:LC_ALL=C e2fsck -nv <device>; echo $?
파일 시스템이 깨끗한 것으로 보고된 전체 검사를 건너뛴 경우
e2fsck
강제로 1단계를 반복하도록 하는 검사를 사용하십시오-f
.발견된 손상에 따라 백업 파일 시스템을 사용하십시오
dd
. 이를 통해 다음 단계에서 문제가 발생하는 경우 현재 상태를 복원할 수 있습니다.읽기 전용 실행 결과를 바탕으로 가능해 보이는 경우 다음 명령을 사용하여 대화식으로 확인하십시오.
LC_ALL=C e2fsck -v <device>; echo $?
-f
완전한 검사를 받으려면 필요한 경우 강제로 수행하십시오 .대화형 달리기가 불가능할 경우 어떻게 해야 하는지는 지금까지 발견된 내용에 따라 다릅니다.
부록: 파일 시스템 기능 확인
2fs 덤프:이 프로그램을 dumpe2fs
사용하면 파일 시스템에서 어떤 기능이 활성화되어 있는지 확인할 수 있습니다.
이는 알려지지 않은 기능에도 적용됩니다. 이 경우 dumpe2fs
슈퍼블록의 기능 필드에서 해당 비트를 고유하게 식별하는 공통 기능 이름이 사용됩니다. 예를 들어, 이는 FEATURE_R16
슈퍼블록의 읽기 전용 호환성 기능 필드에 있는 비트 16(0부터 계산)에 해당합니다. 마찬가지로, FEATURE_I31
호환되지 않는 기능 필드의 최상위 비트에 해당합니다.
compression
이 기능이 설정된 경우 dumpe2fs
이 -f
옵션으로 시작해야 합니다.
그러나 프로그램 버전 1.41.1은 64bit
활성화 및 비활성화된 기능(예: 활성화 및 비활성화)의 특정 조합에서 부동 소수점 예외로 인해 충돌이 발생하므로 약간 버그가 있는 것 같습니다 journal_dev
.
디버그:활성화된 파일 시스템 기능의 경우 명령은 와 유사한 출력을 show_super_stats
생성합니다 . 이 프로그램은 알려지지 않은 기능에 대해서도 알려줍니다.debugfs
dumpe2fs
또한 프로그램 버전 1.41.1에는 일종의 버그가 있는 것 같습니다. show_super_stats
또는 활성화된 경우 명령이 분할 오류로 인해 충돌합니다. 마찬가지로 기능이 비활성화된 상태에서 활성화되면 전체 프로그램이 부동 소수점 예외로 인해 충돌합니다.compression
journal_dev
dumpe2fs
debugfs
64bit
journal_dev
2fs 조정:알려진 파일 시스템 기능만 활성화된 경우에는 나열될 수 있습니다 tune2fs -l
. 그러나 알 수 없는 파일 시스템 기능이 활성화된 경우에는 -f
이 옵션을 사용해도 프로그램 시작이 거부됩니다.
답변2
파일 시스템이 아주 오래된 시스템용이라고 말씀하셨는데요. 파일 시스템의 온라인 확장을 위해 일부 메타데이터 공간을 예약하기 위해 파일 시스템 기능을 지원하지 않는 매우 오래된 도구를 사용하여 파일 시스템이 원래 mke2fs
생성된 경우 버전 1.14.1을 두 번째 실행할 때 자동으로 추가될 수 있습니다.resize_inode
e2fsck
내가 올바르게 기억한다면 할당은 이를 이해하지 못하는 이전 시스템에 완전히 무해하지만 파일 시스템이 확장되면 주요 재구성 없이 일부 주요 메타데이터 구조를 확장할 수 있습니다.
tune2fs -l
USB 드라이브의 파일 시스템과 이전 시스템의 ext2 파일 시스템 중 하나에서 실행하고 결과를 비교하여 이를 확인할 수 있습니다 . 파일 시스템이 마운트된 경우에도 이 작업을 수행할 수 있습니다. USB 드라이브의 출력에 resize_inode
해당 행에 대한 키워드가 포함되어 있고 Filesystem features:
이전 컴퓨터의 로컬 ext2 파일 시스템에 해당 키워드가 없는 경우 가장 가능성 있는 설명 e2fsck -pfv
은 향후 가동 중지 시간을 방지하는 데 도움이 될 수 있습니다.