डिस्क फुल, डु अलग बताता है। आगे कैसे करें जांच?

Question

मेरे पास एक सर्वर में SCSI डिस्क (हार्डवेयर RAID 1), 32G, ext3 filesytem है। dfमुझे बताता है कि डिस्क 100% पूर्ण है। यदि मैं 1G हटाता हूं तो यह सही ढंग से दिखाया गया है।

हालांकि, अगर मैं एक रन करता हूं du -h -x /तो duमुझे बताता है कि केवल 12 जी का उपयोग किया जाता है (मैं -xकुछ सांबा माउंट के कारण उपयोग करता हूं )।

इसलिए मेरा प्रश्न ड्यू और डीएफ कमांड के बीच सूक्ष्म अंतर के बारे में नहीं है, लेकिन इस बारे में कि मैं कैसे पता लगा सकता हूं कि इस भारी अंतर का कारण क्या है?

मैंने एक fsck के लिए मशीन को रिबूट किया जो w / आउट त्रुटियां थी। क्या मुझे दौड़ना चाहिए badblocks? lsofमुझे कोई हटाए गए फ़ाइल नहीं दिखाता है, lost+foundखाली है और संदेश फ़ाइल में कोई स्पष्ट चेतावनी / गलत / विफल बयान नहीं है।

सेटअप के अधिक विवरण के लिए बेझिझक पूछें।

Comments

यह प्रश्न के बहुत करीब है: linux - du बनाम df अंतर ( serverfault.com/questions/57098/du-vs-df-difference )। समाधान माउंट बिंदु के तहत फाइलें थी जैसा कि OldTroll ने उत्तर दिया था।

— क्रिस टिंग

Answer 1

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

Comments

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

— म्हसेखावत

आपको अपने जवाब में ऐसा करने के लिए सीएलआई कमांड दिखाना चाहिए

— जोनाथन

भले ही आपको लगता है कि यह आपके लिए कोई मतलब नहीं है!

— क्रिस

नोट: यह उत्तर माउंट पॉइंट्स के नीचे स्थित फ़ाइलों के बारे में बात कर रहा है (यानी मूल फाइल सिस्टम पर छिपा हुआ है), माउंट पॉइंट्स के भीतर नहीं । (मेरे जैसे बेवकूफ मत बनो।)

— mwfearnley

Answer 2

स्थानीय सर्वर पर किसी समस्या को ट्रैक करने का प्रयास करते समय बस इस पृष्ठ पर ठोकर खाई।

मेरे मामले में हार्ड डिस्क का आकार लगभग 50% है df -hऔर du -shबेमेल है।

यह अपाचे (httpd) की वजह से बड़ी लॉग फाइलों को स्मृति में रखता था जिसे डिस्क से हटा दिया गया था।

इसे चलाने के लिए नीचे ट्रैक किया गया था lsof | grep "/var" | grep deletedजहां /varविभाजन था जिसे मुझे साफ करने की आवश्यकता थी।

आउटपुट ने लाइनें इस तरह दिखाईं:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

फिर अपाचे ( service httpd restart) को पुनः आरंभ करके स्थिति को हल किया गया , और 2 जीबी डिस्क स्थान को हटा दिया गया, हटाए गए फ़ाइलों पर ताले को साफ करने की अनुमति देकर।

Comments

मेरे लिए, ताले जहां मैंने प्रोग्राम बंद करने के बाद भी जारी नहीं किया (लाश?)। मुझे kill -9 'pid'ताले रिलीज़ करने थे। उदाहरण: आपके httpd के लिए यह होता kill -9 32617।

— मिका

लघु नोट: आपको सभी ओपन फाइल डिस्क्रिप्टर को दिखाना होगा या नहीं के lsofरूप में चलाना पड़ सकता हैsudo

— क्रिसवेग

मैं एच 2 के साथ इसमें भाग गया, जो हर दिन एक लॉगफाइल में कई गिग्स जोड़ रहा था। H2 (धीमा) को पुनरारंभ करने के बजाय, मैंने उपयोग किया sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd)।

