du aynı dosya için iki farklı sonuç verir

Linux kümesine erişimi olan bilgisayar mühendisliği mezunuyum. Küme, birkaç düzine bilgi işlem düğümünün bağlı olduğu çok büyük (25 TB) bir dosya sunucusundan oluşur. Her işlem düğümü, 8 - 24 Intel Xeon çekirdeğinden oluşur. Her hesaplama düğümü ayrıca yaklaşık 365 TB yerel disk içerir.

Dosya sunucusuna araştırma grubundaki bir düzine kullanıcı tarafından düzenli olarak erişildiği için, dosya sunucusu temel olarak uzun vadeli dosya depolaması için kullanılır (bu işlem gece hesaplanır, işlem noktalarının yerel diskleri hiçbir zaman yedeklenmez). Bu nedenle, sistem yöneticisi, diğer kullanıcılar için dosya sunucusunu yavaşlatmamaları için dosya diskinden daha hızlı G / Ç'ye sahip yerel diskler üzerinde simülasyonlar çalıştırmamızı istedi.

Bu yüzden, yerel diskler üzerinde simülasyonlar çalıştırıyorum ve sonra, bittikten sonra, yörünge dosyalarını kopyalarım - moleküler dinamik (MD) simülasyonları çalıştırıyorum - depolama için dosya sunucusuna. traj.trrBir düğümün yerel diskindeki bir dizinde adı verilen bir yörünge dosyasına sahip olduğumu varsayalım /home/myusername/mysimulation1/traj.trr. Uzun süreli depolama için, her zaman traj.trrdosya sunucusundaki bir dizine kopyalarım ~/mysimulation1/traj.trr, burada dosya sunucusundaki dizimi ~temsil eder /export/home/myusername. Kopyaladıktan sonra, alışılmış olarak aynı dosya boyutuna sahip du -holduğunu doğrulamak için kullanıyorum . Bu sayede, en azından dosya sunucusuna transferin başarılı olduğundan emin olabilirim. Örneğin:/home/myusername/mysimulation1/traj.trr~/mysimulation1/traj.trr

cd /home/myusername/mysimulation1/
cp -v traj.trr ~/mysimulation1/
du /home/myusername/mysimulation1/traj.trr -h
du ~/mysimulation1/traj.trr -h

İkisi du -haynı okunabilir dosya boyutunu vermek için çağrıda bulunursa, aktarımın / kopyalamanın başarılı olduğundan emin olabilirim. (Tipik traj.trrdosyalarım, çalıştırdığım tam simülasyona bağlı olarak yaklaşık 15 - 20 GB arasında değişmektedir.) İki dosyada du(yani, anahtarsız ) çalışırsam , bayt cinsinden boyutları genellikle çok, çok benzerdir - - genellikle sadece birkaç bayt içinde. Bu genel metodu son bir buçuk yıldır problemsiz bir şekilde kullanıyorum.-htraj.trr

Ancak, son zamanlarda aşağıdaki sorunla karşılaştım: bazendu -hikitraj.trrdosyanın birkaç GB boyutunda farklıolduğunu bildirmektedir. İşte bir örnek:

cd /home/myusername/mysimulation1/            # this is the local disk
cp -v traj.trr ~/mysimulation1/
du traj.trr -h
cd ~/mysimulation1/                           # this is the fileserver
du traj.trr -h

İki çağrıdan gelen çıktı du -hsırasıyla şöyledir:

20G     traj.trr
28G     traj.trr

Eski (yani traj.trryerel diskteki /home/myusername/mysimulation1/) dosya boyutunun doğru olduğuna inanıyorum , çünkü simülasyon yörüngelerimin her birinin yaklaşık 15 - 20 GB olması bekleniyor. Ancak, dosya sunucusundaki dosya gerçekte nasıl daha büyük olabilir ? Nasıl olsa daha küçük olabileceğini görebiliyordum.cp transfer başarısız . Ama aslında nasıl daha büyük olabileceğini anlamıyorum .

