파일을 읽기 위해 hexdump를 사용하면 find의 희소 값(%S)이 변경되는 이유는 무엇입니까?

파일을 읽기 위해 hexdump를 사용하면 find의 희소 값(%S)이 변경되는 이유는 무엇입니까?

저는 Lustre 파일 시스템을 사용합니다. %S파일에 대한 find()의 희소 값을 본 다음 를 사용하여 해당 파일을 인쇄한 hexdump다음 find의 희소 값을 다시 보면 가끔 find( %S)의 희소 값이 변경되는 것을 발견했습니다 . 왜 바뀌었나요?


%S희소 값 찾기( ) 명령을 사용하여 파일 보기 myvideo.mp4:

find myvideo.mp4 -printf "%S"

myvideo.mp4파일을 읽으려면 다음 명령을 사용하십시오 hexdump.

hexdump myvideo.mp4 

여러 파일에서 이 동작을 발견했습니다. 찾기( )의 희소 값 변경 예 %S:

  • 0.000135559도착하다0.631297
  • 0.00466808도착하다0.228736

read 를 사용할 때 파일이 부분적으로 로컬로 캐시되기 때문입니까 hexdump? 나는 이 변경 사항이 특정적이지 않다는 것을 알았습니다. 예를 들어 (그리고 아마도 파일을 읽는 다른 프로그램에도) hexdump똑같은 일이 일어날 것입니다:nano

dernoncourt@server:/videos$ find myvideo.mp4 -printf "%S"
0.00302331
dernoncourt@server:/videos$ nano myvideo.mp4 
dernoncourt@server:/videos$ find myvideo.mp4 -printf "%S"
0.486752

답변1

(이 답변의 모든 정보는 스티븐 차제라스~의논평. 감사해요! )

~에서찾기 매뉴얼 페이지(형식은 내 것입니다):

%S:파일의 희소성입니다. 그 계산식은 ( BLOCKSIZE*st_blocks / st_size)이다. 특정 길이의 일반 파일에 대해 얻을 수 있는 정확한 값은 시스템에 따라 다릅니다.그러나 희소 파일은 일반적으로 1.0보다 작은 값을 갖는 반면, 간접 블록을 사용하는 파일은 1.0보다 큰 값을 가질 수 있습니다. 사용되는 값은 BLOCKSIZE시스템에 따라 다르지만 일반적으로 512바이트입니다. 파일 크기가 0이면 인쇄된 값은 정의되지 않습니다. 지원되지 않는 시스템에서는 st_blocks파일의 희소성이 1.0으로 간주됩니다.

알아채다:

  • BLOCKSIZE*st_blocks디스크 사용량에 따라,
  • st_size겉보기 크기에 해당합니다.

그러므로 %S== BLOCKSIZE*st_blocks / st_size.diskusage/apparentsize

게다가 이답변파일의 겉보기 크기가 때때로 실제 디스크 사용량보다 훨씬 큰 이유를 해결합니다.Lustre와 같은 계층형 스토리지 시스템전혀 희박하지 않을 수도 있지만. 대용량 파일을 프런트엔드 스토리지에 완전히 복원하는 것은 이례적이라는 점도 언급했다.

hexdump등의 프로그램을 사용하여 파일을 읽을 때 프런트엔드 스토리지에 부분적으로 복원되는 경우가 있기 때문에 nanost_blocks값이 증가하여 감소하므로 %S (=BLOCKSIZE*st_blocks / st_size)()에서 보고하는 파일의 희소성이 감소한다는 의미입니다.find%S


Lustre 파일 시스템의 파일이 희박한지 여부를 아는 것은 쓸모가 없으므로 find myvideo.mp4 -printf "%S"다음 명령을 사용할 수 있습니다.해결책통과프로스트슈츠파일이 희박한지 확인하십시오.

file = "myvideo.mp4"
if [ "$((`stat -c '%b*%B-%s' -- "$file"`))" -lt 0 ]
then
    echo "$file" is sparse
else
    echo "$file" is not sparse
fi

이 솔루션에는 다음과 같은 몇 가지 제한 사항이 있습니다.댓글 영역.

그리고 광택도 주의해주세요확실히현재 SEEK_HOLE/SEEK_DATA인터페이스가 직접 지원되므로 사용할 수 없습니다.이 솔루션을 사용하세요Lustre의 파일이 희박한지 이해합니다.

관련 정보