e2fsck로 복구된 파일 시스템의 파일을 신뢰할 수 있습니까?

주제

파일 시스템이 e2fsck에 의해 성공적으로 복구되면 일관된(깨끗한) 상태가 보장됩니다. 그러나 복구 후 파일 자체의 신뢰성을 평가하는 것은 쉽지 않습니다.

이 질문은 특정 오류 조건에서 손상 후 복구된 ext2 및 ext4 파일 시스템에 저장된 데이터의 무결성을 판단하는 기준을 다룹니다.

배경

여러 Linux 시스템을 백업하기 위해 외부 USB 하드 드라이브(예: 플래터 기반, 플래시 없음)의 ext2 파일 시스템을 사용합니다. 이를 위해 rw, relatime옵션(전체)을 사용하여 드라이브를 수동으로 마운트했기 때문에 sync옵션은 사용하지 않았습니다.

최근에 openSUSE 13.1 시스템(Linux 커널 3.11.6-4)에서 대규모 백업(수 100GB)을 수행하고 USB HDD에 대한 모든 쓰기 활동을 완료한 후 드라이브를 마운트 해제할 수 없었습니다. umount명령이 차단되었습니다 . 돌아오지 마. 중단 없는 절전 모드( 상태 D) sync로 들어가는 후속 명령에도 동일하게 적용됩니다 .ps

USB HDD를 뽑았을 때 블록이 해제되지 않습니다.

이 후에도 표준 수단(pm-utils)을 통해 시스템의 전원을 끄려고 하면 멈췄습니다. 머신을 종료하기 위해 SysRq salute r, e, i, s, u를 사용했습니다 b. 그러나 거기에서도 요청 s(동기화) 및 u(읽기 전용 다시 마운트)이 성공하지 못했습니다.sysrq.c에 대한 커널 문서(sysrq.txt) 이러한 요청은 명시적으로 발표될 때까지 완료되지 않지만 이 경우에는 완료되지 않습니다. 따라서 SysRq b(다시 시작)이 발생하면 마운트된 파일 시스템이 완전히 마운트 해제되었다는 확인이 없으며 전체 재부팅이 시작됩니다.

관련된 모든 파일 시스템 확인(루트 파티션의 ext4 및 USB HDD의 ext2)을 사용하여 e2fsck운 좋게도 루트 파일 시스템이 깨끗하고 USB HDD의 파일 시스템에 잘못된 사용 가능한 블록과 사용 가능한 inode 개수만 표시되는 것을 발견했습니다. e2fsck를 통해 수정할 수 있습니다.

여기에 사용된 시스템의 Systemd 로그에는 마운트 해제 및 동기화 차단과 관련된 항목이 표시되지 않습니다. 특히 IO 문제와 관련된 항목이 없습니다. USB 분리 이벤트와 SysRqs를 제외한 나머지 측정은 올바르게 기록됩니다.

사건 이후 SMART와 USB HDD 테스트 결과 badblocks특이한 점은 발견되지 않았습니다. 드라이브는 약 5개월 동안 사용되었으며 현재는 정상적으로 작동하는 것 같습니다.

다양성

나는 지난 몇 년 동안 다른 USB HDD(16개월보다 오래된 것은 없음)와 다른 커널 버전을 실행하는 다른 Linux 시스템에서 동일한 상황을 여러 번 경험했습니다. 처리 시 유일한 차이점은 때때로 SysRq 대신 전원 버튼을 사용하여 시스템을 종료한다는 것입니다.

e2fsck각 사건마다 다음을 사용하여 잠재적으로 영향을 받을 수 있는 모든 파일 시스템(모든 ext2 및 ext4)을 확인했습니다.

1. 파일 시스템을 정리하십시오.

2. e2fsck는 로그(ext4)를 재생하여 더티 파일 시스템을 복구할 수 있습니다.

3. 파일 시스템에 잘못된 여유 블록 및 여유 inode 수가 표시되는데, 이는 e2fsck로 수정할 수 있습니다.

4. e2fsck가 Lost+found에 연결된 분리된 inode를 포함하는 파일 시스템입니다.

5. e2fsck에 의해 복제된 다중 요청 inode(여러 파일에 의해 요청됨)를 포함하는 파일 시스템입니다.

실제적인 문제

위 상황의 영향을 받고 e2fsck에 의해 성공적으로 복구된 ext2 또는 ext4 파일 시스템은 확실히 일관된(깨끗한) 상태입니다.

하지만 해당 파일 시스템에 있는 파일의 내용과 메타데이터는 어떻습니까?

e2fsck에서 발견한 파일 시스템 손상과 데이터 손상 사이에 고유한 상관 관계가 있습니까? 예를 들어:

파일 시스템에서 잘못된 개수 외에 다른 손상이 발견되지 않으면 실제 파일 데이터에는 아무런 문제가 없습니다.

또는:

파일 시스템에 다중 선언된 inode가 포함되어 있으면 하나 이상의 파일 내용이 손상됩니다.

