☰

작은 파일을 512바이트 세그먼트로 분할하면 변경되지만 1k 세그먼트로 분할하면 변경되지 않습니다.

tag-icon • tag-icon find wildcards dd split checksum
작은 파일을 512바이트 세그먼트로 분할하면 변경되지만 1k 세그먼트로 분할하면 변경되지 않습니다.

FileCarve.001그래서 64MB 파일을 512바이트 세그먼트(각 블록 길이는 512바이트)로 분할하려고 합니다 . 더 작은 파일로 분할할 때 파일의 데이터가 동일한지 확인해야 하므로 cat모든 파일을 stdout하고 파이프로 연결합니다 sha256sum(파일이 많아서 이를 사용해야 합니다 find) xargs.

명령이 출력을 분할할 때 파일을 512바이트 세그먼트로 분할하면 데이터가 왜곡되는 것처럼 보입니다 split.

$ dd if=FileCarve.001 bs=512 | split -b512 - splits/img
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 4.10824 s, 16.3 MB/s
$ sha256sum FileCarve.001 
3e64100044099b10060f5ca3194d4d60414941c7cb26437330aba532852a60cd  FileCarve.001
$ find splits/ -type f -print0 | xargs -0 cat | sha256sum
25b37f28204895e5d0b1cb160c5fa599d15188baf7e529ccc92a10fdb3f0515a  -

하지만 파일을 1KB 세그먼트(1000바이트)로 분할하는 것이 잘 작동하는 것 같습니다.

$ dd if=FileCarve.001 bs=512 | split -b1k - splits/img
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 2.06029 s, 32.6 MB/s
$ sha256sum FileCarve.001 
3e64100044099b10060f5ca3194d4d60414941c7cb26437330aba532852a60cd  FileCarve.001
$ find splits/ -type f -print0 | xargs -0 cat | sha256sum
3e64100044099b10060f5ca3194d4d60414941c7cb26437330aba532852a60cd  -

왜 다른가요? 저장 장치에서 블록이 작동하는 방식에 대해 제가 이해하지 못하는 부분이 있나요?

의견에 대한 응답: 나는 split/실행할 때마다 디렉토리를 지웁니다.

답변1

find파일이 처리되는 순서는 정의되지 않습니다. 이는 기본 시스템 호출에 의해 제공된 것과 동일한 순서일 수 있으며 기본 파일 시스템 구조에 따라 달라질 수 있으며 본질적으로 무작위일 수 있습니다. 일부 구현에서는 어떤 방식으로든 목록을 처리할 수 있지만 정렬될 것으로 기대하지는 않습니다.

더 작은 파일을 사용해 보겠습니다. cat frag*Shell glob이 파일 이름을 정렬하므로 올바른 파일을 재현합니다.

$ split -b512 orig.bin frag
$ cat frag* > new.bin
$ sha256sum orig.bin new.bin 
8d12b42623eeefee872f123bd0dc85d535b00df4d42e865f993c40f7bfc92b1e  orig.bin
8d12b42623eeefee872f123bd0dc85d535b00df4d42e865f993c40f7bfc92b1e  new.bin

하지만 find그렇지 않으므로 다른 파일을 얻습니다.

$ find . -name 'frag*' -exec cat {} + > second.bin
$ sha256sum second.bin 
821325739ca65d1cb568ecf3a16bd2e01ac4eef1419b4d714834fab07d2f135c  second.bin

find인쇄 이름을 실행하면 다음과 같은 사실이 잘 드러납니다.

$ find . -name 'frag*' |head -5
./fragzbgv
./fragzbmg
./fragvt
./fragyd
./fragzayc

Linux와 ext4에 있습니다. 내 생각에는 파일 이름을 저장하기 위해 일종의 해시와 트리를 사용하므로 겉보기에 무작위 순서가 발생하는 것 같습니다. tmpfs에서 목록을 얻습니다.취소무작위는 아니지만 여전히 상황을 엉망으로 만드는 생성 순서.

파일 이름 목록을 명시적으로 정렬하면 도움이 됩니다.

$ find . -name 'frag*' -print0 | sort -z | xargs -0 cat > third.bin
$ sha256sum third.bin 
8d12b42623eeefee872f123bd0dc85d535b00df4d42e865f993c40f7bfc92b1e  third.bin

1,000개 블록에서 작동한다는 사실은 우연일 수도 있습니다...

그런데 왜 파일 이름을 직접 지정하는 dd bs=512대신 입력을 사용하고 있는지 잘 모르겠습니다 . 그것이 하는 일은 특정 블록 크기를 사용하여 읽고 쓰는 것이지만, 그 사이의 파이프는 블록 크기를 유지하지 않고 단지 바이트 스트림일 뿐이며 실제로 파일 시스템은catsplitddddsort해서는 안 된다파일을 읽는 데 사용하는 블록 크기(512(2^8) 바이트 또는 521(프라임) 바이트)에 관심이 있습니다.

관련 정보