btrfs: 논리적 체크섬/헤더 오류

btrfs: 논리적 체크섬/헤더 오류

저는 BTRFS를 거의 2년 동안 아무런 문제 없이 파일 시스템으로 사용해 왔습니다. 그런데 어제 파일 시스템이 자동으로 읽기 전용으로 전환되는 문제가 발생했습니다. 컴퓨터를 다시 시작하면 읽기-쓰기 모드로 올바르게 설치되지만 잠시 후 자동으로 읽기 전용 모드로 전환됩니다. 많은 조사 끝에 문제를 BTRFS 오류로 분류했습니다.

달리고 난 후

btrfs scrub start /dev/sda5

나는 내에서 다음을 발견했습니다dmesg

[  107.910348] BTRFS warning (device sda5): checksum/header error at logical 100470390784 on dev /dev/sda5, physical 36045881344: metadata leaf (level 0) in tree 7
[  107.910354] BTRFS warning (device sda5): checksum/header error at logical 100470390784 on dev /dev/sda5, physical 36045881344: metadata leaf (level 0) in tree 7
[  107.910364] BTRFS error (device sda5): unable to fixup (regular) error at logical 100470390784 on dev /dev/sda5

그래서 파일 시스템에 뭔가가 손상되었습니다. 또한 이것이 /dev/sda5내 루트 파티션이 있는 곳이라는 점을 지적해야 합니다 . 그러나 대부분의 경우 모든 것이 잘 작동하기 때문에 이것이 중요한 것은 아닌 것 같습니다. 나는 무언가가 때때로 손상된 블록이나 파일에 대한 디스크 액세스를 트리거하여 BTRFS가 충돌하고 읽기 전용 모드로 전환되어야 한다고 생각했습니다.

두 번 실행했는데 btrfs scrub start /dev/sda5출력은 다음과 같습니다.

UUID:             8b0f88e4-8fb2-4201-8cfa-ed08f40fb185
Scrub started:    Wed Sep 18 14:26:47 2019
Status:           finished
Duration:         0:03:56
Total to scrub:   101.19GiB
Rate:             439.09MiB/s
Error summary:    verify=1
  Corrected:      0
  Uncorrectable:  1
  Unverified:     0

내 루트 파티션 이므로 /dev/sda5설치하는 동안 아무것도 할 수 없습니다. 그래서 라이브 USB를 사용하여 머신으로 부팅하고 실행했지만 btrfs rescue zero-log /dev/sda5문제가 해결되지 않았습니다.

도움이 될 수 있는 기타 정보. 저는 Arch Linux와 5.2.11-arch1-1-ARCH를 사용하고 있습니다. 저도 며칠 전에 Dropbox를 설치했기 때문에 Dropbox가 범인이 아닐까 의심했지만, 프로그램을 제거하고 Dropbox 폴더를 삭제해도 문제가 해결되지 않았습니다.

저는 이전에 이 문제를 처리한 적이 없으며 시스템이 읽기 전용 모드로 잠길 때마다 재부팅할 수 없는 것 같습니다. 어떤 도움이라도 대단히 감사하겠습니다.

답변1

다른 사람들도 이 부분적인 답변 이상의 것을 기대할 수 있기를 바랍니다. 그러나 다음과 같습니다.

Btrfs는 파일 시스템에서 사용하는 각 블록에 대한 체크섬을 저장합니다. 이 오류 메시지는 btr이 블록을 읽었으나 체크섬이 일치하지 않았음을 의미합니다. 일반적으로 이는 쉽게 복구할 수 있는(백업에서 파일 교체) 사용자(파일) 데이터 블록입니다. 그러나 이 경우에는 파일 시스템 메타데이터 블록입니다.

이상적으로 체크섬 손상은 하드웨어 문제(예: 디스크의 "비트 부패")로 인해 발생합니다. 그리고 btrfs는 디스크가 하나만 있는 경우에도 일반적으로 두 개의 메타데이터 복사본을 저장합니다(메타데이터 구성 파일 DUP). 따라서 btrfs scrub이 문제는 일반적으로 다른 복사본을 보면 해결됩니다. 해당 복사본이 없거나(파일 시스템이 생성되었거나 단일 메타데이터 프로필로 변환됨) 두 복사본이 모두 손상되었습니다.

가장 먼저 해야 할 일은(실제로 이와 같은 단계 전에 수행해야 하는 zero-log) 특히 중요한 파일의 백업이 있는지 확인하는 것입니다.

그 후에는 새 파일 시스템을 생성하고 데이터를 복사하여 다시 작동하게 할 수 있습니다. 내가 드릴 수 있는 유일한 조언은btrfs 메일링 리스트에 문의하세요.

관련 정보