Bu çoğaltılan SD kartların içerikleri için neden farklı sha1sum'ları var?


17

Farklı üreticilerin Sınıf 10 UHS-1 SDHC SD kartlarına sahibim. Hepsi aşağıdaki gibi bölümlere ayrılmıştır

 $ 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

Görüntüleri kopyalamak için bir bellek kartı teksir kullandım. Tüm kartlar aynı içeriğe sahiptir.

Herhangi iki SD kartın ikinci bölümünü takıp içeriği karşılaştırdığımda, bunlar tamamen aynı.

 $ 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^

Ancak, bölümlerin sha1sum'unu karşılaştırırsam, bazen farklı olurlar

 $ 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  -

Stranger, bu iki sürücüyü gibi ikili bir ayırma aracı kullanarak karşılaştırırsam radiff2, aşağıdakileri görüyorum

 $ 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

İçerikte diffherhangi bir fark görmese de 767368 değişiklik !

Ve akıl sağlığı için, aynı sha1sum'a sahip iki bölümü karşılaştırırsam, aşağıdakileri görüyorum

 $ radiff2 -c sdj2.img sdf2.img
0

0 değişiklik!

İşte farklı kartlardan gördüğüm farklı sha1sum'ların dökümü. Kartın üreticisi, sürücüyü okumak için dd kullandığımda ne sha1sum aldığım üzerinde büyük bir etkiye sahip gibi görünüyor.

resim açıklamasını buraya girin

Sha1sums'daki farklılıklara rağmen, tüm bu kartlar benim amacım için çalışıyor. Ancak, sha1sums karşılaştıramıyorum çünkü integrety denetimi zorlaştırıyor.

İki SD kart bölümünün farklı sha1sum'ları olabilir, ancak monte edildiğinde tam olarak aynı içeriğe sahip olması nasıl mümkün olabilir?


Cevap: Şimdi beklendiği gibi çalışıyor. İşleri düzeltmek için tutarsızlık, kullandığım SySTOR teksirinden kaynaklandı. Sahip olduğum kopyalama ayarı, kopyalanan bölüm bilgilerini ve dosyalarını kullanıyordu, ancak bire bir eşleşme olmasını sağlamak için bitlere gerek yoktu.


3
Bu tür kartlarla ne tür testler yapıyorsunuz? :)
hjk

Onları monte ettikten sonra karşılaştırıyorsanız , sorun var.
David Hoelzer

Yanıtlar:


18

Çoğaltılan içerikleri yazdıktan hemen sonra içeriklerini karşılaştırdınız mı? Evet ise, tamamen aynı şekilde çıkmalıdırlar . Örneğin,

# 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

Bu, yalnızca kartlar tam olarak aynı boyuta sahipse geçerlidir. Bazen, aynı üretici ve modeldeki farklı kart grupları bile biraz farklı boyutlarda ortaya çıkar. Cihazın blockdev --getsize64tam boyutunu elde etmek için kullanın .

Ayrıca, her iki kart da tam olarak aynı boyutlara sahipse, ancak her iki karta da kartların kapasitesinden daha küçük bir görüntü yazdıysanız, görüntünün bitiminden sonra gelen çöp farklılığın rapor edilmesine neden olabilir.

Aygıta herhangi bir dosya sistemi bağladıktan sonra farklılıkları görmeye başlayacaksınız. Dosya sistemi uygulaması, dosya sistemine boş bir günlük veya bayrak sistemini / zaman damgası gibi dosya sistemini temiz olarak işaretlemek için çeşitli şeyler yazar ve artık aynı içeriği artık görmezsiniz. Dosya sistemini salt okunur olarak bağlasanız bile bazı durumlarda bu durumun geçerli olabileceğine inanıyorum.


OP mu ihtiyaç kullanmak blockdev --getsize64? ddOkuduğu veri miktarını duyuruyor gibi görünüyor .
G-Man, 'Monica'yı Yeniden Başlat'

