이는 하드웨어 RAID의 LUKS 암호화에서 LVM으로 관리되는 논리 볼륨의 ext4 파일 시스템에 관한 것입니다. 운영 체제는 일반 Ubuntu 22.04 LTS입니다.
불행히도 RAID는 최근에 실패했으며 파일 시스템은 그 당시 읽기 전용으로 다시 매핑되었습니다. 해당 파일 시스템에 대한 모든 응용 프로그램 쓰기를 중지한 후 행운을 빌어 RAID를 완전히 복원할 수 있습니다. 그리고 운이 좋게도 파일 시스템은 복원된 데이터로 여전히 완전히 읽을 수 있습니다! 그리고 e2fsck오류도 발견하지 못했습니다.
그럼 다 괜찮아요? 불행히도. 불행하게도 메모리에는 아직 기록되지 않은 데이터가 꽤 많이(수백 메가바이트) 남아 있으며 이를 디스크로 가져오는 방법을 모르겠습니다. 그렇기 때문에 아직 재부팅하지 않은 것이고, 재부팅하고 싶지 않은 이유이기도 합니다. 누락된 데이터가 있는 데이터베이스 파일을 모두 복구하는 것이 큰 작업이 될 것이기 때문입니다. 기록되지 않은 데이터의 존재는 다음을 통해 쉽게 확인할 수 있습니다.
sync ; grep Dirty /proc/meminfo
일반적으로 몇 킬로바이트만 생성하지만 내 경우에는 수백 메가바이트를 생성합니다. 안타깝게도 데이터가 존재하는 다양한 커널 드라이버의 수준이 물리적 디스크 캐시인지, 볼륨 그룹 중 하나인지, 실제 파일 시스템인지는 알 수 없습니다.
지금까지 시도한 수리
나의 첫 번째 시도는 다음을 통해 여전히 읽기 전용 파일 시스템을 읽기-쓰기로 다시 마운트하는 것이었습니다.
mount -o remount /dev/mapper/vg1-data
불행하게도 다음과 같은 오류 메시지가 나타납니다.
mount: /data: cannot remount /dev/mapper/vg1-data read-write, is write-protected.
그러나 실제 볼륨은 다음을 통해 확인할 수 있듯이 읽기-쓰기입니다.
cat /sys/block/dm-*/ro
0이는 RAID 상단의 볼륨을 포함하여 장치 매퍼가 제어하는 모든 것에 대한 결과를 제공합니다 . 실제 장치 자체에서도 마찬가지입니다 sd. 뿐만 아니라:
dmsetup info vg1-data
볼륨 상태를 으로 보고합니다 ACTIVE. 대신 ACTIVE (READ-ONLY)읽기 전용인 경우 상태를 으로 보고합니다 . 마찬가지로 lvs의 일반 속성을 보여줍니다 -wi-ao----.
큰 단서, 파일 시스템의 읽기-쓰기 기능이 실제로 문제의 원인이 아니라는 사실은 를 통해 확인할 수 있습니다 tune2fs -l. 이는 다른 많은 통계 중에서 마운트된 파일 시스템의 마지막 오류에 대한 다음 정보를 인쇄합니다.
Last error time: Wed Jan 17 18:47:43 2024
Last error function: ext4_remount
Last error line #: 5822
Last error err: EBUSY
해당 오류가 발생했을 때 syslog에 다음과 같은 비밀스러운 줄이 기록되었습니다.
EXT4-fs error (device dm-N): ext4_remount:5822: comm mount: Abort forced by user
다음을 통해 볼륨을 읽기 전용 모드로 명시적으로 강제하는 경우:
dmsetup table vg1-data | dmsetup reload -r vg1-data
dmsetup resume vg1-data
dmsetup info vg1-data
그런 다음 추가 재 mount시도는 더 이상 "마지막 오류 시간" 타임스탬프를 업데이트하지 않지만 동일한(이제 분명히 올바른) 오류 메시지를 생성합니다. 다시 사용하여 dmsetup볼륨을 읽기-쓰기로 만든 후 추가 재 mount시도를 통해 마지막 오류의 타임스탬프가 다시 업데이트되고 syslog에도 다시 기록됩니다.
다른 서버 오류 게시물에서 디스크 매퍼 볼륨을 읽기 전용으로 설정한 다음 다시 읽기-쓰기로 설정하라는 힌트를 찾았지만 그 역시 효과가 없었습니다.Linux 소프트웨어 RAID 1 - 하나의 디스크에 결함이 발생한 후 루트 파일 시스템이 읽기 전용이 됩니다.
cryptsetup reload또한 아무것도 달성하지 못했습니다.