du एक ही फ़ाइल के लिए दो अलग-अलग परिणाम देता है

Question

मैं एक लिनक्स क्लस्टर के उपयोग के साथ कम्प्यूटेशनल रसायन विज्ञान का स्नातक छात्र हूं। क्लस्टर में एक बहुत बड़ी (25 टीबी) फाइलरवर होती है, जिसमें कई दर्जन कंप्यूट नोड्स जुड़े होते हैं। प्रत्येक गणना नोड में 8 से 24 इंटेल Xeon कोर होते हैं। प्रत्येक गणना नोड में लगभग 365 टीबी की एक स्थानीय डिस्क भी होती है।

चूंकि शोधकर्ता समूह में फाइलरवर को नियमित रूप से एक दर्जन या तो उपयोगकर्ताओं द्वारा एक्सेस किया जाता है, इसलिए फाइलसेवर का उपयोग मुख्य रूप से दीर्घकालिक फ़ाइल भंडारण के लिए किया जाता है (यह रात को बैकअप लिया जाता है, जबकि गणना नोड्स के स्थानीय डिस्क कभी भी बैकअप नहीं होते हैं)। इस प्रकार, सिस्टम प्रशासक ने हमें स्थानीय डिस्क पर सिमुलेशन चलाने का निर्देश दिया है - जिनके पास फाइलरवर की तुलना में तेज I / O है - ताकि अन्य उपयोगकर्ताओं के लिए फाइलर को धीमा न करें।

इसलिए, मैं स्थानीय डिस्क पर सिमुलेशन चलाता हूं और फिर, उनके समाप्त होने के बाद, मैं प्रक्षेपवक्र फ़ाइलों की प्रतिलिपि बनाता हूं - मैं आणविक गतिशीलता (एमडी) सिमुलेशन चला रहा हूं - भंडारण के लिए फाइलरवर में। मैं एक प्रक्षेपवक्र बुलाया फ़ाइल है मान लीजिए traj.trr, एक नोड के स्थानीय डिस्क पर एक निर्देशिका में /home/myusername/mysimulation1/traj.trr। दीर्घकालिक भंडारण के लिए, मैं हमेशा कॉपी traj.trrfileserver में एक निर्देशिका करने के लिए, ~/mysimulation1/traj.trrहै, जहां ~, fileserver में मेरी निर्देशिका का प्रतिनिधित्व करता है /export/home/myusername। इसे कॉपी करने के बाद, फिर मैं आदतन यह du -hसत्यापित करने के लिए उपयोग करता हूं कि /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

यदि दोनों du -hएक ही मानव-पठनीय फ़ाइल आकार देने के लिए कहते हैं , तो मैं यथोचित रूप से सुनिश्चित कर सकता हूं कि हस्तांतरण / प्रतिलिपि सफल रही। (मेरी विशिष्ट traj.trrफाइलें मेरे द्वारा चलाए गए सटीक सिमुलेशन के आधार पर आकार में लगभग 15 से 20 जीबी तक होती हैं।) यदि मैं दो फ़ाइलों पर du(यानी, -hस्विच के बिना ) चलाता हूं, तो traj.trrबाइट्स में उनके आकार आमतौर पर बहुत, बहुत समान हैं - - आमतौर पर सिर्फ कुछ बाइट्स के भीतर। मैं पिछले डेढ़ साल से इस समग्र पद्धति का उपयोग कर रहा हूं, कोई समस्या नहीं है।

हालांकि, हाल ही में मैं निम्नलिखित समस्या में चला गया हूं: कभी-कभीdu -hरिपोर्ट करती है कि दोtraj.trrफाइलें कई जीबी से आकार में भिन्न हैं। यहाँ एक उदाहरण है:

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

दो कॉल से आउटपुट du -hक्रमशः इस प्रकार है:

20G     traj.trr
28G     traj.trr

मेरा मानना ​​है कि पूर्व (यानी, traj.trrस्थानीय डिस्क में /home/myusername/mysimulation1/) सही फ़ाइल आकार है, क्योंकि मेरे सिमुलेशन प्रक्षेपवक्र प्रत्येक के बारे में 15 से 20 जीबी होने की उम्मीद है। लेकिन फिर फाइलसेवर पर फ़ाइल वास्तव में बड़ी कैसे हो सकती है ? मैं देख सकता था कि यह कैसे छोटा हो सकता है, अगर किसी तरह cpस्थानांतरण विफल हो गया। लेकिन मैं नहीं देखता कि यह वास्तव में बड़ा कैसे हो सकता है ।

जब मैं ऊपर के समान कमांड निष्पादित करता हूं, तो मुझे समान आउटपुट मिलता है, लेकिन बिना -hदिए गए स्विच को du:

20717480        traj.trr
28666688        traj.trr

क्या आप अंतर के किसी कारण के बारे में सोच सकते हैं?

