ext4를 사용하면 파일 시스템 쓰기를 얼마나 오랫동안 캐시할 수 있나요?

ext4를 사용하면 파일 시스템 쓰기를 얼마나 오랫동안 캐시할 수 있나요?

얼마 전 ext4가 언마운트 해제 후 빈 파일을 남길 가능성이 있다는 논의가 있었습니다. 요약하자면 꽤 잘 요약되어 있습니다.이 기사에서. 기본적으로 지연된 할당으로 인해 ext 저널의 기본 커밋 간격(5초)보다 훨씬 오랜 시간 동안 쓰기 캐시에 쓰기가 유지될 수 있습니다.

특정 상황에서 블록 할당을 강제하여 기본적으로 최대 5초 후에 데이터를 디스크에 강제로 저장하는 패치에서 문제가 해결된 것으로 보입니다.

응용 프로그램이 파일 자체를 자르거나 추가하지 않고 파일의 기존 부분을 덮어쓰면 어떻게 되는지 궁금합니다. 그것도 5초 안에 강제로 디스크에 저장되나요?

파일에 추가하는 것과는 상황이 다른 것 같습니다. 추가할 때 파일 크기가 변경됩니다. 이는 메타데이터 변경입니다. 따라서 5초 이내에 저널 커밋이 필요하며 data=ordered이므로 보안 문제로 인해 그 전에 데이터를 기록해야 합니다. 그렇지 않으면 다른 사용자가 삭제한 파일의 일부가 추가된 파일의 소유자에게 표시될 수 있습니다. 파일).

파일 데이터만 덮어쓰는 경우, 이전 데이터가 새 데이터와 동일한 사용자에게 속하므로 메타데이터 저널 커밋 전에 데이터 쓰기가 이루어져야 할 이유가 없습니다. 그렇다면 쓰기는 커밋 전에 발생합니까, 아니면 저널 커밋 간격보다 오래 지연될 수 있습니까? 그렇다면 얼마나 오래?

업데이트: 올바른 일, 즉 fsync()를 사용할 때 이 모든 것이 관련이 없다는 것을 알고 있습니다. (이것이 ext4 및 데이터 손실에 대한 모든 논의의 주된 이유였습니다. 문제는 fsync()를 수행하지 않거나 적절한 순간에 수행되지 않는 애플리케이션에만 관련됩니다.) 저는 제 자신의 애플리케이션을 작성하는 것이 아닙니다. 내 애플리케이션이 모두 제대로 작동하는지 모르겠고, 그러한 "위험한" 쓰기에 대한 대략적인 기간을 알고 싶습니다. 묻는 이유는 내 그래픽 드라이버가 정기적으로 커널 패닉을 일으키기 때문인데, 데이터 쓰기의 마지막 5초 이상을 걱정해야 하는지 알고 싶습니다.

답변1

커밋 간격을 사용자 정의 값으로 설정할 수 있습니다. 이 값은 32비트 부호 없는 정수(초)만큼 클 수 있습니다. 그러니까 약 40억 초, 즉 136년이 됩니다. 이는 마운트 옵션을 통해 사용할 수 있으며 commit다음과 같이 적용할 수 있습니다. 이는 단지 예일 뿐이며 에서 설정할 수도 있습니다 fstab.

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

커밋 간격은 데이터가 추가되는지, 기존 데이터를 덮어쓰는지 등과 같은 모든 유형의 조건을 기반으로 하지 않습니다. 마운트 commit옵션(마운트 옵션을 전혀 제공하지 않는 경우 기본값은 5초)은 bash 쉘에서 다음과 같은 작업을 수행하는 것과 동일합니다.

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

이 전역 파일 시스템 동기화 간격을 혼동하지 마십시오 data=ordered("커밋 간격"은 명령줄 프로그램의 기능을 이해하는 우리에게 덜 의미 있는 용어일 수 있습니다 sync. 이 경우 "동기화 간격"이라고 명명하는 것이 더 나을 수 있습니다). data=ordered에 관한 것입니다주문하다데이터와 메타데이터가 업데이트됩니다( data=writeback"덜 안전함/빠름" 및 data=journal"더 안전함/느림"). commit=12345678파일 시스템 드라이버 자체가 모든 더티 데이터/저널/메타데이터/무엇이든 물리적 미디어에 대한 전체 동기화를 강제하는 빈도에 관한 것입니다. 그리고 원하는 경우 가장 확실히 136년으로 설정할 수 있으며, data=writeback,nobh호출하지 않거나 RAM에 더티 페이지가 여러 수명 동안 남아 있는 프로그램 fsync()sync()함께 마운트할 수 있습니다.

업데이트: 질문 편집 내용에 따라 그래픽 드라이버 커널 패닉을 해결할 수 있을 때까지 마운트 옵션 data=journal,commit=1이나 마운트 옵션을 사용하여 파일 시스템을 실행해야 한다고 말하고 싶습니다 . sync이렇게 하면 데이터 무결성이 최대로 유지되지만 성능이 저하됩니다. 특히 손실되어서는 안 되는 데이터를 디스크에 자주 쓰는 경우 이 작업을 수행하고 싶을 것이며, fsync()적절하게 사용하기 위해 사용 중인 앱을 "신뢰"하지 않는 경우 이는 두 배로 중요합니다.

원천: 여기그리고 개인적인 경험

답변2

귀하의 질문에 대한 대답이 무엇이든 그것은 중요하지 않습니다.

그만큼노출 보장ext4 파일 시스템의 동작은 "성공 sync/ fsync호출 후 데이터가 디스크에 저장됩니다"입니다. 따라서 이러한 질문을 하게 만드는 애플리케이션이 있는 경우 데이터 무결성을 보장해야 하는 중요한 지점에 동기화 호출을 삽입해야 합니다. 동일한 문제가 걱정되는 사용자라면 sync비정상적으로 종료될 수 있는 위험한 동작을 수행하기 전에 명령줄 유틸리티를 호출할 수 있습니다.

관련 정보