LVM 물리 볼륨에서 불량 블록을 확인하는 방법은 무엇입니까?

ext4를 사용하면 해당 명령 e2fsck -c /dev/sda1이나 다른 명령을 사용하여 불량 블록을 확인할 수 있습니다. 그러면 블록을 불량 블록 inode에 추가하여 블록을 "블랙리스트"로 만듭니다.

e2fsck -cbadblocks기본 하드 디스크에서 실행됩니다 . badblocksext 파일 시스템이 포함된 하드 디스크에서와 마찬가지로 LVM 물리 볼륨에서 직접 이 명령을 사용할 수 있습니다 (PV가 실제로 하드 디스크이고 MD 소프트웨어 RAID 장치와 같은 다른 유형의 가상 장치가 아니라고 가정).

이는 파일 시스템에 어떤 종류의 불량 블록 정보도 추가하지 않지만 하드 드라이브가 불량 블록을 처리하도록 되어 있는 파일 시스템의 유용한 기능은 아니라고 생각합니다.

badblocks디스크에서 SMART 자체 테스트를 실행하는 것보다 훨씬 좋습니다( /dev/sdX하드 드라이브의 장치 이름으로 대체).

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

테스트 자체에는 몇 시간이 소요됩니다(정확히 시간이 얼마나 걸리는지 알려줍니다). 완료 후 smartctl -a쿼리 결과를 통해 셀프 테스트 로그를 검색할 수 있습니다. "성공적으로 완료되었습니다"라고 표시되면 하드 드라이브에 문제가 없는 것입니다.

즉, LVM을 사용하지 않고 불량 블록을 어떻게 확인합니까?

앞서 말했듯이 하드 드라이브 자체는 손상된 블록을 사용하지 않도록 하며 해당 블록에서 데이터를 재배치합니다. 이는 파일 시스템이나 LV가 수행해야 하는 작업이 아닙니다. 반면, 하드 드라이브에 불량 블록이 여러 개 있는 경우 해당 블록을 재배치할 필요는 없지만 오류가 발생했기 때문에 전체 하드 드라이브를 교체하려고 합니다.

나는 LVM이 기본 스토리지에서 불량 블록을 처리하지 않을 것이라고 확신합니다. 이는 전부는 아니지만 대부분의 최신 하드 드라이브에 해당됩니다. 해당 섹터에 써야 할 수도 있지만 디스크는 해당 섹터를 다시 매핑해야 합니다. (예를 들어 먼저 오프라인 표면 스캔을 수행하는 데 필요할 수 있습니다 smartctl /dev/sda -t offline.)

즉, LVM은 사용자가 요청하지 않는 한 실제로 데이터를 이동하지 않습니다 pvmove. 따라서 ext4 badblocks 기능을 사용할 수 있습니다. 실행 중인 경우 불량 블록을 다시 확인하면 됩니다 pvmove. 데이터를 이동하는 일반적인 작업(예:)은 없습니다 lvextend.

LVM은 "논리 범위 0-99는 물리적 범위 200-299"라는 매핑을 유지한 다음 확장하면 "논리 범위 100-199는 물리적 범위 100-199"만 추가하기 때문에 확장 시 데이터가 이동되지 않습니다. 또는 "논리 확장 영역 100-149는 물리적 확장 영역 50-99이고, 논리적 확장 영역 150-199는 물리적 확장 영역 140-189입니다." LVM은 물리적 범위가 순서가 잘못되었거나 연속되지 않은 경우에는 신경 쓰지 않습니다.

pvckLVM 메타데이터를 확인할 수 있으며 일관성은 파일 시스템의 작업입니다. LVM은 볼륨 관리에만 관여하므로 특정 범위를 구성하는 공간이 손상되었는지 여부에 신경 쓸 필요가 없습니다. 더 높은 수준의 소프트웨어가 이러한 문제를 포착하기 때문입니다. 그럼에도 불구하고 LVM 메타데이터는 물리 볼륨의 첫 번째(그리고 마지막) 섹터만 차지합니다.

상당한 규모의 PV(생산에서 볼 수 있는 것과 같은)의 첫 번째 섹터와 마지막 섹터가 동시에 실패하는 경우 천문학적으로 불가능하기 때문에 기본적으로 세계 최악의 행운을 누리게 됩니다. 그렇지 않고 관리자가 드라이브의 여러 섹터에 오류가 있다는 사실을 알게 되면 대부분의 사람들은 "하드 드라이브가 영구적으로 오류가 발생하여 교체가 필요함" 아래에 이와 같은 내용을 제출할 것입니다.

오류가 반환 되면 LVM 메타데이터가 어딘가에 pvck백업되었는지 확인할 수 있습니다 . /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를 수행하고 백업 전략을 가지고 있기 때문에 큰 문제가 아닙니다.

논리 볼륨을 마운트할 때 불량 블록을 확인하십시오.

1단계: 논리 볼륨의 이름을 확인합니다.

ll /dev/mapper

2단계: 불량 블록을 확인합니다.

sudo badblocks -o bad-blocks.txt -n -s -v -f /dev/mapper/ubuntu--vg-my_drive--lv