यदि, कुछ संभावना नहीं है, duतो किसी तरह से खराबी है, मैं इसके साथ ठीक हो सकता हूं। लेकिन मुझे वास्तव में यह सुनिश्चित करने की आवश्यकता है कि traj.trrफ़ाइलरवर की प्रतिलिपि स्थानीय डिस्क पर इसके स्रोत संस्करण के लिए पूर्ण और समान है। मुझे स्थानीय फ़ाइल को हटाने की आवश्यकता है ताकि नए सिमुलेशन चलाने के लिए मेरे पास पर्याप्त स्थानीय डिस्क स्थान हो, लेकिन मैं traj.trrफ़ाइलरवर के संस्करण को दूषित होने का जोखिम नहीं उठा सकता।

.Trr फ़ाइल स्वरूप (Gromacs आणविक गतिशीलता पैकेज से) एक द्विआधारी प्रारूप, नहीं पाठ है। इस प्रकार, मुझे यकीन नहीं है कि यदि प्रोग्राम जैसे प्रोग्राम की तुलना में फ़ाइलों को मज़बूती से रखा जा सकता है diff।

Comments

फ़ाइलों पर md5sumया चलाने का प्रयास sha1sumकरें। क्या वे मेल खाते हैं?

— cjm

@ cjm मैं सिर्फ md5sumदो फाइलों पर चला । दो चेकसम मेल खाते हैं। तो मुझे लगता है कि इसका मतलब है कि दो फाइलें समान हैं?

— एंड्रयू

किन आकारों के द्वारा सूचित किया जाता है ls -l? कमांड duरिपोर्ट करती है कि आपकी फ़ाइल के लिए डिस्क पर कितना स्थान है, न कि आपकी फ़ाइल कितनी बड़ी है। डिस्क पर आकार आपके फाइल सिस्टम और इसकी आवंटन रणनीतियों से प्रभावित हो सकता है।

— केसी

@ एक्सी का ls -l -hकहना है कि दोनों फाइलें 20 जीबी की हैं। इसी तरह, ls -lकहते हैं कि दोनों फाइलें 21214683940 बाइट्स हैं। इसलिए मुझे लगता है कि फाइलें समान आकार की हैं, लेकिन डिस्क स्थान की एक ही राशि का उपयोग नहीं करें (तदनुसार du)।

— एंड्रयू

@ और ls द्वारा बताए गए आकार समान हैं और हैश भी वही हैं जो आप निष्कर्ष निकाल सकते हैं कि फाइलें समान हैं। ये उपकरण वे हैं जो आपको आपकी जरूरत का विश्वास दिलाते हैं और आपको दिखाते हैं कि डु आपकी जरूरतों को पूरा करने का उपकरण नहीं है।

— केसी

Answer 1

आपको वास्तव में कुछ का उपयोग करना चाहिए md5sumया sha1sumअखंडता की जांच करना चाहिए ।

यदि आप वास्तव में आकार का उपयोग करना चाहते हैं ls -lया du -b।

duउपयोगिता सामान्य रूप से केवल फ़ाइल के डिस्क उपयोग, यानी कैसे फाइल सिस्टम के ज्यादा यह द्वारा किया जाता है पता चलता है। यह मान पूरी तरह से बैकिंग फ़ाइल सिस्टम और स्पार्स फ़ाइलों जैसे अन्य कारकों पर निर्भर करता है।

उदाहरण:

$ 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

हमारे पास दो फाइलें हैं जिनमें 512MB शून्य हैं। पहले वाले को स्पार्स संग्रहीत किया जाता है और वह किसी डिस्क स्थान का उपयोग नहीं करता है, जबकि दूसरा प्रत्येक डिस्क पर स्पष्ट रूप से बाइट स्टोर करता है। - एक ही फाइल, लेकिन पूरी तरह से अलग डिस्क उपयोग।

-bविकल्प आपके लिए अच्छा हो सकता है:

   -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

Answer 2

जब आप एक ही डेटा को 2 अलग-अलग एचडीडी पर रखते हैं तो यह एक आम समस्या है। आप duकमांड को अतिरिक्त स्विच के साथ चलाना चाहते हैं , यह मानते हुए कि यह है - जिसे यह दिया जाना चाहिए ये लिनक्स नोड्स हैं।

स्विच?

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

उदाहरण

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

उपरोक्त फाइलसिस्टम एक स्थानीय डिस्क ( /root) है, जबकि दूसरा /home/samमेरे एनएएस से एनएफएस हिस्सा है।

$ 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

तो क्या चल रहा है?

यह बहुत से लोगों को भ्रमित करता है लेकिन याद रखें कि जब फ़ाइलों को डिस्क में संग्रहीत किया जाता है तो वे अंतरिक्ष के ब्लॉक का उपभोग करते हैं, भले ही वे केवल उन ब्लॉकों के एक हिस्से का उपयोग कर रहे हों। जब आप duबिना चलाए --apparent-sizeडिस्क के ब्लॉक स्पेस की मात्रा के आधार पर आकार प्राप्त कर रहे हैं, तो फ़ाइल (नों) द्वारा खपत वास्तविक स्थान नहीं।

इसके बजाय चेकसम का उपयोग करना?

