수명이 짧은 파일이 디스크로 플러시됩니까?

내 프로그램은 많은 작은 단기 파일을 만듭니다. 일반적으로 생성 후 1 초 이내에 삭제됩니다. 파일은 실제 하드 디스크가 지원하는 ext4 파일 시스템에 있습니다. Linux가 정기적으로 pdflush더티 페이지를 디스크로 플러시한다는 것을 알고 있습니다. 내 파일은 수명이 짧기 때문에에 의해 캐시되지 않을 가능성이 높습니다 pdflush. 내 질문은 내 프로그램이 많은 디스크 쓰기를 유발합니까? 내 관심사는 내 하드 디스크의 수명입니다.

파일이 작기 때문에 크기의 합이 dirty_bytesand 보다 작다고 가정하겠습니다 dirty_background_bytes.

Ext4에는 기본 저널이 켜져 있습니다 (예 : 메타 데이터 저널). 또한 메타 데이터 또는 데이터가 디스크에 기록되는지 여부를 알고 싶습니다.

ext4를 사용한 간단한 실험 :

100MB 이미지 만들기 ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

루프 장치로 만드십시오 ...

# losetup -f --show image
/dev/loop0

파일 시스템을 만들고 마운트하십시오 ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

짧은 수명의 파일로 실행하십시오. (원하는 방법으로 변경하십시오.)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

마운트 해제, 동기화, 루프 해제

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

이미지 내용을 확인하십시오.

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

필자의 경우 모든 파일 이름을 나열했지만 파일 내용은 나열하지 않았습니다. 내용 만 쓰지 않았습니다.

솔리드 스테이트 드라이브에 대해 이야기하지 않는 한 많은 디스크 쓰기가 드라이브 수명의 주요 요소가되지는 않습니다.

디스크 쓰기를 전혀 피하려면 tmpfs를 살펴보십시오 .

일반적으로, 그들은 작성되지 않습니다. 두 가지 조건 중 하나가 충족되면 캐시가 더티 페이지를 플러시하기 때문입니다.

1. 이후에 데이터가 만료 /proc/sys/vm/dirty_writeback_centisecs되며 기본값은 5 초입니다.

2. 캐시에서 dirty_ratio더티 페이지 보다 더 많은 데이터를 보유하기 위해 캐시에 메모리가 너무 적습니다 (기본값 : 20 %).

따라서 사용 가능한 메모리가 충분하고 5 초 이내에 삭제되는 작은 파일을 제외하고 쓰기 트래픽이 적은 시스템에서는 데이터가 플러시되지 않습니다.

수명이 짧은 파일이 디스크에 기록되는지 여부는 커널 파일 캐시의 기본 동작뿐만 아니라 파일 시스템 드라이버 구현 및 해당 파일 시스템의 마운트 옵션에 대한 세부 사항에 따라 달라집니다. 모든 것이 항상 즉시 디스크에 기록되도록 시스템을 구성 할 수 있습니다 (본질적으로 DOS와 같은 동작).

관심있는 동작 ( "지연 할당"이라고 함)을 두드러지게 나타내는 파일 시스템 중 하나는 XFS입니다. 이를 통해 삭제 된 파일에 속하는 블록이 중간 디스크 액세스없이 메모리에서 재사용 될 것이라는 확신을 가질 수 있습니다. XFS는 여전히 메타 데이터 저널을 업데이트하려고 할 수 있습니다 (디스크에 자주 기록됨). 그러나 XFS 저널이 메타 데이터 전용 인 경우 배터리 백업 RAM과 같은 다른 빠른 장치에 설정할 수있을 정도로 작습니다. 많은 RAID 컨트롤러에서).

이 동작으로 인해 전원이 완전히 차단 된 것은 드문 일이 아니지만 갑작스런 전원 중단 후 XFS 파일 시스템에서 합법적으로 보이는 파일 (크기 및 기타 메타 데이터는 그대로)을 찾는 것입니다. 이는 "일시적인"빠른 파일 작업을 지원하는 비용입니다.

어떤 이론

일반적으로 파일 시스템에 액세스하는 시스템 호출은 파일 시스템 드라이버 정의 메소드 (VFS 드라이버가 등록 될 때 "struct inode_operations"및 "struct file_operations"에 첨부)에서 다소 빨리 종료됩니다. 그 후 발생하는 일은 파일 시스템 구현의 재량에 달려 있습니다. 일반적으로 다음과 같은 접근 방식이 사용됩니다 (이 간단한 예는 Linux FAT 드라이버에서 가져온 것입니다).

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

파일 시스템이 "동기화"모드로 마운트되면 모든 변경 사항이 즉시 디스크로 이동합니다 (이 경우 fat_sync_inode ()를 통해). 그렇지 않으면, 블록은 "더티 (dirty)"로 표시되고 적당한 기회에 플러시 될 때까지 메모리 캐시에 남아 있습니다.

따라서 파일 시스템 마운트 옵션을 고려하고 해당 구현의 소스 코드를 검사하지 않고 임시 파일에 대한 시스템 동작을 예측하는 것은 불가능합니다 (물론 임베디드 공간에서 주로 발견되는 모든 종류의 이국적인 파일 시스템에 적용됨) .