하드웨어 오류로 인해 일부 손상이 있는 btrfs 디스크가 있고 일부 파일을 복사할 때 I/O 오류가 발생합니다. btrfs 스크랩을 실행했고 csum 오류가 보고되었을 때 오프라인으로 가져와 스크랩을 실행했는데 btrfs check --check-data-csum다음 수십 줄이 반환되었습니다.
mirror 0 bytenr 549766098944 csum 1874004453 expected csum 2335064354
내가 아는 한, 를 --backup사용하여 이 문제를 해결하는 것이 매우 가능합니다. 하지만 이것은 qemu용 가상 디스크 저장소이며, 이렇게 하면 가상 디스크(특히 Windows 디스크)의 내부 일관성이 손상될까 걱정됩니다.
btrfs 맨페이지에는 --init-csum-tree다른 위험한 명령 옆에 플래그가 언급되어 있습니다. 이것이 이 기능을 사용하는 좋은 이유입니까, 아니면 다른 옵션이 있습니까?
CentOS Linux 7, 커널 3.10.0-514.26.2.el7.x86_64
btrfs-progs 버전 4.4.1 릴리스 1.el7
디스크는 WD 레드 6TB(5.5TiB) WD60EFRX, 5.5TiB 파티션 1개입니다.
가상 디스크는 .qcow2 형식입니다.
답변1
btrfs의 가상 머신 이미지에는 알려진 문제가 있습니다. 따라서 귀하의 데이터는 실제로 괜찮습니다. 앞으로는 이러한 경고/오류가 더 많이 발생할 것으로 예상됩니다. https://www.spinics.net/lists/linux-btrfs/msg25940.html
답변2
체크섬이 불량하면 데이터도 불량일 수 있습니다. 체크섬 트리를 지우는 것(이것이 하는 일 --init-csum-tree)은 문제를 해결하지 못하고 단지 불량 데이터를 사용자 공간에 직접 노출시키고 이전 데이터의 어떤 것도 감지하지 못하게 합니다. 다른 비트는 FS에서 썩었습니다. 기본적으로 디스크에는 데이터 복사본이 하나만 있고 해당 복사본이 손상되었으므로 더 이상 데이터에 대해 걱정할 필요가 없습니다.잠재적으로이러한 디스크 이미지는 데이터 손상이 거의 확실하기 때문에 좋지 않습니다. 12개 정도의 오류 메시지만 표시된다면 더 이상 그런 일이 발생하지 않을 것입니다.많은BTRFS가 블록 수준에서 체크섬을 수행하므로 최소한 각 손상은 4-16KiB의 데이터에 해당해야 하므로 이는 좋은 것입니다.
이 경우 실제로 btrfs restore디스크에서 다른 위치로 파일을 가져오거나 백업에서 복원하는 방법을 사용하는 것이 좋습니다. 디스크가 하나만 있고 데이터 복사가 없는 경우 체크섬 오류가 발생하면 알려진 양호한 데이터를 새 위치로 복원하는 것 외에는 할 수 있는 일이 많지 않습니다.