이 중복 SD 카드의 콘텐츠에 대해 다른 sha1sum이있는 이유는 무엇입니까?


17

다른 제조업체의 Class 10 UHS-1 SDHC SD 카드가 많이 있습니다. 그들은 모두 다음과 같이 분할됩니다

 $ sudo fdisk -l /dev/sdj
Disk /dev/sdj: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0000de21

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdj1          2048  1050623  1048576  512M  c W95 FAT32 (LBA)
/dev/sdj2       1050624  2099199  1048576  512M 83 Linux
/dev/sdj3       2099200  3147775  1048576  512M 83 Linux
/dev/sdj4       3147776 31116287 27968512 13.3G 83 Linux

메모리 카드 복사기 를 사용 하여 이미지를 복사했습니다. 모든 카드의 내용이 동일합니다.

두 개의 SD 카드 중 두 번째 파티션을 마운트하고 내용을 비교하면 정확히 동일합니다.

 $ sudo mount -o ro /dev/sdg2 /mnt/system-a/
 $ sudo mount -o ro /dev/sdj2 /mnt/system-b/
 $ diff -r --no-derefence /mnt/system-a /mnt/system-b/
 $ # prints nothing^

그러나 파티션의 sha1sum을 비교하면 때로는 다릅니다.

 $ sudo dd if=/dev/sdg2 | sha1sum
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.3448 s, 43.5 MB/s
ee7a16a8d7262ccc6a2e6974e8026f78df445e72  -

 $ sudo dd if=/dev/sdj2 | sha1sum
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.6412 s, 42.5 MB/s
4bb6e3e5f3e47dc6cedc6cf8ed327ca2ca7cd7c4  -

낯선 사람과 같은 이진 확산 도구를 사용 하여이 두 드라이브를 비교 radiff2하면 다음과 같습니다.

 $ sudo dd if=/dev/sdg2 of=sdg2.img
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.2378 s, 43.9 MB/s

 $ sudo dd if=/dev/sdj2 of=sdj2.img
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.2315 s, 43.9 MB/s

 $ radiff2 -c sdg2.img sdj2.img
767368

내용에 diff차이가 없더라도 767368 변경 !

안전을 위해 sha1sum이 동일한 두 개의 파티션을 비교하면 다음을 볼 수 있습니다.

 $ radiff2 -c sdj2.img sdf2.img
0

0 개의 변화!

다음은 다른 카드에서 볼 수있는 다양한 sha1sum에 대한 분석입니다. dd를 사용하여 드라이브를 읽을 때 카드 제조업체가 sha1sum에 미치는 영향이 큰 것 같습니다.

여기에 이미지 설명을 입력하십시오

sha1sum의 차이에도 불구하고이 모든 카드는 제 목적을 위해 작동합니다. 그러나 sha1sum을 비교할 수 없기 때문에 부정확 한 검사가 어렵습니다.

두 개의 SD 카드 파티션이 다른 sha1sum을 가질 수 있지만 마운트 할 때 정확히 동일한 내용을 가질 수있는 방법은 무엇입니까?


답변 : 이제 예상대로 작동합니다. 일을 정리하기 위해, 내가 사용하고있는 SySTOR 복사기 때문에 불일치가 발생했습니다. 복사 설정은 복사 된 파티션 정보와 파일을 사용했지만 일대일 일치를 보장하기 위해 비트를 필요로하지 않았습니다.


3
그런 종류의 카드로 어떤 종류의 테스트를하고 있습니까? :)
hjk

마운트 한 후 비교하면 문제가 있습니다.
David Hoelzer

답변:


18

복제 된 내용을 쓴 직후 내용을 비교 했습니까 ? 그렇다면 정확히 똑같이 나와야합니다 . 예를 들어

# Duplicate
dd bs=16M if=/dev/sdg of=/dev/sdk

# Comparing should produce no output
cmp /dev/sdg /dev/sdk
# Compare, listing each byte difference; also no output
cmp -l /dev/sdg /dev/sdk

카드의 크기가 정확히 같은 경우에만 해당됩니다. 때로는 제조업체와 모델이 동일한 다른 배치의 카드도 약간 다른 크기로 나옵니다. blockdev --getsize64장치의 정확한 크기를 얻는 데 사용하십시오 .

또한 두 카드의 크기가 모두 동일하지만 카드 용량보다 작은 두 카드에 이미지를 쓰면 이미지 끝 이후에 나오는 쓰레기로 인해 차이가보고 될 수 있습니다.