Yukarıdaki gibi aynı komutları yerine getirdiğimde benzer bir çıktı alıyorum, ancak -hanahtarı vermeden du:

20717480        traj.trr
28666688        traj.trr

Farklılığın herhangi bir sebebini düşünebiliyor musun?

Olası bir şans eseri dubir şekilde arıza yaparsa, bununla iyi olabilirim. Ama ben sadece kopyasını emin olmak için ihtiyacım vartraj.trr , dosya sunucusundaki yerel diskteki kaynak sürümüyle aynı ve eksiksiz . Yeni simülasyonları çalıştırmak için yeterli yerel disk alanım olacak şekilde yerel dosyayı traj.trrsilmem gerekiyor, ancak dosya sunucusundaki sürümün bozulmasını göze alamam .

(GROMACS moleküler dinamiği paketinden) .trr dosya biçimi bir ikili biçimi değil metindir. Bu nedenle, dosyaları gibi bir program tarafından güvenilir bir şekilde karşılaştırılabilir olup olmadığından emin değilim diff.

Bütünlüğünü kontrol etmek için gerçekten md5sumveya benzeri bir şey kullanmalısınız sha1sum.

Gerçekten boyut kullanımını kullanmak istiyorsanız ls -lveya du -b.

Yardımcı duprogram normalde sadece dosyanın disk kullanımını, yani dosya sisteminin ne kadarını kullandığını gösterir. Bu değer tamamen destek dosya sistemine ve seyrek dosyalar gibi diğer faktörlere bağlıdır.

Örnek:

$ truncate -s 512M foo
$ cat foo >bar
$ ls -l foo bar
-rw-r--r-- 1 michas users 536870912 23. Dez 00:06 bar
-rw-r--r-- 1 michas users 536870912 23. Dez 00:03 foo
$ du foo bar
0       foo
524288  bar
$ du -b foo bar
536870912       foo
536870912       bar

Her ikisi de 512 MB sıfır içeren iki dosyamız var. İlki seyrek olarak depolanır ve herhangi bir disk alanı kullanmaz, ikincisi ise her bir baytı açıkça diskte depolar. - Aynı dosya, ancak tamamen farklı disk kullanımı.

Bu -bseçenek sizin için iyi olabilir:

   -b, --bytes
          equivalent to '--apparent-size --block-size=1'

   --apparent-size
          print apparent sizes, rather than disk usage; although the apparent
          size is  usually  smaller,  it  may  be  larger  due  to  holes  in
          ('sparse')  files, internal fragmentation, indirect blocks, and the
          like

Aynı verileri 2 farklı HDD’ye koyduğunuzda bu yaygın bir sorundur. duKomutu ve ek bir anahtarı çalıştırmak isteyeceksiniz , varsayalım - bunlara Linux düğümleri vermelidir.

Anahtar?

   --apparent-size
          print  apparent  sizes,  rather  than  disk  usage;  although the 
          apparent size is usually smaller, it may be larger due to holes in
          ('sparse') files, internal fragmentation, indirect blocks, and the 
          like

Örnek

$ du -sh --apparent-size /home/sam/scsconfig.log ~/scsconfig.log 
93K /home/sam/scsconfig.log
93K /root/scsconfig.log

Yukarıdaki dosya sistemleri yerel bir disktir ( /root), diğeri /home/samNAS'ımdan bir NFS paylaşımıdır.

$ df -h . /home/sam
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      222G  118G   92G  57% /
mulder:/export/raid1/home/sam
                      917G  566G  305G  65% /home/sam

Ee n'aber?

Bu birçok insanı şaşırtıyor ancak dosyaların bir diske kaydedildiğinde, bu blokların yalnızca bir kısmını kullanıyor olsalar bile alan bloklarını kullandıklarını unutmayın. duOlmadan koşarken--apparent-size , kullanılan disk alanı miktarını temel alarak, dosya (lar) tarafından tüketilen gerçek alanı değil boyutunu elde edersiniz.

