페이지 캐시 동작 보장 및 로그 파일

페이지 캐시 동작 보장 및 로그 파일

더티 페이지가 언제, 어떤 순서로 디스크에 기록되는지 보장할 수 있나요? 로그 구조 파일(추가 전용 파일)의 특정 경우 더티 페이지가 누적되어 순서 없이 디스크에 기록될 수 있습니까?

예를 들어, 다음과 같은 더티 페이지가 누적된 로그 파일을 상상해 보세요...

1: file_offset=16kb page_len=4kb <-- dirty
2: file_offset=20kb page_len=4kb <-- dirty
3: file_offset=24kb page_len=4kb <-- dirty

Linux에서는 위의 더티 페이지를 순서대로 작성합니까, 아니면 순서 없이 작성될 가능성이 있습니까? 잘못된 쓰기가 가능한 경우 로그 파일을 생성하는 데이터베이스와 애플리케이션은 이 상황을 어떻게 처리합니까? 예를 들어, 페이지 3이 먼저 기록되고 페이지 1과 2가 기록되기 전에 운영 체제가 충돌하면 8kb 파일 홀이 발생합니다.

답변1

Linux에서는 위의 더티 페이지를 순서대로 작성합니까, 아니면 순서 없이 작성될 가능성이 있습니까?

나는 모른다.

잘못된 쓰기가 가능한 경우 로그 파일을 생성하는 데이터베이스와 애플리케이션은 이 상황을 어떻게 처리합니까?

https://www.sqlite.org/atomiccommit.html#_dealing_with_garbage_writing_into_journal_files

SQLite는 기본 파일 시스템이 쓰기 요청을 재정렬할 수 있고 쓰기 요청이 마지막에 발생하더라도 페이지 수를 먼저 산화물로 태울 수 있다고 가정합니다. 따라서 두 번째 방어선으로 SQLite는 롤백 로그의 각 데이터 페이지에 32비트 체크섬을 사용합니다. 섹션 4.4에 설명된 대로 로그를 롤백할 때 롤백하는 동안 각 페이지에 대해 이 체크섬이 평가됩니다. 잘못된 체크섬이 발견되면 롤백이 중단됩니다. 데이터가 손상된 경우에도 체크섬이 정확할 가능성은 적지만 제한적이므로 체크섬은 페이지 데이터의 정확성을 보장하지 않습니다. 그러나 체크섬을 사용하면 최소한 이 오류가 발생할 가능성이 줄어듭니다.

관련 정보