— डेस्टी

मेरे मामले में, यहां तक ​​कि जब रिस्टार्ट httpdस्पेस जारी नहीं होता है। जब मैंने /etc/init.d/rsyslog restartइसे चलाया तो यह काम किया: डी

— थान गुयेन वान

आप greps को छोड़ सकते हैं और बस कर सकते हैं lsof -a +L1 /var, जहां का -aअर्थ है और सभी स्थितियां (डिफ़ॉल्ट है OR), का +L1अर्थ है केवल 1 से कम लिंक वाली फाइलों की सूची। (यानी, ओपन फाइल डिस्क्रिप्टर के साथ हटाई गई फाइलें), और /varउस माउंट बिंदु के तहत फाइलों में बाधाएं

— kbolino

Answer 3

मैं ओल्डट्रॉल के आपके "लापता" स्थान के सबसे संभावित कारण के जवाब से सहमत हूं।

लिनक्स पर आप आसानी से पूरे रूट विभाजन (या उस मामले के लिए कोई अन्य विभाजन) को हटा सकते हैं, उदाहरण के लिए, फाइलसिस्टम का कहना है कि आप किसी अन्य स्थान पर हैं / बस mnt करें

mount -o bind / /mnt

तो आप एक कर सकते हैं

du -h /mnt

और देखें कि आपके स्थान का उपयोग क्या है।

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

Comments

इस टिप के लिए बहुत बहुत धन्यवाद। बिना डाउनटाइम के मेरी बड़ी, "छिपी" फाइलों को खोजने और हटाने के लिए मुझे अनुमति दी!

— 13

धन्यवाद - इससे पता चला कि /var/lib/docker/aufs/diff/

— docker

Answer 4

देखिए क्या df -iकहता है यह हो सकता है कि आप इनोड से बाहर हैं, जो तब हो सकता है यदि उस फाइलसिस्टम में बड़ी संख्या में छोटी फाइलें हैं, जो सभी उपलब्ध स्थान का उपभोग किए बिना सभी उपलब्ध इनोड का उपयोग करती हैं।

Comments

एक फ़ाइल का आकार और एक फ़ाइल सिस्टम पर अंतरिक्ष की मात्रा दो अलग-अलग चीजें हैं। जितनी छोटी फाइलें होती हैं, उनके बीच विसंगति उतनी ही बड़ी होती है। यदि आप ऐसी स्क्रिप्ट लिखते हैं जो फाइलों के आकार को बढ़ाती है और उसकी तुलना du -sउसी उपशीर्षक से करती है, तो आप एक अच्छा विचार प्राप्त करने जा रहे हैं यदि यह मामला यहाँ है।

— Marcin

Answer 5

मेरे मामले में यह बड़ी हटाई गई फ़ाइलों के साथ करना था। इस पृष्ठ को खोजने से पहले इसे हल करना काफी दर्दनाक था, जिसने मुझे सही रास्ते पर स्थापित किया।

मैंने आखिरकार इस समस्या को हल कर लिया lsof | grep deleted, जिससे मुझे पता चला कि कौन सा प्रोग्राम दो बहुत बड़ी लॉग फाइल (कुल उपलब्ध 5GB मेरे 8GB रूट फाइल) को पकड़े हुए था।

Comments

यह उत्तर मुझे आश्चर्यचकित करता है कि आप रूट विभाजन पर लॉग फाइल को क्यों स्टोर कर रहे हैं, विशेष रूप से एक जो छोटा है ... लेकिन प्रत्येक अपने स्वयं के लिए, मुझे लगता है ...

— एक CV

मेरे पास एक समान मुद्दा था, मैंने सभी अनुप्रयोगों को हटा दिया था जो हटाए गए फ़ाइल का उपयोग कर रहे थे, मुझे लगता है कि एक ज़ोंबी प्रक्रिया थी जो अभी भी एक बड़ी हटाए गए फ़ाइल को पकड़े हुए है

