सवाल डिस्क पूर्ण, डु अलग बताता है। आगे की जांच कैसे करें?


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

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

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

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

सेटअप के और विवरण के लिए पूछने के लिए स्वतंत्र महसूस करें।


89
2018-05-30 12:29


मूल


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


जवाब:


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


87
2018-05-30 12:35



निर्देशिकाओं को अनमाउंट करने की आवश्यकता के बिना आप इन छिपी हुई फ़ाइलों को पा सकते हैं। नीचे मार्सेल जी के जवाब पर एक नज़र डालें जो बताती है कि कैसे। - mhsekhavat
आपको अपने उत्तर में ऐसा करने के लिए सीएलआई कमांड दिखाना चाहिए - Jonathan
अगर आप सोचते हैं कि यह आपके लिए समझ में नहीं आता है तो भी जांचें! - Chris


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

मेरे मामले में df -h तथा du -sh हार्ड डिस्क आकार के लगभग 50% से मेल नहीं खाया।

यह अपाचे (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 जीबी डिस्क स्पेस को साफ़ कर दिया।


71
2018-03-12 11:10



मेरे लिए, लॉक जहां मैंने प्रोग्राम को बंद करने के बाद भी जारी नहीं किया था (लाश?)। मुझे करना पड़ा kill -9 'pid' ताले को रिहा करने के लिए। उदाहरण: आपके httpd के लिए यह होता kill -9 32617। - Micka
मामूली नोट: आपको दौड़ना पड़ सकता है lsof जैसा sudo या सभी खुले फ़ाइल वर्णनकर्ता नहीं दिखाएंगे - ChrisWue
मैं एच 2 के साथ इसमें भाग गया, जो हर दिन लॉगफाइल में कई गिग जोड़ रहा था। H2 (धीमी) को पुनरारंभ करने के बजाय, मैंने उपयोग किया sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd)। - Desty
मेरे मामले में, फिर भी शुरू होने पर भी httpd अंतरिक्ष जारी नहीं किया जाता है। जब मैं भाग गया /etc/init.d/rsyslog restart यह काम किया: डी - Thanh Nguyen Van
आप पकड़ को छोड़ सकते हैं और बस कर सकते हैं lsof -a +L1 /var, कहा पे -a मतलब और सभी शर्तें (डिफ़ॉल्ट है या), +L1 का अर्थ केवल लिंक से संबंधित फाइलों की सूची 1 से कम है (यानी, खुली फ़ाइल डिस्क्रिप्टर वाली हटाई गई फाइलें), और /var उस माउंट प्वाइंट के नीचे फाइलों के लिए बाधाओं - kbolino


मैं OldTroll के उत्तर से आपकी "गायब" जगह के सबसे संभावित कारण के रूप में सहमत हूं।

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

mount -o bind / /mnt

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

du -h /mnt

और देखें कि आपकी जगह का क्या उपयोग करता है।

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


40
2018-05-30 13:54



इस टिप के लिए बहुत बहुत धन्यवाद। मुझे डाउनटाइम के बिना मेरी बड़ी, "छिपी हुई" फ़ाइलों को ढूंढने और हटाने की अनुमति दी! - choover
धन्यवाद - इससे पता चला है कि डॉकर मेरे हार्ड ड्राइव को diffs के साथ भर रहा था /var/lib/docker/aufs/diff/ - naught101


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


23
2018-05-30 14:10



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


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

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


15
2017-11-14 18:15



यह जवाब मुझे आश्चर्यचकित करता है कि आप मूल विभाजन पर लॉग फ़ाइलों को संग्रहीत क्यों कर रहे हैं, खासकर एक छोटा ... लेकिन प्रत्येक के लिए, मुझे लगता है ... - α CVn
मेरे पास एक ही समस्या थी, मैंने हटाए गए फ़ाइल का उपयोग कर रहे सभी एप्लिकेशन को पुनरारंभ किया था, मुझे लगता है कि एक ज़ोंबी प्रक्रिया अभी भी एक बड़ी हटाई गई फ़ाइल पर हो रही है - user1965449
यह हमारे लिए मामला था, एक लॉग प्रोसेसिंग लिनक्स ऐप जिसे फ़ाइलबीट के रूप में जाना जाता था, फाइलें खुली थीं। - Pykler


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


5
2018-05-30 12:51



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


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

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

सीडी / (तो आप रूट में हैं)

एलएस | xargs du -hs

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

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

तो आप उसे नोटिस करेंगे दुकान बड़ा है ए सीडी / स्टोर

और फिर से चलाओ

एलएस | xargs du -hs

उदाहरण आउटपुट:
 109 एम बैकअप
 358 एम एफएनबी
 4.0 जी आईएसओ
 8.0 के केएस
 16K खो गया + मिला
 47 एम रूट
 11 एम स्क्रिप्ट्स
 7 9 एमएम टीएमपी
 21 जी वीएमएस

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


4
2018-06-26 13:05



सरल उपकरण का उपयोग क्यों नहीं करते हैं baobab? (देख marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
हम्म ls + xargs ओवरकिल की तरह लगता है, du -sh /* खुद ही ठीक काम करता है - ChrisWue
अगर आपको एनसीडीयू के बारे में पता नहीं है ... आप बाद में मुझे धन्यवाद देंगे: dev.yorhel.nl/ncdu - Troy Folger


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

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


3
2018-06-26 10:38



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


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


1
2018-05-04 18:01



क्या यह आपके काम पर हुआ? serverfault.com/help/on-topic - chicks
नहीं बस मेरे घर कंप्यूटर पर। - Justin Chadwick
xfs_fsr हमारे लिए इस मुद्दे को ठीक किया - Druska


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


0
2018-06-21 10:33