장치에 파일 시스템을 마운트하면 차이점이 보이기 시작합니다. 파일 시스템 구현은 빈 저널 또는 파일 시스템을 깨끗한 것으로 표시하는 플래그 / 타임 스탬프와 같은 다양한 것들을 파일 시스템에 기록하므로 더 이상 동일한 내용을 볼 수 없습니다. 파일 시스템을 읽기 전용으로 마운트하더라도 일부 상황에서는 이것이 가능할 수 있다고 생각합니다.


영업합니까 필요 사용은 blockdev --getsize64? 것 같습니다 dd가 읽는 데이터의 양을 발표했다.
G-Man, 'Reinstate

3
EIBTI. 크기를 쿼리하면 실제로 명확 해집니다. dd얼마나 복사 했는지보고합니다 . 이미지 파일, 한 장치의 크기 및 다른 장치의 크기 등의 크기가 일치하지 않는 경우, 소스의 크기, 원하는 크기 또는 둘 다일 수 있습니다.
Celada

네가 옳아. 그들은해야하며, 그들이 있습니다 정확히 같은. 더 자세히 살펴본 후 SySTOR 복사기의 복사 설정으로 인해 불일치가 발생하는 것을 발견했습니다. I 때 dd내 컴퓨터에서 SD 카드 (I는 복사기의 마스터 이미지와 함께했던 것처럼), 모든 shasums이 일치합니다. 나는 "전체 미디어"지금은 모든 카드 복제가 일치 한 shasums에 "시스템 및 파일 데이터 만 '에서 SySTOR의 설정을 변경
peskal

8

Celada의 답변을 바탕으로 : 한편으로는 diff마운트 된 두 파일 시스템 사이 에서 (재귀 적) 작업을 수행하고 있습니다. 다른 한편으로, 파일 시스템을 마운트 한 후 파일 시스템이있는 장치 간에 이진 비교를 수행합니다 . 사과와 석류입니다.

마운트 된 파일 시스템 레벨에서의 조작은 파일 시스템에있는 파일의 데이터 내용 만 볼 수 있습니다. 장치 간의 이진 비교는 데이터 와 메타 데이터를 확인 합니다. 767368의 차이점에 약간 놀랐지 만 몇 가지를 추측 할 수 있습니다.

  • 파일 시스템을 마운트하면 커널은 현재 시간을 파일 시스템 수퍼 블록에 "마운트 시간"으로 씁니다. 두 장치를 동시에 ( 정확히 동시에 아님) 마운트 한 경우 수퍼 블록의 "마운트 시간"이 달라집니다.
  • 재귀 파일 시스템 후에 장치 수준 이진 비교를 수행하면 diff각 장치의 모든 파일에 액세스 시간 (노드 inode)이 업데이트됩니다.

추신 : 당신은 dd너무 많이 사용해야 합니까? 당신은 radiff2 -c /dev/sdg2 /dev/sdj2 또는 어떻게됩니까 sha1sum /dev/sdg2?


드라이브를 읽기 전용으로 마운트 할 때에도 적용됩니까? 나는 마운트하기 전에 shasum 비교를 수행했지만 여전히 다릅니다. 또한 마운트 후 읽기 전용으로 shasum 변경을 본 적이 없습니다. P : - 또한 당신이 맞아요, 나는 DD 수상의 쓸모없는 사용 승리한다
peskal

(1) 아니, 당신은, 같은 파일 시스템을 마운트 (당신의 경험 즉, 일치) 용의자 ro(읽기 전용) 해야 하지 원인 (또는 허용) 어떤 수정. (필요한 것 이외의 작업을 수행하는 소프트웨어의 경우가 하나 또는 두 개인 것을 보았지만) (2) 귀하의 의견을 읽은 후에 (이 글을 쓰는 시점에서 각 답변에 대해 하나씩), 나는 여전히 무엇을 이해하지 못합니다 일어난. 당신이 중 하나를 편집 질문을하시기 바랍니다 즉시 (설치 전) 복제 후 비교 장애를 가지고있는 상황 (즉, 그것은 차이를 발견)를 설명하는 답변을 게시 할 예정입니다 ... (계속)
G-남자 '는 분석 재개 모니카'말한다

(계속)… 그리고 그것을 해결하기 위해 무엇을 했습니까? (3) 마음에 들지만 "UUOD", "UUODD"또는 "UUDD"라고해야합니까? 나는“UUDD”에 투표하지만, 우리는 아마도 이것을 Meta에 맡겨야 할 것입니다. :-) ⁠
G-남자 '는 분석 재개 모니카'말한다
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.