걱정해야 할까요? LVM 스냅샷을 병합할 때 syslog에 세그폴트가 보고됨(원본을 다시 스냅샷으로 되돌림)

걱정해야 할까요? LVM 스냅샷을 병합할 때 syslog에 세그폴트가 보고됨(원본을 다시 스냅샷으로 되돌림)

저는 Ubuntu 12.10의 LVM에서 스냅샷을 실험하고 있었습니다. 6.5GiB의 스냅샷 논리 볼륨을 생성하고 원본을 일부 변경한 후 스냅샷을 다시 병합하여 실행 취소하기로 결정했습니다. 모든 것이 잘 진행되는 것 같았지만 syslog에서 여러 LVM 관련 세그폴트 메시지를 발견했습니다.

입력된 명령:

sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup

syslog에서:

Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]

그런 다음 원본 LV를 마운트 해제하고 스냅샷이 더 이상 존재하지 않는지 확인한 후 실행했습니다 fsck.ext4 -f. 그런 식으로 확인되었습니다. 하지만 여전히 세그폴트가 걱정됩니다. fsck가 포착하지 못하는 방식으로 내 데이터가 엉망이 될 가능성이 있습니까? 제가 실험하고 있던 볼륨은 백업 볼륨이었는데, 여기에 백업한 모든 파일 시스템이 여전히 제대로 작동하고 있으므로 처음부터 다시 시작해서 백업하면 됩니다. 하지만 반면에 증분 백업 기록을 유지하고 싶습니다. 나는 이 백업을 신뢰할 수 있다는 확신을 갖고 싶습니다.

답변1

네, 확실히 버그입니다. 하지만 걱정하지 마세요. LVM은 이 문제를 처리할 만큼 똑똑합니다. 한때 pvmove 도중에 전원이 꺼진 적이 있는데 기본적으로 서버를 다시 켜는 것 "취소"만 하면 되었습니다. 이전 pvmove를 다시 시작하세요.

우선, 사용하는 도구가 커널 프로세스에 대한 사용자 공간 인터페이스일 뿐이라는 점을 아는 것이 중요합니다. LVM은 커널 내부에 있으므로 커널 패닉이 발생하지 않는 한 괜찮습니다. pvmove 또는 lvchange와 같은 사용자 공간 도구는 우리를 위해 LVM과 인터페이스를 제공하고 기본적으로 커널에 "아직 작업을 완료했나요? 어떻게 됐나요?"라고 묻습니다. 또는 "이봐, 우리 이거 얼마나 진행됐어?" (귀하의 특정 문제는 lvchange가 성공적으로 완료된 후 lvchange segfaulting과 관련되어 있습니다.최근에 수정된 버그 같은데따라서 모든 시스템 업데이트가 있는지 확인하는 것이 좋습니다.)

일반적으로 LVM에 문제가 있는지 여부에 대해 너무 미끄럽거나 편집증적이어서는 안 됩니다. LVM은 이와 같은 예상치 못한 오류를 잘 처리하도록 설계되었습니다(사용 중인 도구뿐만 아니라 직접적인 영향을 미치는 경우에도 마찬가지). ) 그리고 그 보장은 기존 파티션에 비해 볼륨 관리자를 사용하는 요점의 일부입니다. 문제가 있는 경우에만 문제가 발생합니다.정말나쁜 일이 일어나거나 깊이 생각하지 않고 어떤 일을 하게 됩니다. LVM은 블록 대신 익스텐트별로 작동하며 복사 작업이 이미 성공적으로 완료될 때까지 복사된 익스텐트를 활성화하고 원본을 비활성화하지 않습니다. 이렇게 하면 절반만 복사된 익스텐트가 할당되지 않은 것으로 표시되고 후속 도구가 이를 덮어쓰게 됩니다. 이것은 내 pvmove와 귀하의 lvchange의 경우입니다.

편집하다:

보고이 메일링 리스트 발표, 병합이 실제로 "내부"에서 어떻게 작동하는지에 대한 자세한 설명을 얻을 수 있습니다.

병합이 활성화된 동안 원본 장치에 대한 모든 액세스는 병합 중인 스냅샷으로 [이동]됩니다. 병합이 완료되면 원본 대상이 원활하게 다시 로드되고 병합 스냅샷이 삭제됩니다. [비스냅샷] 파일 시스템은 이 시간 동안 마운트된 상태를 유지할 수 있습니다.

알아두면 흥미로울 것 같아요

답변2

무거운 작업은 커널(장치 매퍼)에 의해 처리되지만 데이터 자체는 안전해야 합니다. 그러나 LVM 사용자 영역 도구에는 여전히 중요한 기능이 있습니다. 이들은 장치 매퍼 자체가 알지도 관심도 없는 LVM 메타데이터, 즉 무엇을 어디에 어떻게 저장했는지 유지합니다.

이러한 메타데이터를 업데이트하는 중에 LVM 도구에서 세그먼트 오류가 발생하면 데이터가 손실될 수 있습니다. 어떤 면에서 LVM은 파티션을 위한 파일 시스템입니다. 손상된 LVM 메타데이터는 파일 시스템 슈퍼블록을 잃는 것과 같습니다. 이것이 바로 거의 모든 변경 사항이 /etc/lvm/....

Segfault는 결코 좋지 않습니다. LVM 도구가 이 작업을 수행하는 경우 해당 도구 사용을 중단하고 안정적으로 작동하는 LVM 버전으로 전환해야 합니다. 그리고 아마도 배포판에 버그를 보고하여 문제를 추적하고 영구적으로 수정할 수 있습니다.

관련 정보