내 자신의 학습을 위해 파일 구멍이 있는 파일을 만들려고 노력해 왔습니다. stdin에서 읽고 파일에 쓰는 유틸리티를 만들었지만 파일에 쓰기 전에 파일 끝을 넘어서 lseek 여러 바이트를 사용합니다.
fh -b 20000 testfile
hello
there
프로세스를 시작한 후 입력("hello")을 입력하여 테스트 파일에 쓸 수 있지만 그 전에는 파일 끝에서 20000바이트를 찾습니다. 그런 다음 쓰기 전에 "거기"에 쓰기 전에 파일 끝에서 또 다른 20000바이트를 다시 찾습니다.
나에게 명확하지 않은 것은 새로 생성된 파일에 할당된 블록 수입니다. 만약 내가한다면
ls -ls testfile
할당된 블록은 8개이고 파일 크기는 40013(예상)입니다.
13바이트(파일 홀 없음)의 새 파일이 4개 블록에 할당됩니다 ls -ls. 이것이 실제로는 1블록(2048바이트의 블록)을 의미한다는 것을 알았지만, 보고된 블록은 512바이트로 균등하게 나눌 수 있습니다. 따라서 이것이 사실이라고 가정하면 계산에서는 파일 취약점이 있는 파일을 계산하지 않습니다. 물리적 파일 크기가 (논리적 크기 40013이 아닌) 13바이트에 불과한데 8개의 블록이 할당되는 이유는 무엇입니까? 여전히 4바이트여야 하지 않습니까?
블록 크기를 올바르게 읽고 있는지 잘 모르겠습니다. 둘째, 파일 구멍이 없는 비슷한 크기의 파일은 4개만 있을 것이라는 점을 고려하면 블록 크기가 왜 8인지 이해가 되지 않습니다.
저는 ext4 파일 시스템에서 Ubuntu 11.10을 실행하고 있습니다.
답변1
Ext4는 블록 크기로 1kB, 2kB 또는 4kB를 사용할 수 있습니다. 제가 아는 한 Ubuntu의 기본값은 4kB입니다. 여기서 블록은 특정 파일 시스템에 대해 일정한 파일 블록 크기입니다. 설명하는 파일에는 0이 아닌 두 개의 블록이 있습니다. 하나는 포함 hello(앞에 3616, 뒤에 474의 0으로 둘러싸여 있음)하고 다른 하나는 here(앞에 3148 바이트 만 포함하고 474가 뒤 따르는 0 묶음)을 포함합니다. 파일 끝). 총 2개의 4kB 블록이 있습니다.
출력 에서 ls블록은 명령으로 선택한 단위이며 ls기본값은 1kB입니다. 파일 데이터를 포함하기 위해 2개의 4kB 블록이 할당되어 있으므로 파일에 할당된 크기는 8kB입니다.
귀하의 혼란은 두 가지로 인해 발생할 수 있습니다. 첫째, 블록당 2048바이트가 가능하지만 이는 Ubuntu(또는 대부분의 최신 배포판)에서 기본값이 아니며 시스템의 값도 아닙니다. tune2fs -l /dev/sdz42(파일 시스템 장치의 실제 경로를 사용하여) 실행하여 블록 크기를 확인할 수 있습니다 .
둘째, 희소 파일은 완전히 0으로 구성된 블록을 저장하지 않습니다. 블록(최소한 ext4를 포함한 대부분의 파일 시스템에서 블록 크기 경계에 맞춰 정렬되어야 함)에 0과 기타 내용이 포함되어 있으면 전체 블록이 디스크에 저장됩니다. 따라서 해당 40012바이트 파일(그런데 어떻게 40013바이트를 얻었습니까?)에는 모두 0인 4개의 비저장 블록이 있고, 그 다음에는 hello0으로 둘러싸인 저장소 블록이 있고, 그 다음에는 모두 0인 또 다른 4개의 비저장 블록이 있습니다. 블록. 블록, 그리고 영합을 포함하는 마지막 부분 블록입니다 there.
표준 쉘 명령을 사용하여 유틸리티를 작성할 수 있습니다.
n=20000
while IFS= read -r line; do
dd bs=1 seek=$n </dev/null
echo "$line"
done >testfile