— user1965449

यह हमारे लिए एक मामला था, एक लॉग प्रोसेसिंग लाइनक्स ऐप जिसे फाइलबीट के रूप में जाना जाता है, फाइलें खुली रखती हैं।

— 20

@Pykler हमारे लिए यह फाइलबीट भी था। पारितोषिक के लिए धन्यवाद!

— मार्टिज़न हेमेल्स

Answer 6

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

Comments

ओपी ने कहा कि वह सिस्टम को रिबूट करेगा और समस्या बनी रही।

— ओल्डट्रॉल

मेरे पास लाश थी जो फाइलों पर ताले नहीं छोड़ती थी, मैं kill -9 'pid'उन्हें ताले छोड़ देता हूं और डिस्क स्थान वापस प्राप्त करता हूं ।

— मिका

Answer 7

यह देखने की कोशिश करें कि क्या डिस्क पर लिखते समय एक मृत / त्रिशंकु प्रक्रिया बंद है: lsof | grep "/ mnt"

फिर किसी भी पीआईडी ​​को मारने की कोशिश करें जो फंस गए हैं (विशेषकर "(हटाए गए") में समाप्त होने वाली लाइनों की तलाश करें)

Comments

धन्यवाद! मैं यह पता लगाने में सक्षम था कि एसएफटीपी सर्वर प्रक्रिया नष्ट कर दी गई फ़ाइल

— lyomi

Answer 8

यह बड़ी फ़ाइलों को खोजने के लिए मैंने आज तक पाया सबसे आसान तरीका है!

यहाँ एक उदाहरण है यदि आपका रूट माउंट भरा हुआ है / (माउंट / रूट) उदाहरण:

सीडी / (इसलिए आप रूट में हैं)

ls | xargs डुह्स

उदाहरण आउटपुट:

 9.4M बिन
 63 एम बूट
 4.0K cgroup
 680K देव
 31 एम आदि
 6.3 जी घर
 313M परिवाद
 32M lib64
 16K खोया + पाया
 61 जी मीडिया
 4.0K mnt
 113M ऑप्ट
 du: 'proc / 6102 / task / 6102 / fd / 4' तक नहीं पहुंच सकता: ऐसी कोई फ़ाइल या निर्देशिका नहीं
 0 खरीद
 19M रूट
 840K रन
 19 एम साइबिन
 4.0K सेलिनक्स
 4.0K srv
 25 जी स्टोर
 26M tmp

तब आप देखेंगे कि स्टोर बड़ी है cd / store

और फिर से दौड़ो

ls | xargs डुह्स

उदाहरण आउटपुट: 
 109 एम बैकअप
 358M fnb
 4.0G आइसो
 8.0K ks
 16K खोया + पाया
 47M रूट
 11M स्क्रिप्ट
 79M tmp
 21 जी वीएमएस

इस मामले में vms निर्देशिका अंतरिक्ष हॉग है।

Comments

क्यों नहीं सरल उपकरण का उपयोग कर रहे हैं baobab? (देखें marzocca.net/linux/baobab/baobab-getting-started.html )

— यवन

