답변:
ext4를 사용하는 경우 명령 등으로 불량 블록을 확인할 수 있습니다
e2fsck -c /dev/sda1. 불량 블록 아이 노드에 블록을 추가하여 "블랙리스트"합니다.
e2fsck -cbadblocks기본 하드 디스크에서 실행 됩니다. badblocks하드 디스크에서 해당 명령을 사용하는 것처럼 PV가 실제로 하드 디스크이고 다른 유형의 가상 장치가 아니라고 가정하면 LVM 물리 볼륨에서 직접 명령을 사용할 수 있습니다. ext 파일 시스템을 포함합니다.
파일 시스템에 잘못된 블록 정보를 추가하지는 않지만 파일 시스템의 유용한 기능이라고 생각하지 않습니다. 하드 디스크는 불량 블록을 처리해야합니다.
badblocks디스크에서 SMART 자체 테스트를 실행하는 것보다 낫습니다 ( /dev/sdX하드 디스크의 장치 이름으로 교체 ).
smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less
시험 자체는 몇 시간이 걸릴 것입니다 (정확한 시간을 알려줍니다). 완료되면로 결과를 쿼리 smartctl -a하고 자체 테스트 로그를 찾을 수 있습니다. "성공적으로 완료되었습니다"라고 표시되면 하드 디스크에 문제가없는 것입니다.
즉, LVM에서 사용하지 않는 불량 블록을 어떻게 확인할 수 있습니까?
내가 말했듯이, 하드 디스크 자체는 손상된 블록을 사용하지 않도록하고 해당 블록에서 데이터를 재배치합니다. 그것은 파일 시스템이나 LV가해야 할 일이 아닙니다. 반면에, 하드 디스크에 불량 블록이 몇 개 이상있는 경우, 블록을 재배치하는 것을 원하지 않지만 전체 하드 디스크가 고장 나서 교체해야합니다.
dd. 생각보다 자주 미디어가 실제로 훌륭하고 데이터가 손상되었으므로 다시 매핑 할 필요없이 미디어를 덮어 씁니다.
dd하지만 여전히해서는 안됩니다. md습격 이있는 경우 문제를 처리 할 수 있습니다 . @derobert 아마 디스크가 포함되지 않은 경우 어떻게 해야할지 것입니다 md:) 습격
LVM이 불량 블록을 처리하지 않는다고 확신합니다. 기본 스토리지를 기대합니다. 그리고 전부는 아니지만 대부분의 최신 하드 디스크가 사용합니다. 섹터에 쓰기를 수행해야 할 수도 있지만 디스크는 다시 매핑해야합니다. (예 :로 오프라인 표면 스캔을 먼저 수행해야 할 수도 있습니다 smartctl /dev/sda -t offline).
즉, LVM은 요청하지 않는 한 실제로 데이터를 이동하지 않습니다 (예 :) pvmove. 따라서 ext4 배드 블록 기능을 사용할 수 있습니다. 실행하면 불량 블록이 있는지 다시 확인해야합니다 pvmove. 일반적인 작업 (예 lvextend:)은 데이터를 이동 하지 않습니다 .
LVM에서 "논리적 범위 0–99는 물리적 범위 200–299"라는 맵을 유지하기 때문에 Extend는 데이터를 이동하지 않으며,이를 확장 할 때 "논리적 범위 100–199는 물리적 범위 100-199"를 추가합니다. 또는 "논리적 범위 100-149는 물리적 범위 50–99이고 논리적 범위는 150-199는 물리적 범위 140-189"입니다. LVM은 물리적 범위가 순서가 맞지 않거나 연속적이지 않은 것을 신경 쓰지 않습니다.
pvck일관성이 파일 시스템의 작업 인 후 LVM 메타 데이터를 확인할 수 있습니다. LVM은 볼륨 관리에 관한 것이므로 특정 수준을 구성하는 공간이 나쁜 경우 신경 쓰지 않아도됩니다. LVM 메타 데이터는 어쨌든 물리 볼륨의 첫 번째 (선택적으로 마지막 섹터) 만 차지합니다.
생산에서 볼 수 있듯이 합리적으로 큰 PV의 첫 번째 및 마지막 섹터가 동시에 실패하면 기본적으로 천문학적으로 가능성이 거의 없기 때문에 세계에서 가장 운이 좋지 않습니다. 그렇지 않으면, 관리자가 드라이브의 여러 섹터가 고장났다는 것을 알고 있다면, 대부분의 사람들은 "하드 드라이브가 영구적으로 고장 나서 교체해야합니다."에서 이와 같은 내용을 제출하면됩니다.
경우 pvck반환 오류, 당신은 당신의 LVM 메타 데이터에 백업되어 있는지 확인할 수 있습니다 /etc/lvm곳. 그렇다면 pvcreate백업 사본을 지정할 수 있습니다.--restorefile
통사론:
pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>
예:
pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2
복원이 작동하지 않는 경우 (예를 들어, 첫 번째 섹터가 불량한 경우) 위의 작업을 다시 수행 할 수 있지만 --metadatacopies 2메타 데이터를 첫 번째 및 PV의 마지막 섹터. pvscan부팅 할 때 두 위치를 모두 확인하고 메타 데이터를 찾으면 체크섬과 비교하여 확인합니다. 체크섬이 첫 번째 섹터에서는 실패하지만 마지막 섹터에서는 성공하면 치명적이지 않은 오류 메시지가 표시됩니다.
수동과 고통의 종류이지만 다시 한 번 사람들이 BTRFS로 볼륨 관리 리덕스를 얻는 것에 흥분하는 이유 중 하나입니다. 대부분의 경우 derobert가 언급 한 이유 때문에 실제로 그렇게 큰 문제는 아니며 데이터의 연속성을 절대적으로 긍정적으로 보장 해야하는 사람들은 일반적으로 RAID를 수행하고 백업 전략을 가지고 있기 때문입니다.
-c완전한 의미없는 것을 호출하기 전에 수행 할 작업 을 확인할 수 있습니다 .