यदि आप फ़ाइलों के 2 पेड़ों की तुलना करने के बारे में चिंतित हैं तो यह एक बेहतर विकल्प है। आप सभी फ़ाइलों के लिए एक चेकसम की गणना के लिए इस कमांड का उपयोग कर सकते हैं, और फिर चेकसम के अंतिम चेकसम की गणना कर सकते हैं। यह उदाहरण उपयोग करता है sha1sumलेकिन आप md5sumइसके बजाय आसानी से उपयोग कर सकते हैं ।

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

उदाहरण

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

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

तो हम देख सकते हैं कि 2 पेड़ समान हैं।

(नोट: ढूँढें कमांड फाइलों को सूचीबद्ध करेगी जैसा कि वे फ़ाइल सिस्टम में दिखाई देते हैं। इसलिए, यदि आप विभिन्न फ़ाइल सिस्टम (जैसे एक्सटी 3 बनाम एपीएफएस) से दो निर्देशिकाओं की तुलना कर रहे हैं, तो आपको अंतिम शा 1sum से पहले क्रमबद्ध करना होगा। (जोड़ा गया) जियानजुन डोंग)

Answer 3

संक्षिप्त उत्तर: फ़ाइल आकार का परीक्षण न करें, कमांड की वापसी स्थिति का परीक्षण करें। वापसी की स्थिति केवल एक विश्वसनीय संकेत है कि क्या कॉपी सफल हुई (बाइट द्वारा दो फाइलों की बाइट की तुलना करने में कमी, प्रत्यक्ष रूप से - जो प्रतिलिपि सफल हुई तो बेमानी है)।

फ़ाइल का आकार जाँचना जाँच का एक बहुत उपयोगी तरीका नहीं है कि क्या कोई प्रतिलिपि सफल हुई। कुछ मामलों में, यह एक उपयोगी पवित्रता जाँच हो सकती है, उदाहरण के लिए जब आप वेब से कोई फ़ाइल डाउनलोड करते हैं। लेकिन यहाँ एक बेहतर तरीका है।

सभी यूनिक्स कमांड्स यह बताने के लिए एक स्थिति लौटाते हैं कि क्या वे सफल हुए: 0 सफलता के लिए, 1 या अधिक त्रुटियों के लिए। तो बाहर निकलने की स्थिति की जाँच करें cp। cpसामान्य रूप से एक त्रुटि संदेश मुद्रित किया जाएगा यदि यह विफल हो गया है, यह दर्शाता है कि त्रुटि क्या है। एक स्क्रिप्ट में, अंतिम कमांड की निकास स्थिति मैजिक चर में है $?।

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

यह जांचने के बजाय कि क्या $?शून्य है, आप बूलियन ऑपरेटरों का उपयोग कर सकते हैं।

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

यदि आप एक स्क्रिप्ट चला रहे हैं और स्क्रिप्ट को रोकना चाहते हैं यदि कोई कमांड विफल हो, तो चलाएं set -e। यदि कोई कमांड विफल रहता है (यानी एक गैर-शून्य स्थिति देता है), तो स्क्रिप्ट कमांड के समान स्थिति के साथ तुरंत बाहर निकल जाएगी।

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

---

जिस कारण से आपकी कॉपी की गई फ़ाइल बड़ी थी, ऐसा होना चाहिए क्योंकि यह एक विरल फ़ाइल थी । विरल फ़ाइल संपीड़न का एक कच्चा रूप है जहां केवल नल बाइट वाले ब्लॉक संग्रहीत नहीं होते हैं। जब आप किसी फाइल को कॉपी करते हैं, तो cpकमांड नेल बाइट्स को पढ़ती है और लिखती है, इसलिए जहां मूल में गायब ब्लॉक्स थे, उस कॉपी में नेल बाइट्स से भरे हुए ब्लॉक हैं। लिनक्स के तहत, cpकमांड विरल फाइलों का पता लगाने की कोशिश करती है, लेकिन यह हमेशा सफल नहीं होती है; cp --sparse=alwaysयह CPU समय में बहुत मामूली वृद्धि की कीमत पर कठिन प्रयास करता है।

अधिक आम तौर पर, duसंपीड़न के अन्य रूपों के कारण विभिन्न परिणाम लौट सकते हैं। संपीड़ित फाइलसिस्टम दुर्लभ हैं, हालांकि। यदि आप फ़ाइल के आकार को फ़ाइल में बाइट्स की संख्या के रूप में जानना चाहते हैं, तो इसका उपयोग ls -lकरने वाले डिस्क ब्लॉक की संख्या के विपरीत, इसके बजाय का उपयोग करें du।

Comments

बहुत बहुत धन्यवाद! क्या आप जानते हैं कि कोई अलग (अलग) उपयोगिता है जो मुझे बता सकती है कि मेरी फाइल विरल है या नहीं?

— एंड्रयू

@ और देखें विरल फ़ाइलें ढूँढना? और लिनक्स पर विस्तृत स्पार्स फ़ाइल जानकारी

— गाइल्स 'तथाकथित बंद किया जा रहा है बुराई'