2012-10-20 2 views
7

저는 꽤 중요한 데이터를 다루는 소프트웨어를 작성 중이고 내구성을 얻기 위해 정확히 무엇이 필요한지 알아야합니다.Linux에서 내구성을 유지하려면 무엇이 필요합니까?

어디에서나 나는 모순 된 정보이므로 모든 통찰력에 감사드립니다.

디스크에 쓰는 방법에는 세 가지가 있습니다.

  • O_DIRECT | O_DSYNC로 설정하고 512 바이트 - 16MB 블록을 미리 작성한 다음 pwrite합니다.

  • O_DIRECT를 사용하여 512 바이트 블록을 미리 시작한 다음 pwrite하고 필요한만큼 정기적으로 fdatasync를 호출하십시오.

  • msync (..., MS_SYNC | MS_INVALIDATE)를 필요에 따라 정기적으로 호출하는 메모리 매핑 된 파일을 사용합니다.

그리고 이것은 모두 기본 플래그가있는 ext4에 있습니다.

이러한 모든 경우에 데이터가 손실 (쓰기 또는 동기화가 반환 된 후)되거나 전원 장애, 패닉, 충돌 또는 다른 이유로 손상 될 수 있습니까?

내 서버가 pwrite 중반부 또는 pwrite 시작 부분과 fdatasync 끝 부분 사이 또는 매핑 된 메모리와 msync 사이에서 사망하는 경우 이전 데이터와 새 데이터가 혼합되거나 그것은 하나가 될 것인가? 필자의 개별 pwrite 호출이 원자 단위로 정렬되도록하고 싶습니다. 이 경우인가요? 여러 파일에 걸쳐있는 경우입니까? 그래서 O_DIRECT |로 쓰면 O_DSYNC를 A로 설정 한 다음 O_DIRECT로 설정 | O_DSYNC에서 B로 넘어갔습니다. 아무리 무슨 일이 일어나더라도 데이터가 B에 있으면 A도됩니다.

fsync는 데이터가 쓰여진 것을 보증합니까? This은 말하지 않았지만 그 이후로 상황이 변경되었는지는 알 수 없습니다.

ext4의 저널링은 this SO answer이 말하는 손상된 블록의 문제를 완전히 해결합니까?

저는 현재 posix_fallocate를 호출하고 ftruncate를 호출하여 파일을 늘리고 있습니다. 이 두 가지 모두 필요하며 충분합니까? ftruncate가 실제로 할당 된 블록을 초기화하여 these issues을 피할 것이라고 생각했습니다.

혼란을 믹스에 추가하려면 EC2에서이 코드를 실행하고 있습니다. 그 영향이 있는지는 잘 모르겠습니다. 그것이 얼마나 적극적으로 종료 될지 제어 할 수 없으므로 테스트하기가 어렵습니다.

+1

적어도 하드웨어 (또는 소프트웨어) 오류로 인해 데이터가 항상 손실 될 수 있습니다. 백업 (즉, 복제)하거나 적어도 일부 체크섬을 계산 (유효성을 검사하거나 무효화) 할 수 있어야합니다. 나는 syscall 트릭을하는 것이 충분하다는 것을 확신하지 못한다. 나는 중요한 데이터를 복제하고 체크섬하기 위해 열심히 노력할 것이고 아마도 트랜잭션 측면에서 생각할 것입니다. –

+2

@BasileStarynkevitch 위의 계층에서 데이터는 두 노드가 확인한 경우에만 기록 된 것으로 간주되며 일별 스냅 샷도 가져옵니다. 이 점을 충분히 고려하여 문제를 확인하기 전에 실제로 데이터를 실제로 HDD에 기록하도록하는 것입니다. – Max

답변

3

이러한 모든 경우에 데이터가 손실 (쓰기 또는 동기화가 반환 된 후)되거나 전원 장애, 패닉, 충돌 또는 다른 이유로 손상 될 수 있습니까?

물론입니다.

fsync는 데이터가 쓰여진 것을 보증합니까? 이것은 말하지 않지만, 그 이후로 상황이 바뀌 었는지는 알 수 없습니다.

아니요. 답변은 기기에 따라 다르며 파일 시스템에 따라 다를 수 있습니다. 불행히도, 그 파일 시스템은 "실제"저장 장치 위에 레이어와 레이어가 될 수 있습니다. (예 :md, lvm, fuse, loop, ib_srp 등).

얼마나 적극적으로 종료 할 지 제어 할 수 없으므로 테스트하기가 어렵습니다.

사실입니다. 그러나 NMI 또는 sysrq-trigger을 사용하여 상당히 갑작스러운 중단을 만들 수 있습니다.

관련 문제