एचएम ls+ xargsओवरकिल की तरह लगता है, du -sh /*अपने आप ही ठीक काम करता है

— क्रिसव्यू

यदि आप ncdu के बारे में नहीं जानते हैं ... तो आप मुझे बाद में धन्यवाद देंगे: dev.yorhel.nl/ncdu

— ट्रॉय फोल्गर

Answer 9

मेरे लिए, मुझे चलाने की आवश्यकता थी sudo duक्योंकि एक बड़ी मात्रा में डॉक फाइलें थीं /var/lib/dockerजिनके तहत एक गैर-सूडो उपयोगकर्ता को पढ़ने की अनुमति नहीं है।

Comments

यह मेरी समस्या थी। मैं भूल गया कि मैंने डॉकटर में स्टोरेज सिस्टम को स्विच कर दिया है और पुराने वॉल्यूम अभी भी घूम रहे हैं।

— रिचर्ड निनाबेर

Answer 10

विचार करने की एक और संभावना - यदि आप docker का उपयोग कर रहे हैं, तो आप लगभग एक बड़ी विसंगति देख सकते हैं, और आप वॉल्यूम mounts का उपयोग कर रहे कंटेनर के अंदर df / du चलाते हैं। Docker होस्ट पर वॉल्यूम के लिए आरोहित निर्देशिका के मामले में, df HOST के df योग की रिपोर्ट करेगा। यदि आप इसके बारे में सोचते हैं तो यह स्पष्ट है, लेकिन जब आपको "डिस्क को भरने वाले कंटेनर" की एक रिपोर्ट मिलती है, तो सुनिश्चित करें कि आप कंटेनर के फ़्लेस्पेस की खपत को कुछ इस तरह से सत्यापित करते हैं du -hs <dir>।

Answer 11

इसलिए मुझे सेंटोस 7 में भी यह समस्या थी और ब्लीचबिट और क्लीनिंग / usr और / var जैसे सामानों के एक गुच्छा की कोशिश करने के बाद एक समाधान मिला, हालांकि उन्होंने केवल 7G के बारे में ही दिखाया था। अभी भी रूट विभाजन में उपयोग किए जा रहे 50G के 50G दिखा रहा था, लेकिन केवल 9G फ़ाइल उपयोग दिखाया गया था। एक जीवित ubuntu सीडी दौड़ाया और आक्रामक 50G विभाजन को खोल दिया, टर्मिनल खोला और विभाजन पर xfs_check और xfs_repair चला। मैंने तब विभाजन को रिमूव किया और मेरी खोई हुई + मिली निर्देशिका का विस्तार 40G हो गया। आकार के आधार पर खोए हुए + को मिला और भाप के लिए एक 38G टेक्स्ट लॉग फ़ाइल मिली जो अंततः एक एमपी 3 त्रुटि को दोहराती है। बड़ी फाइल को हटा दिया और अब जगह है और मेरे डिस्क उपयोग मेरे रूट विभाजन आकार से सहमत हैं। मैं अभी भी जानना चाहूंगा कि स्टीम लॉग कैसे प्राप्त करें ताकि फिर से इतना बड़ा न हो।

Comments

क्या आपके साथ काम पर ऐसा हुआ था? serverfault.com/help/on-topic

— चूजों

सिर्फ मेरे घर के कंप्यूटर पर नहीं।

— जस्टिन चाडविक

xfs_fsrइस मुद्दे को हमारे लिए तय किया

— Druska

Answer 12

यदि माउंटेड डिस्क एक विंडोज़ मशीन पर एक साझा फ़ोल्डर है, तो ऐसा लगता है कि df पूरे विंडोज़ डिस्क के आकार और डिस्क का उपयोग दिखाएगा, लेकिन डु केवल डिस्क के उस हिस्से को दिखाएगा जिसकी आपके पास पहुंच भी है। (और आरोहित है)। तो इस मामले में समस्या को विंडोज़ मशीन पर ठीक किया जाना चाहिए।

Answer 13

उत्पादन में हमारे साथ एक समान बात हुई, डिस्क का उपयोग 98% हो गया। निम्नलिखित जांच की:

a) df -iइनोड उपयोग की जाँच के लिए, इनोड का उपयोग ६% था इसलिए बहुत छोटी फाइलें नहीं थी

b) rootछिपी हुई फाइलों को माउंट करना और जांचना। कोई अतिरिक्त फ़ाइल दर्ज नहीं की जा सकी । duपरिणाम माउंट से पहले के समान थे।

ग) अंत में, nginxलॉग की जाँच की । इसे डिस्क में लिखने के लिए कॉन्फ़िगर किया गया था, लेकिन एक डेवलपर ने लॉग फ़ाइल को सीधे हटा दिया, जिससे nginxसभी लॉग इन-मेमोरी को रखा जा सके। चूंकि फ़ाइल /var/log/nginx/access.logको डिस्क से हटा दिया rmगया था, इसका उपयोग करके दिखाई नहीं दे duरहा था, लेकिन फ़ाइल द्वारा एक्सेस किया जा रहा था nginxऔर इसलिए इसे अभी भी खुला रखा गया था

Answer 14

मुझे वही समस्या थी जो इस विषय में वर्णित है, लेकिन एक वीपीएस में। इसलिए मैंने इस विषय में वर्णित सभी चीजों का परीक्षण किया है, लेकिन सफलता के बिना। समाधान हमारे VPS प्रदाता जो एक कोटा पुनर्गणना प्रदर्शन किया और के अंतरिक्ष अंतर को सही के साथ समर्थन के लिए एक संपर्क था df -hऔर du-sh /।

Answer 15

मैं आज एक FreeBSD बॉक्स पर इस समस्या में भाग गया। मुद्दा यह था कि यह एक कलाकृति थी vi( vimनिश्चित नहीं कि vimयह समस्या पैदा होगी)। फ़ाइल अंतरिक्ष का उपभोग कर रही थी लेकिन डिस्क पर पूरी तरह से नहीं लिखा गया था।

आप इसे देख सकते हैं:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

यह -n8 वीं कॉलम (कुंजी) द्वारा सभी खुली फाइलों और सॉर्ट्स (संख्यात्मक रूप से ) को देखता है -k8, जो अंतिम दस आइटम दिखाता है।

मेरे मामले में, अंतिम (सबसे बड़ी) प्रविष्टि इस तरह दिखी:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

इसका मतलब यह था कि प्रक्रिया (PID) 12345 डिस्क के अभाव के बावजूद डिस्क के 1.46G (1024 (द्वारा विभाजित आठवें स्तंभ) का उपभोग duकर रही थी। viबहुत बड़ी फ़ाइलों को देखने में भयानक है; यहां तक ​​कि इसके लिए 100MB भी बड़ा है। 1.5G (या वास्तव में बड़ी वह फ़ाइल वास्तव में थी) हास्यास्पद है।

समाधान था sudo kill -HUP 12345(यदि वह काम नहीं करता था, तो मैं sudo kill 12345और यदि वह भी विफल रहता है, तो खूंखार kill -9खेल में आ जाएगा)।

बड़ी फ़ाइलों पर पाठ संपादकों से बचें। त्वरित स्किमिंग के लिए नमूना वर्कअराउंड:

उचित लाइन लंबाई मानकर:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

अनुचित रूप से बड़ी रेखा मान लेना:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

ये उपयोग vim -Rके स्थान पर view, क्योंकि vimलगभग हमेशा बेहतर जब इसके इंस्टॉल हो रहा है ...। उन्हें viewया vi -Rइसके बजाय पाइप करने के लिए स्वतंत्र महसूस करें ।

आप इस तरह के एक बड़ी फ़ाइल वास्तव में इसे संपादित करने के खोलने जा रहे हैं, तो विचार करें sedया awkया कुछ अन्य कार्यक्रम संबंधी दृष्टिकोण।

Answer 16

जाँच करें कि क्या आपके सर्वर में ossec एजेंट स्थापित है। या कुछ प्रॉजेक्ट हटाए गए लॉग फ़ाइलों का उपयोग कर रहा है। मेरे समय में पहले ossec एजेंट था।

Comments

ओपी ने उल्लेख किया कि मशीन को रिबूट किया गया था, इसलिए कोई हटाई गई फाइलें नहीं होनी चाहिए।

— राल्फफ्रीडल

Answer 17

/ खोया / पाया की जाँच करें, मेरे पास एक सिस्टम (सेंटो 7) था और / खोए हुए फ़ाइल में से कुछ ने सभी जगह को खा लिया।

Comments

प्रश्न में वर्णित के रूप में रिपोर्ट किए गए डिस्क उपयोग में अंतर के लिए यह खाता कैसे होगा ?

— रोइमा