아니면 그 반대입니까? 파일 시스템과 파일 데이터는 독립적입니다. 적어도 장치의 통신 수준에서 손상을 일으키는 원인이 무엇인지 정확히 알지 못한 채 하나의 손상으로 다른 하나가 손상되었다고 결론을 내릴 수 없기 때문입니다.

후자의 경우 나중에 파일 시스템이 깨끗한 것으로 확인되더라도 설명된 상황으로 인해 파일 내용이 손상될 수 있습니다. 옳은?

e2fsck에서 발견한 파일 시스템 오류를 기반으로 파일 무결성을 평가하는 데 사용할 수 있는 경험적 값이나 합리적인 기준이 있습니까?

이러한 맥락에서,답변질 도착"fsck로 수행된 파일 시스템 수정을 테스트하는 방법"좋은 책이다.

파일 시스템과 데이터 무결성의 차이점은 다음과 같습니다.ext4 파일 시스템에 대한 커널 문서. 후자의 경우, 나는 훌륭한 것에 깊은 인상을 받았습니다.답변미켈 도착"정전 후에도 저널 파일 시스템이 손상되지 않는다고 보장할 수 있나요?", 이는 이 주제와도 매우 관련이 있습니다.

자신의 추측과 영향

Systemd는 서비스 단위(템플릿)를 제공합니다.[이메일 보호됨]passno기본적으로 시작 시 /etc/fstab에서 선택한 파일 시스템을 "그루밍"합니다. -p매뉴얼 페이지의 옵션 설명 에 따르면e2fsck(8), "수동 개입 없이 안전하게 복구할 수 있는 모든 파일 시스템 문제를 자동으로 복구"하도록 구성되었습니다. 불행하게도 설명에서는 "보안"이 파일 시스템 일관성만을 가리키는지 아니면 파일의 내용과 메타데이터도 포함하는지 여부를 지정하지 않습니다.

그러나 Systemd 서비스는 사용자에게 완전히 투명한 방식으로 조각 모음을 시작하기 때문에 적어도 일부 전문가는 해당 파일 시스템 복구 결과에 대해 완전한 확신을 가지고 있습니다.

따라서 막연한 느낌(!)을 바탕으로 깨끗한 파일 시스템(위의 오류 상태 1)과 로그를 재생하여 수정할 수 있는(오류 상태 2)을 사용하면 파일 자체가 다음과 같다고 가정하는 것이 안전하다고 말하고 싶습니다. 그러한 사건 이후에도 손상되지 않았습니다.

반면에 오류 상태 5의 파일 시스템에 대해서는 백업을 참조하겠습니다.

그렇다면 왜 이렇게 소란을 피우는 걸까요? 동의함: 표준 기본 또는 루트 파일 시스템인 경우 해당 내용을 최신 백업과 비교합니다. 하지만 이 경우 이러한 백업은 영향을 받는 USB HDD 자체에 있습니다. 무결성이 의심되는 경우 즉시 여러 컴퓨터를 다시 백업해야 합니다. 또한 이는 해당 드라이브의 순환 백업 전략 중에 누적된 오래된 백업을 생성하며 그렇지 않으면 해당 데이터의 스냅샷으로 의미 없이 사용될 수 있습니다.

따라서 설명된 시나리오의 영향을 받은 후 수정된 ext2 또는 ext4 파일 시스템의 데이터를 얼마나 신뢰할 수 있는지에 대한 합리적이고 신뢰할 수 있는 표준을 갖는 것이 유용할 것입니다.

추가 발견

스스로 알아내려고 노력하면서 이것이 훌륭하다는 것을 알았습니다.장fsck에 대한 자세한 내용은 Sun용 Oracle 시스템 관리 설명서를 참조하십시오. fsck의 USF 버전을 설명하지만 일반적인 아이디어는 e2fsck에도 적용됩니다. 그러나 이 매우 상세한 문서는 fsck의 페이로드를 고려하기보다는 fsck의 사용과 파일 시스템 자체에 초점을 맞추고 있습니다.

존재하다이 답변도착하다"ext4에서 fsck -p(preen)는 무엇을 합니까?", Noah는 fsck가 ext4 파일 시스템 조각 모음을 수행하여 자동으로 처리할 수 있는 파일 시스템 오류 목록과 자동으로 처리할 수 없는 오류 목록을 게시했습니다. 물론 상관관계가 존재한다고 가정할 때, 어떤 오류가 파일 데이터 손상을 의미하는지, 어떤 오류는 그렇지 않은지를 나타내는 파일 시스템 오류 목록이 있으면 좋을 것입니다.

이것은 그의 것입니다답변, Michael Prokopec은 이 문제에 대한 쓰기 캐싱의 중요성을 언급했습니다. 이와 관련해서 찾아보니답변키가 큰 Jeff가 도착합니다."SATA 디스크가 쓰기 캐싱을 올바르게 처리합니까?"적어도 대부분의 SATA 드라이브에는 기본적으로 쓰기 캐싱이 활성화되어 있습니다. 그러나 같은 기사에 따르면 드라이브는 이러한 캐시를 가능한 한 빨리 플러시하려고 시도합니다. 물론 보장은 없지만...