☰

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

tag-icon • tag-icon linux disk ext4
수명이 짧은 파일이 디스크에 플러시됩니까?

내 프로그램은 작은 임시 파일을 많이 생성합니다. 일반적으로 생성 후 1초 이내에 삭제됩니다. 이러한 파일은 실제 하드 디스크가 지원하는 ext4 파일 시스템에 있습니다. 나는 Linux가 주기적으로 pdflush( ) 더티 페이지를 디스크에 플러시한다는 것을 알고 있습니다. 내 파일은 임시 파일이므로 사용되지 않을 가능성이 높습니다 pdflush. 내 질문은 내 프로그램이 많은 디스크 쓰기를 유발하는가입니다. 내 관심사는 하드 드라이브의 수명입니다.

파일이 작기 때문에 파일 크기의 합 dirty_bytes이 dirty_background_bytes.

Ext4는 메타데이터 로그인 기본 로그를 엽니다. 또한 메타데이터나 데이터가 디스크에 기록되는지 알고 싶습니다.

답변1

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

디스크 쓰기를 완전히 피하고 싶다면 다음을 확인하십시오.임시 파일 시스템,

답변2

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

내 경우에는 모든 파일 이름이 나열되었지만 파일 내용은 나열되지 않았습니다. 그래서 그냥 내용을 썼습니다.

답변3

일반적으로 말하면, 아니요, 기록되지 않습니다. 이는 두 가지 조건 중 하나가 충족되면 캐시가 더티 페이지를 플러시하기 때문입니다.

  1. 데이터는 /proc/sys/vm/dirty_writeback_centisecs기본적으로 5초 후에 만료됩니다.

  2. 캐시에 데이터를 보관하기에는 메모리가 너무 적어 dirty_ratio캐시의 더티 페이지 수(기본값은 20%)를 초과합니다.

따라서 여유 메모리가 많고 쓰기 트래픽이 매우 적은 시스템(5초 이내에 삭제된 작은 파일 제외)에서는 데이터가 플러시되지 않습니다.

답변4

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

XFS는 관심 있는 동작(소위 "지연 할당")을 강조하는 파일 시스템입니다. 이를 사용하면 방금 삭제한 파일에 속한 블록이 중간 디스크 액세스 없이 메모리에서 재사용된다는 점을 어느 정도 확신할 수 있습니다(다른 곳의 흥미로운 구성 옵션 없이). 많은 RAID 컨트롤러의 경우).

이러한 동작으로 인해 갑작스러운 정전 후 XFS 파일 시스템에서 완전히 0으로 설정되었지만 합법적인 것처럼 보이는 파일(크기 및 기타 메타데이터는 그대로 유지)을 찾는 것은 드문 일이 아닙니다. 이는 빠른 "반임시" 파일 작업을 지원하는 데 드는 비용입니다.

일부 이론

일반적으로 파일 시스템에 액세스하는 시스템 호출은 곧 파일 시스템 드라이버에 의해 정의된 메서드(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()를 통해). 그렇지 않으면 블록은 "더티"로 표시되고 합리적인 기회에 플러시될 때까지 메모리 캐시에 남아 있습니다.

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

관련 정보