나는 데이터 캐시를 보유하고 있는 루트가 아닌 ext4 파일 시스템의 주기적인 손상을 다루고 있습니다. 캐싱은 특히 나중에 처리하기 쉽도록 이미지를 조각으로 자르는 데 사용됩니다.
응용 프로그램 로그 오류:
OSError: [Errno 74] Bad message: '/redacted/path/to/sliced/image/data'
오류는 다음과 /var/log/syslog같습니다
kernel: [163197.788364] EXT4-fs error (device md127): ext4_lookup:1590: inode #125532502: comm python3.6: iget: checksum invalid
파일 시스템은 SSD 3개가 있는 RAID5 어레이에 있습니다.
나중에 실행하면 fsck항상 문제가 해결됩니다. 적어도 지금까지 문제가 4-5번 발생했습니다. 그러나 실행 중인 프로세스를 다시 시작하는 것은 분명히 골치 아픈 일이며 이 예외( OSError)를 무시하고 다른 많은 문제를 가리는 것은 현명하지 않은 것 같습니다.
파일이 작성된 시점(예외가 발생하기 몇 시간 전)을 정확하게 추적할 수 있었지만 /var/log/syslog그 당시에도 아무런 문제가 보고되지 않았습니다.
ext4 파일 시스템 손상의 일반적인 원인은 무엇입니까? 예를 들어, 특히 Python에서 일반적으로 막대한 피해를 초래하는 프로그래밍 오류(예: 부적절한 잠금 사용)는 무엇입니까? 커널이나 하드웨어의 버그로 인해 시스템 로그에 오류가 없는 경우가 종종 있습니까?
답변1
이런 오류,모든 오류는 inode 체크섬 실패라고 가정합니다., ext4fs 모듈을 나타냅니다.생각하다메타데이터가 손상되었습니다. 물론, 다른 오류도 표시된다면 이는 분명히 답이 아닙니다.
Inode 체크섬 오류는 inode 구조에 대한 ext4fs 계층의 의견에 동의하지 않는 일부 하위 수준 도구나 모듈(Python은 아님!)로 인해 발생합니다. 단일 비트를 업데이트하지 않으면 체크섬 오류가 발생합니다.
전체 inode 작업은 커널, 파일 시스템 드라이버 및 하위 수준 파일 시스템 기능 간의 인터페이스에서 발생합니다. 이를 IOSS 또는 I/O 하위 시스템이라고 설명하겠습니다.
이 오류는 IOSS/FS 버그일 수도 있습니다.이런 일은 몇 년 전에 일어났습니다., xattr이 체크섬과 충돌하는 경우). 따라서 가능하다면 최신 커널/파일 시스템 드라이버를 사용해 볼 수도 있습니다.
답변2
바라보다하드 드라이브 - SATA 오류가 위험합니까? -우분투에 물어보세요. 이전에 RAID 어레이에서 FPDMA QUEUED오류를 발견했지만 /var/log/syslog삭제했는데 이것이 이러한 오류 메시지의 유일한 소스였습니다. 따라서 이는 분명히 ext4 파일 시스템 손상의 일반적인 원인이지만 더 이상 이러한 오류에 대한 설명이 아닙니다.