3
EIBTI. Boyutu sorgulamak gerçekten netleştirir. ddne kadar kopyaladığını bildirir . Bir görüntü dosyası, bir aygıtın boyutu ve başka bir aygıtın boyutu vb. Arasında boyut uyuşmazlığı olması durumunda, kaynağın boyutu, tasarımı veya her ikisi birden olabilir.
Celada

Haklısın. Onlar olmalı ve bunlar tam olarak aynı. Bunu daha sonra inceledikten sonra tutarsızlığın SySTOR teksirimdeki kopya ayarından kaynaklandığını gördüm. Ne zaman ddbilgisayarımdan SD kartlar (ı teksir için ana görüntü ile yaptığı gibi), tüm shasums maç. SySTOR'daki ayarları "yalnızca sistem ve dosya verileri" yerine "tüm ortam" olarak değiştirdim ve şimdi tüm çoğaltılmış kartların eşleşen shasums değerleri var
peskal

8

Celada'nın cevabı üzerine inşa etmek için: Bir yandan, diffiki bağlı dosya sistemi arasında (özyinelemeli) yapıyorsunuz . Öte yandan, dosya sistemlerini monte ettikten sonra, üzerinde dosya sistemleri olan cihazlar arasında ikili bir karşılaştırma yapıyorsunuz . Bu elma ve nar.

Bağlı dosya sistemi düzeyindeki işlem, yalnızca dosya sistemlerindeki dosyaların veri içeriğini görebilir. Cihazlar arasındaki ikili karşılaştırma verilere ve meta verilere bakar . 767368 farklılıklarından biraz şaşırdım, ancak birkaçını tahmin edebilirim:

  • Bir dosya sistemi bağladığınızda, çekirdek geçerli zamanı dosya sistemi süper bloğuna "bağlama zamanı" olarak yazar. Eğer iki cihazı monte (ve hiç varsa kesin aynı anda), farklı olacaktır süperblokların içinde "kat monte".
  • Özyinelemeli dosya sisteminden sonra aygıt düzeyinde ikili karşılaştırmayı yaparsanız, diffher aygıttaki her dosyanın erişim zamanı (inode'da) güncellenmiş olacaktır.

PS: ddÇok mu kullanmanız gerekiyor ? Yaparsan ne olur radiff2 -c /dev/sdg2 /dev/sdj2 ya da sha1sum /dev/sdg2?


Bu, sürücüyü salt okunur olarak monte ederken bile geçerli mi? Ben de montajdan önce shasum karşılaştırma yaptım ve hala farklı. Ayrıca montajdan sonra shasum değişikliğini hiç salt okunur olarak görmedim. - Ayrıca haklısın, dd ödülünün faydasız kullanımını kazanmalıyım: p
peskal

(1) Hayır, şüphelendiğiniz (yani deneyiminizle tutarlı olarak) bir dosya sistemini ro(salt okunur) olarak değiştirmek herhangi bir değişikliğe neden olmamalı (veya izin vermemelidir) . (Bir ya da iki yazılım örneğinin yapması gerekenden başka bir şey yaptığını görmeme rağmen.) (2) Yorumlarınızı okuduktan sonra (her cevapta bir tane, bu yazı sırasında), ne olduğunu hala tam olarak anlayamıyorum olmuş. Lütfen sorunuzu düzenleyecek misiniz ya da çoğaltma işleminden hemen sonra (montajdan önce) karşılaştırma hatası aldığınız koşulları (farklılıklar bulduğunu) açıklayan bir cevap gönderir misiniz?… (Devam ediyor)
G-Man 'Monica'yı Yeniden Kur'

(Devamı)… ve çözmek için ne yaptınız? (3) Sevdim ama buna “UUOD”, “UUODD” veya “UUDD” denmeli mi? “UUDD” için oy kullanıyorum, ancak büyük olasılıkla bunu Meta'ya almalıyız. :-) ⁠
G-Man '
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.