☰

걱정해야 할까요? LVM 스냅샷을 병합할 때(원본 데이터를 스냅샷으로 복원) 시스템 로그에 분할 오류가 보고되었습니다.

tag-icon • tag-icon linux lvm segmentation-fault snapshot
걱정해야 할까요? LVM 스냅샷을 병합할 때(원본 데이터를 스냅샷으로 복원) 시스템 로그에 분할 오류가 보고되었습니다.

방금 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

시스템 로그에서:

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 segfault가 발생한다는 것입니다.최근에 수정된 버그인 것 같습니다.따라서 모든 시스템 업데이트가 있는지 확인하는 것이 좋습니다.)

일반적으로 LVM에 문제가 있는지 여부에 대해 너무 주저하거나 편집증적이어서는 안 됩니다. LVM은 이러한 예상치 못한 오류를 매우 잘 처리하도록 설계되었습니다(사용 중인 도구뿐만 아니라 직접적인 영향을 주더라도). 이는 전통적인 파티셔닝 대신 볼륨 관리자를 사용하는 요점의 일부입니다. 너에게 무슨 일이 생기면 곤란해질 뿐이야진짜나쁜 일이 일어나거나, 깊게 생각하지 않고 어떤 일을 하게 됩니다. LVM은 블록이 아닌 익스텐트별로 작동하며 복사 작업이 성공적으로 완료될 때까지 복사된 익스텐트를 활성화하고 원래 익스텐트를 비활성화하지 않습니다. 이렇게 하면 복사된 범위의 절반이 할당되지 않은 것으로 표시되고 후속 도구가 이를 덮어쓰게 됩니다. 이것은 내 pvmove와 lvchange 모두에 해당됩니다.

편집하다:

보고 있다이 메일링 리스트에 대한 공지, 병합이 실제로 "내부적으로" 어떻게 작동하는지 자세히 설명할 수 있습니다.

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

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

답변2

무거운 작업은 커널(장치 매퍼)에 의해 처리되지만 데이터 자체는 안전해야 합니다. 그러나 LVM 사용자 수준 도구는 여전히 중요한 목적을 수행합니다. 이는 장치 매퍼 자체가 알지 못하거나 신경 쓰지 않는 저장 내용, 위치 및 저장 방법에 대한 LVM 메타데이터를 보존합니다.

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

Segfaulting은 결코 좋은 일이 아닙니다. LVM 도구에 이런 일이 발생하면 해당 도구 사용을 중단하고 안정적인 LVM 버전으로 전환해야 합니다. 그리고 문제를 추적하고 영구적으로 수정할 수 있도록 버그가 배포판에 보고될 수 있습니다.

관련 정보