bunun yerine bir sağlama toplamı kullanıyor musunuz?

2 dosya ağacını karşılaştırmakla ilgileniyorsanız, bu daha iyi bir seçenek olabilir. Bu komutu tüm dosyalar için bir sağlama toplamı hesaplamak için kullanabilirsiniz ve daha sonra bir sağlama toplamı toplamı hesaplamak için kullanabilirsiniz. Bu örnek kullanır, sha1sumancak md5sumbunun yerine kolayca kullanabilirsiniz .

$ cd /some/dir
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum

Örnek

$ cd ~/dir1
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
55e2672f8d6fccff6d83f0bffba1b67aeab87911  -

$ cd ~/dir2
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
55e2672f8d6fccff6d83f0bffba1b67aeab87911  -

Böylece 2 ağacın aynı olduğunu görebiliriz.

(Not: find komutu, dosyaları dosya sisteminde göründükleri gibi listeleyecektir. Bu nedenle, farklı dosya sistemindeki iki dizini karşılaştırıyorsanız (örneğin, Ext3 ve APFS gibi), ilk sha1sum'dan önce sıralamanız gerekir. Xianjun Dong)

Kısa cevap: dosya boyutunu test etmeyin, komutun dönüş durumunu test edin. İade durumu, kopyanın başarılı olup olmadığına dair yalnızca güvenilir bir göstergedir (iki dosyayı bayt byte ile doğrudan dolaylı olarak karşılaştırmanın kısa olması - kopya başarılı olursa gereksizdir).

Dosya boyutunu kontrol etmek, bir kopyanın başarılı olup olmadığını kontrol etmenin çok kullanışlı bir yolu değildir. Bazı durumlarda, örneğin web'den dosya indirirken yararlı bir akıl sağlığı kontrolü olabilir. Ama burada daha iyi bir yol var.

Tüm Unix komutları başarılı olup olmadıklarını belirten bir durum döndürür: başarı için 0, hatalar için 1 veya daha fazla. Yani çıkış durumunu kontrol edin cp. cpnormalde başarısız olursa, hatanın ne olduğunu belirten bir hata mesajı yazdırır. Bir komut dosyasında, son komutun çıkış durumu sihirli değişkendedir $?.

cp -v traj.trr ~/mysimulation1/
if [ $? -ne 0 ]; then
  echo 1>&2 "cp failed due to the error above"
  exit 2
 fi

$?Sıfır olup olmadığını kontrol etmek yerine, boole işleçlerini kullanabilirsiniz.

cp -v traj.trr ~/mysimulation1/ || exit 2

Bir komut dosyası çalıştırıyorsanız ve herhangi bir komut başarısız olursa komut dosyasının durmasını istiyorsanız, çalıştırın set -e. Herhangi bir komut başarısız olursa (yani sıfır olmayan bir durum döndürür), komut dosyası hemen komutla aynı durumla çıkar.

set -e
…
cp -v traj.trr ~/mysimulation1/

Kopyaladığınız dosyanın daha büyük olmasının nedeni seyrek bir dosya olmasıydı . Seyrek dosya yalnızca boş bayt içeren blokların depolanmadığı kaba bir sıkıştırma biçimidir. Bir dosyayı kopyaladığınızda cpkomut, boş baytları okur ve yazar, böylece orijinalin eksik blokları olduğu yerde, kopya boş baytlarla dolu bloklara sahiptir. Linux altında, cpkomut seyrek dosyaları algılamaya çalışır, ancak her zaman başarılı olmaz; cp --sparse=alwaysCPU zamanındaki çok küçük bir artış pahasına daha çok denemesini sağlar.

Daha genel olarak, dudiğer sıkıştırma biçimleri nedeniyle farklı sonuçlar verebilir. Sıkıştırılmış dosya sistemleri olsa nadirdir. Bir dosyanın boyutunu, dosyadaki bayt sayısındaki gibi, kullandığı disk blok sayısının aksine bilmek istiyorsanız, ls -lyerine kullanın du.