Linux इंटरव्यू: df और du अलग-अलग डिस्क उपयोग क्यों दिखाते हैं?

प्रॉम्प्ट और लागू संदर्भ

02:00 बजे, एक एप्लिकेशन ENOSPC में लिखते समय /var प्राप्त करना शुरू करता है। होस्ट रिपोर्ट करता है:

$ df -B1 /var
Filesystem          1B-blocks         Used  Available Use% Mounted on
/dev/nvme0n1p3    214748364800 210453397504          0 100% /var

$ sudo du -x -B1 -s /var
126701535232  /var

$ df -i /var
Filesystem          Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p3    20000000 4200000 15800000   21% /var

राउंडेड मान कुल 200 GiB, df द्वारा उपयोग किया गया 196 GiB, और du के माध्यम से पहुँच योग्य 118 GiB हैं, जिससे उपयोग किए गए स्थान में 78 GiB का अंतर रह जाता है। inode आउटपुट तत्काल कारण के रूप में inode की कमी को खारिज करता है। सर्विस अनप्रिविलेज्ड है, होस्ट को रीबूट नहीं किया जा सकता है, और किसी भी फ़ाइल को तब तक नहीं हटाया जा सकता जब तक कि उसके ओनर और उद्देश्य का पता न चल जाए।

यह Linux प्रोडक्शन-ट्रबलशूटिंग का एक प्रश्न है। सबसे मजबूत उत्तर सबसे बड़े पाथनेम को हटाने से शुरू नहीं होता है। यह पहले साबित करता है कि दोनों टूल्स ने समान फ़ाइल सिस्टम, नेमस्पेस, समय, इकाइयों और एक्सेस स्कोप का अवलोकन किया; फिर यह बताता है कि दृश्यमान डायरेक्टरी ट्री के बाहर कौन सा एलोकेशन मौजूद हो सकता है और ऐसा रिकवरी एक्शन चुनता है जिसके ब्लास्ट रेडियस को समझा गया हो।

इंटरव्यूअर क्या मूल्यांकन करता है

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

दूसरा सिग्नल स्कोप नियंत्रण है। df /var की तुलना अप्रतिबंधित du /var से करना, कंटेनर के अंदर एक कमांड चलाना, परमिशन त्रुटियों को अनदेखा करना, या तेज़ राइट्स के दौरान लिए गए नमूनों की तुलना करना एक विसंगति पैदा कर सकता है। उम्मीदवार को कोई कारण बताने से पहले माउंट टारगेट, माउंट नेमस्पेस, फ़ाइल सिस्टम सीमा, बाइट इकाइयों, अनुमतियों और अवलोकन विंडो को संरेखित करना चाहिए।

तीसरा सिग्नल सुरक्षित घटना प्रतिक्रिया (incident response) है। lsof +aL1 /var उस फ़ाइल सिस्टम पर एक से कम लिंक काउंट वाली खुली फ़ाइलों की पहचान कर सकता है, लेकिन इसका आउटपुट किसी प्रोसेस को किल करने या डिस्क्रिप्टर को ट्रंकेट करने की अनुमति के बजाय एक सबूत है। एक मजबूत उत्तर सर्विस ओनर की पहचान करता है, फ़ाइल डिस्क्रिप्टर और डिवाइस की पुष्टि करता है, एप्लिकेशन-समर्थित लॉग रीओपन या ग्रेसफुल रीस्टार्ट को प्राथमिकता देता है, और डिस्क सुधार और एप्लिकेशन स्वास्थ्य दोनों को सत्यापित करता है।

चौथा सिग्नल समान दिखने वाले कारणों को अलग करना है। ext4 आरक्षित ब्लॉक्स अनप्रिविलेज्ड राइटर्स के लिए उपलब्ध स्थान को कम करते हैं और Size - Used को Avail से अधिक कर सकते हैं; वे यह नहीं समझाते हैं कि 78 GiB को df द्वारा उपयोग किए गए के रूप में क्यों गिना जाता है लेकिन उसी फ़ाइल सिस्टम के du स्कैन से अनुपस्थित है। Inode की कमी भी ENOSPC लौटा सकती है, लेकिन प्रॉम्प्ट का 21% inode उपयोग उस शाखा को अस्वीकार करता है। कॉपी-ऑन-राइट स्नैपशॉट, कम्प्रेशन और कोटा के लिए आँख मूंदकर कॉपी किए गए ext4 कमांड के बजाय फ़ाइल सिस्टम-विशिष्ट टूल्स की आवश्यकता होती है।

अंतिम सिग्नल क्लोजर है। उत्तर में पहले और बाद का साक्ष्य सेट स्थापित होना चाहिए, पुनः प्राप्त बाइट रेंज को समझाना चाहिए, पुष्टि करनी चाहिए कि राइटर ने इच्छित पाथनेम को फिर से खोल दिया है, आवर्ती डिलीट-ओपन वृद्धि की जांच करनी चाहिए, और लॉग रोटेशन या माउंट-परिवर्तन मॉनिटरिंग में सुधार करना चाहिए। केवल df में कम प्रतिशत यह साबित नहीं करता है कि एप्लिकेशन स्वस्थ है या डेटा सुरक्षित रखा गया था।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या दोनों कमांड एक ही माउंट नेमस्पेस में चल रहे हैं? यदि एक होस्ट पर और दूसरा कंटेनर या सर्विस नेमस्पेस में चलता है, तो /var विभिन्न माउंट्स पर रिज़ॉल्व हो सकता है। जांच को प्रभावित प्रोसेस के नेमस्पेस में प्रवेश करना चाहिए या जानबूझकर होस्ट पर रहना चाहिए।
• कौन सा सटीक पाथ विफल हो रहा है और किस फ़ाइल सिस्टम में यह शामिल है? findmnt -T किसी भी पाथ को उसके माउंट पर मैप करता है। एक नेस्टेड या बाइंड माउंट बदल देता है कि df और du की तुलना किससे की जानी चाहिए।
• क्या नमूने समान इकाइयों और अनुमतियों के साथ एक साथ लिए गए थे? तेजी से बढ़ते लॉग कमांड्स के बीच बदल सकते हैं, मानव-पठनीय राउंडिंग छोटे अंतरों को छुपाती है, और अपठनीय डायरेक्टरीज़ एक अनप्रिविलेज्ड du को कम गिनती कराती हैं।
• कौन से फ़ाइल सिस्टम और स्टोरेज लेयर्स शामिल हैं? ext4, XFS, Btrfs, ZFS, ओवरले फ़ाइल सिस्टम, LVM स्नैपशॉट, और क्लाउड वॉल्यूम स्नैपशॉट विभिन्न अकाउंटिंग और रिकवरी नियंत्रण उजागर करते हैं।
• क्या कमी डेटा ब्लॉक्स, inodes या कोटा में है? df -i, कोटा टूल्स और एप्लिकेशन त्रुटि शाखाओं में अंतर करते हैं। एक बड़ी फ़ाइल को हटाने से inode की कमी ठीक नहीं होती है, और मुक्त वैश्विक ब्लॉक्स उपयोगकर्ता या प्रोजेक्ट कोटा को ओवरराइड नहीं करते हैं।
• ऑपरेशनल रूप से कौन से रिकवरी एक्शन की अनुमति है? लॉग-रीओपन सिग्नल, ग्रेसफुल रीस्टार्ट, फ़ेलओवर, या छोटे मेंटेनेंस विंडो में अलग-अलग उपलब्धता जोखिम होते हैं। आपातकालीन डिस्क्रिप्टर ट्रंकेशन के लिए स्पष्ट स्वामित्व और रोलबैक योजना की आवश्यकता होती है।
• कितना हेडरूम पुनर्स्थापित किया जाना चाहिए, और कब तक? लक्ष्य यह निर्धारित करता है कि राइट्स को रोकना है, वॉल्यूम का विस्तार करना है, ट्रैफ़िक को फ़ेलओवर करना है, या पहले ज्ञात एलोकेशन को पुनः प्राप्त करना है। यह अज्ञात डेटा को हटाने का औचित्य साबित नहीं करता है।

30-सेकंड का उत्तर ढांचा

"मैं पहले विनाशकारी कार्यों को रोकूँगा और findmnt, df -B1, और sudo du -x -B1 का उपयोग करके उसी पाथ, फ़ाइल सिस्टम, माउंट नेमस्पेस, समय, अनुमतियों और बाइट इकाइयों की तुलना करूँगा। Inode उपयोग 21% होने के साथ, मैं 78 GiB ब्लॉक अंतर को मापूँगा और उन अनलिंक की गई फ़ाइलों के लिए lsof +aL1 /var की जाँच करूँगा जिन्हें प्रोसेस अभी भी खुला रखे हुए हैं। यदि कोई अंतर को समझाता है, तो मैं इसके PID, डिस्क्रिप्टर, डिवाइस और सर्विस ओनर को सत्यापित करूँगा, फिर एप्लिकेशन के लॉग-रीओपन पाथ या ग्रेसफुल रीस्टार्ट का उपयोग करूँगा और पुष्टि करूँगा कि स्पेस वापस आ गया है। यदि नहीं, तो मैं ओवर-माउंटेड डायरेक्टरीज़, परमिशन त्रुटियों और फ़ाइल सिस्टम-विशिष्ट मेटाडेटा या स्नैपशॉट का निरीक्षण करूँगा। ext4 आरक्षित ब्लॉक्स शून्य अनप्रिविलेज्ड उपलब्धता की व्याख्या करते हैं, 78 GiB उपयोग किए गए स्थान के अंतर की नहीं। मैं मापों को दोहराकर और एप्लिकेशन राइट्स, लॉग्स और पुनरावृत्ति की जाँच करके समाप्त करूँगा।"

चरण-दर-चरण गहन विश्लेषण

तुलना को पुनरुत्पादित करने योग्य बनाकर शुरुआत करें। विफल पाथ, वर्तमान नेमस्पेस, माउंट स्रोत, फ़ाइल सिस्टम प्रकार, ब्लॉक सांख्यिकी, inode सांख्यिकी, और du कुल को एक साथ कैप्चर करें:

readlink -f /var
findmnt -T /var -o SOURCE,FSTYPE,OPTIONS,TARGET
df -B1 /var
df -i /var
sudo du -x -B1 -s /var

-x, du को /var वाले फ़ाइल सिस्टम पर ही रखता है, इसलिए नेस्टेड फ़ाइल सिस्टम कुल में नहीं जोड़ा जाता है। -B1 ब्लॉक-इकाई की अस्पष्टता को दूर करता है। du को पर्याप्त विशेषाधिकार के साथ चलाएं और इसके डायग्नोस्टिक्स पढ़ें; परमिशन त्रुटियों का निरीक्षण किए बिना उन्हें दबाना एक एक्सेस समस्या को एक झूठे स्टोरेज सिद्धांत में बदल देता है। एक ही माउंट नेमस्पेस से कमांड कैप्चर करें। कंटेनराइज़्ड राइटर के लिए, यह मानने के बजाय कि समान पाथ स्ट्रिंग्स समान ऑब्जेक्ट्स को नाम देती हैं, होस्ट दृश्य की तुलना एक विचारशील nsenter दृश्य से करें।

देखा गया अंतर एक डायग्नोस्टिक मात्रा है, न कि खोजने के लिए कोई फ़ाइल:

same_filesystem_gap = df_used_blocks - du_reachable_allocated_blocks
                    = 196 GiB - 118 GiB
                    = 78 GiB

यह समीकरण अनुमानित है क्योंकि फ़ाइल सिस्टम मेटाडेटा, एलोकेशन ग्रैन्युलैरिटी, समवर्ती राइट्स, कॉपी-ऑन-राइट शेयरिंग, कम्प्रेशन और टूल सिमेंटिक्स एक संपूर्ण विभाजन नहीं बनाते हैं। यह अभी भी उपयोगी है: एक स्थिर 78 GiB का अंतर इतना बड़ा है कि इसे आउटपुट राउंडिंग के रूप में खारिज नहीं किया जा सकता है। किसी अन्य सामान्य बड़े पाथनेम को खोजने से पहले उन कारणों की खोज करें जो दृश्यमान, पहुँच योग्य ट्री के बाहर ब्लॉक्स आवंटित करते हैं।

सबसे अधिक मूल्यवान जाँच एक खुली फ़ाइल है जिसका अंतिम डायरेक्टरी लिंक हटा दिया गया है:

sudo lsof +aL1 /var

# After selecting a candidate from lsof, verify the live descriptor.
sudo readlink /proc/2481/fd/7
sudo stat -Lc 'device=%d inode=%i size=%s blocks=%b block_size=%B' /proc/2481/fd/7

Linux unlink एक नाम हटाता है। यदि यह अंतिम लिंक था लेकिन किसी प्रोसेस में अभी भी फ़ाइल खुली है, तो फ़ाइल और उसके ब्लॉक्स तब तक बने रहते हैं जब तक कि अंतिम संदर्भित डिस्क्रिप्टर बंद नहीं हो जाता। du डायरेक्टरी ट्री के माध्यम से उस inode तक नहीं पहुँच सकता है; df अभी भी इसके आवंटित ब्लॉक्स की गिनती करता है। एक सामान्य घटना पथ एक लॉगर है जो रोटेशन द्वारा इसे गलत तरीके से डिलीट या रीनेम करने के बाद भी फ़ाइल में लिखना जारी रखता है।

प्रत्येक स्पार्स या विशेष फ़ाइल के लिए स्पष्ट SIZE/OFF मान को सटीक रिक्लेम पूर्वानुमान के रूप में न समझें। पुष्टि करें कि डिस्क्रिप्टर टारगेट डिवाइस पर एक नियमित फ़ाइल है, इसका लिंक काउंट शून्य है, कौन सा प्रोसेस इसका ओनर है, क्या यह अभी भी बढ़ रहा है, और क्या एप्लिकेशन में एक प्रलेखित रीओपन सिग्नल है। यदि एक डिस्क्रिप्टर 78 GiB के अधिकांश हिस्से की व्याख्या नहीं करता है, तो कई बड़े डिस्क्रिप्टर को सहसंबंधित करें।

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

/proc/PID/fd/FD के माध्यम से लिखना प्रोसेस को रोके बिना स्पेस को पुनः प्राप्त कर सकता है, लेकिन यह अंतिम उपाय है। राइटर एक पुराना ऑफ़सेट बनाए रख सकता है, अपने अगले राइट पर एक स्पार्स होल बना सकता है, एप्लिकेशन फॉर्मेट को दूषित कर सकता है, या आंतरिक इनवेरिएंट्स को विफल कर सकता है। इसका उपयोग केवल तभी करें जब सर्विस ओनर डिस्क्रिप्टर और राइट सिमेंटिक्स की पुष्टि करता है, ट्रैफ़िक निहित है, साक्ष्य संरक्षित हैं, और एक रिकवरी योजना मौजूद है। सामान्य रनबुक को कभी भी डिस्क्रिप्टर ट्रंकेशन को डिफ़ॉल्ट समाधान के रूप में विज्ञापित नहीं करना चाहिए।

यदि lsof अंतर को स्पष्ट नहीं कर सकता है, तो माउंट टोपोलॉजी का निरीक्षण करें। एक गैर-खाली डायरेक्टरी पर माउंट किया गया फ़ाइल सिस्टम अंतर्निहित डायरेक्टरी प्रविष्टियों को छुपाता है जबकि उनके ब्लॉक्स पैरेंट फ़ाइल सिस्टम पर आवंटित रहते हैं। findmnt नेस्टेड, बाइंड और ओवर-माउंटेड पाथ्स को प्रकट करता है। स्वीकृत मेंटेनेंस कार्रवाई के दौरान, /var के बाहर एक खाली टारगेट के लिए /var का एक गैर-पुनरावर्ती बाइंड प्रोडक्शन चाइल्ड माउंट को अनमाउंट किए बिना अंतर्निहित पैरेंट दृश्य को उजागर कर सकता है:

sudo mkdir -p /mnt/var-underlay
sudo mount --bind /var /mnt/var-underlay
sudo du -x -B1 -s /mnt/var-underlay
sudo umount /mnt/var-underlay

पहले वास्तविक माउंट ट्री के विरुद्ध इस दृष्टिकोण को मान्य करें; नेमस्पेस प्रसार और प्लेटफ़ॉर्म नीति इसके प्रभाव को बदल सकती है। व्यस्त प्रोडक्शन फ़ाइल सिस्टम का केवल निरीक्षण करने के लिए उसे अनमाउंट न करें। यदि छिपी हुई फ़ाइलें पाई जाती हैं, तो उन्हें स्थानांतरित करने या हटाने से पहले उनके ओनर और प्रतिधारण आवश्यकताओं की पहचान करें।

इसके बाद उपयोग किए गए स्थान के अंतर से उपलब्धता लेखांकन को अलग करें। ext4 पर, विशेषाधिकार प्राप्त प्रोसेस आरक्षित ब्लॉक्स एप्लिकेशन के लिए उपलब्ध कच्चे मुक्त ब्लॉक्स को अनुपलब्ध कर सकते हैं। संशोधित करने के बजाय निरीक्षण करें:

source=$(findmnt -n -o SOURCE -T /var)
sudo tune2fs -l "$source" | grep -E 'Block count|Reserved block count|Block size'
sudo du --inodes -x -d1 /var | sort -n

प्रॉम्प्ट में कुल और उपयोग किए गए के बीच 4 GiB है लेकिन शून्य उपलब्ध के रूप में दिखाया गया है, जो कि अनप्रिविलेज्ड सर्विस के लिए अनुपलब्ध कुछ मुक्त ब्लॉक्स के अनुरूप है। यह तत्काल राइट विफलता की व्याख्या करता है, न कि df, du की पहुंच से 78 GiB अधिक को उपयोग किए गए के रूप में क्यों चिह्नित करता है। किसी घटना के दौरान रिजर्व को कम करने से विशेषाधिकार प्राप्त डेमन्स के लिए इच्छित हेडरूम हट सकता है और विखंडन जोखिम बढ़ सकता है; इसके लिए क्षमता निर्णय की आवश्यकता होती है, न कि रिफ्लेक्सिव tune2fs -m 0 की।

Inode की कमी एक अन्य स्वतंत्र ENOSPC पाथ है। यहाँ df -i 21% दिखाता है, इसलिए यह ट्रिगर नहीं है। यदि यह 100% था, तो उच्च-फ़ाइल-गिनती ट्रीज़ का पता लगाने के लिए du --inodes -x का उपयोग करें और केवल प्रतिधारण नीति द्वारा कवर किए गए डेटा को हटा दें। ब्लॉक रिक्लेमेशन और inode रिक्लेमेशन अलग-अलग उद्देश्य हैं।

फ़ाइल सिस्टम-विशिष्ट लेखांकन सबसे अंत में आता है। GNU du दस्तावेज करता है कि कॉपी-ऑन-राइट शेयरिंग, कम्प्रेशन, बैकअप ब्लॉक्स और नेटवर्क फ़ाइल सिस्टम इसके अनुमान को डिवाइस खपत से अलग कर सकते हैं। Btrfs या ZFS पर, उस फ़ाइल सिस्टम के टूल्स के साथ सबवॉल्यूम, स्नैपशॉट, कोटा, और एक्सक्लूसिव बनाम संदर्भित बाइट्स का निरीक्षण करें। ओवरले स्टोरेज पर, नेमस्पेस और रनटाइम से लेयर्स का निरीक्षण करें जो उनके ओनर हैं। XFS या Btrfs स्रोत के विरुद्ध ext4 टूल्स न चलाएं।

यदि खुली फ़ाइलें, छिपा हुआ डेटा, एक्सेस त्रुटियां, समवर्ती वृद्धि, आरक्षित उपलब्धता और फ़ाइल सिस्टम सुविधाएं अभी भी साक्ष्य की व्याख्या नहीं करती हैं, तो कर्नेल लॉग और फ़ाइल सिस्टम स्वास्थ्य का निरीक्षण करें। एक रिपेयर टूल एक ऑनलाइन डायग्नोस्टिक शॉर्टकट नहीं है: साक्ष्य सुरक्षित रखें, फ़ाइल सिस्टम की प्रलेखित प्रक्रिया का उपयोग करें, और किसी भी जाँच को शेड्यूल करें जिसके लिए अनमाउंटेड वॉल्यूम की आवश्यकता होती है।

उसी साक्ष्य सेट के साथ घटना को समाप्त करें। df -B1, df -i, और विशेषाधिकार प्राप्त du -x -B1 को दोहराएं; पुष्टि करें कि पुनः प्राप्त बाइट्स अपेक्षित ओवरहेड के भीतर बंद या हटाए गए एलोकेशन से मेल खाते हैं; एक नए एप्लिकेशन राइट को सत्यापित करें; पुष्टि करें कि सर्विस अब इच्छित नामित फ़ाइल में लिखती है; और विलंबता, त्रुटियों, रेप्लिका और डेटा अखंडता की जाँच करें। फिर ब्लॉक और inode हेडरूम, डिलीट-ओपन वृद्धि, लॉग-रोटेशन विफलताओं, माउंट टोपोलॉजी परिवर्तनों और अप्रत्याशित स्नैपशॉट वृद्धि पर अलर्ट सेट करें।

उच्च गुणवत्ता वाला नमूना उत्तर

"78 GiB का अंतर प्रशंसनीय है क्योंकि df और du के लेखांकन दायरे अलग-अलग हैं। df को फ़ाइल सिस्टम-व्यापी ब्लॉक आँकड़े मिलते हैं, जबकि du उन नामित प्रविष्टियों को स्कैन करता है जिन तक वह पहुँच सकता है। मैं पहले /var को findmnt के साथ मैप करके, प्रभावित सर्विस के माउंट नेमस्पेस में दोनों टूल्स चलाकर, बाइट इकाइयों, du -x, रूट विशेषाधिकारों और लगभग एक साथ नमूनों का उपयोग करके साबित करूँगा कि यह एक वास्तविक अंतर है। Inodes केवल 21% हैं, इसलिए मैं उस शाखा को अलग रखूँगा।

मेरी पहली परिकल्पना डिलीट-ओपन फ़ाइलों की है। मैं lsof +aL1 /var चलाऊँगा, फिर प्रत्येक बड़े परिणाम के PID, फ़ाइल डिस्क्रिप्टर, डिवाइस, inode, ओनर और वृद्धि को सत्यापित करूँगा। यदि कोई लॉगर अभी भी लगभग गायब स्थान का ओनर है, तो मैं इसके समर्थित रीओपन सिग्नल या नियंत्रित ग्रेसफुल रीस्टार्ट का उपयोग करूँगा। जब तक सर्विस ओनर ब्लास्ट रेडियस की पुष्टि नहीं करता, तब तक मैं प्रोसेस को किल करने या /proc को ट्रंकेट करने से बचूँगा। डिस्क्रिप्टर बंद होने के बाद, मैं जाँच करूँगा कि df अपेक्षित सीमा को पुनः प्राप्त करता है और एप्लिकेशन नए नामित लॉग में लिखता है।

यदि वह अंतर को स्पष्ट नहीं करता है, तो मैं ऐसी डायरेक्टरी के लिए findmnt आउटपुट का निरीक्षण करूँगा जिसकी अंतर्निहित फ़ाइलें किसी अन्य माउंट द्वारा छिपी हुई हैं, du परमिशन त्रुटियों की समीक्षा करूँगा, और फिर स्नैपशॉट, कॉपी-ऑन-राइट एलोकेशन, कोटा और मेटाडेटा के लिए फ़ाइल सिस्टम-विशिष्ट टूल्स का उपयोग करूँगा। चूँकि यह वॉल्यूम ext4 है, इसलिए मैं आरक्षित ब्लॉक्स का निरीक्षण करूँगा। वे समझा सकते हैं कि सर्विस के पास शून्य उपलब्ध बाइट्स क्यों हैं, भले ही कुल घटाव उपयोग किया गया 4 GiB है, लेकिन वे 78 GiB उपयोग किए गए स्थान के अंतर की व्याख्या नहीं कर सकते।

मैं मूल मापों को दोहराकर, विफल राइट पाथ का परीक्षण करके, सर्विस स्वास्थ्य और डेटा अखंडता की जाँच करके, और वास्तव में कौन सा एलोकेशन जारी किया गया था, इसे रिकॉर्ड करके समाप्त करूँगा। रोकथाम का काम लॉग रोटेशन या माउंट जीवनचक्र को ठीक करना, ब्लॉक्स और inodes दोनों पर अलर्ट करना और फ़ाइल सिस्टम के आपातकालीन रिजर्व तक पहुँचने से पहले अनलिंक-ओपन वृद्धि की निगरानी करना है।"

सामान्य गलतियाँ

• सबसे बड़ी दृश्यमान फ़ाइल को तुरंत हटाना → यह आवश्यक डेटा हो सकता है और एक अदृश्य एलोकेशन की व्याख्या नहीं कर सकता है → डेटा बदलने से पहले मापन के दायरे को संरेखित करें और ओनर की पहचान करें।
• df /var की तुलना du / से करना → नेस्टेड फ़ाइल सिस्टम और विभिन्न रूट्स घटाव को अमान्य करते हैं → विफल पाथ को मैप करें और उसी फ़ाइल सिस्टम पर du -x का उपयोग करें।
• du परमिशन त्रुटियों को अनदेखा करना → अगम्य नामित फ़ाइलें कुल को कृत्रिम रूप से कम करती हैं → पर्याप्त विशेषाधिकार के साथ चलाएं और प्रत्येक डायग्नोस्टिक की समीक्षा करें।
• विभिन्न माउंट नेमस्पेस में कमांड चलाना → समान पाथनेम विभिन्न फ़ाइल सिस्टम में रिज़ॉल्व हो सकता है → प्रभावित प्रोसेस के नेमस्पेस में दोनों माप एकत्र करें।
• 78 GiB के अंतर को "आरक्षित ब्लॉक्स" कहना → ext4 रिजर्व अनप्रिविलेज्ड उपलब्धता को प्रभावित करता है, जबकि अंतर उपयोग किए गए ब्लॉक्स की तुलना पहुंच योग्य एलोकेशन से करता है → प्रत्येक अंतर की अलग से गणना करें।
• पहले से डिलीट-ओपन फ़ाइल पर rm का उपयोग करना → इसका अंतिम नाम पहले ही जा चुका है और लाइव डिस्क्रिप्टर inode को आवंटित रखता है → स्वामित्व वाले प्रोसेस को डिस्क्रिप्टर को बंद करने या सुरक्षित रूप से फिर से खोलने के लिए कहें।
• पहले समाधान के रूप में kill -9 भेजना → अचानक समाप्ति से काम का नुकसान हो सकता है और क्लीनअप बायपास हो सकता है → समर्थित रीओपन, रीलोड, ग्रेसफुल रीस्टार्ट, या फ़ेलओवर पाथ को प्राथमिकता दें।
• आदतवश /proc/PID/fd/FD को ट्रंकेट करना → रिटेन्ड ऑफ़सेट और फ़ाइल-फ़ॉर्मेट धारणाएं नया करप्शन पैदा कर सकती हैं → सत्यापित सिमेंटिक्स के साथ स्वीकृत आपातकाल के लिए ट्रंकेशन आरक्षित रखें।
• छिपी हुई फ़ाइलों को प्रकट करने के लिए व्यस्त चाइल्ड माउंट को अनमाउंट करना → आश्रित सेवाएं तुरंत विफल हो सकती हैं → टोपोलॉजी का निरीक्षण करें और स्वीकृत वैकल्पिक दृश्य या मेंटेनेंस विंडो का उपयोग करें।
• Inode के उपयोग को बाइट अंतर के हिस्से के रूप में मानना → Inode की कमी एक अलग ENOSPC तंत्र है → df -i की जाँच करें और उच्च फ़ाइल गणनाओं का स्वतंत्र रूप से निदान करें।
• प्रत्येक फ़ाइल सिस्टम पर ext4 कमांड लागू करना → स्नैपशॉट और एलोकेशन सिमेंटिक्स XFS, Btrfs, ZFS, और ओवरले लेयर्स में भिन्न होते हैं → FSTYPE की पहचान करें और इसके समर्थित टूल्स का उपयोग करें।
• df गिरने के बाद रुक जाना → राइटर अभी भी अस्वस्थ हो सकता है या गलत टारगेट पर लॉगिंग कर सकता है → एप्लिकेशन राइट्स, नामित फ़ाइलों, डेटा अखंडता और पुनरावृत्ति संकेतों को सत्यापित करें।

फ़ॉलो-अप प्रश्न और उत्तर

फ़ॉलो-अप 1: क्या होगा यदि lsof अनुपलब्ध है या प्रोसेस को नहीं देखता है?

राइटर के समान PID और माउंट नेमस्पेस में /proc/PID/fd का निरीक्षण करें, (deleted) में समाप्त होने वाले सिम्लिंक की तलाश करें, फिर डिवाइस, inode, लिंक काउंट और प्रोसेस स्वामित्व को सत्यापित करें। यदि अनुमतियाँ, PID नेमस्पेस, या सुरक्षा नीति इसे छिपाती है तो होस्ट lsof एक कंटेनराइज़्ड प्रोसेस को मिस कर सकता है। /proc ट्रंकेशन को अगला स्वचालित कदम न बनाएं; रिकवरी का निर्णय सर्विस-विशिष्ट रहता है।

फ़ॉलो-अप 2: क्या होगा यदि du इसके बजाय df से बड़ा है?

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

फ़ॉलो-अप 3: Btrfs या ZFS पर क्या बदलता है?

दृश्यमान फ़ाइल आकार अपर्याप्त हैं क्योंकि स्नैपशॉट और कॉपी-ऑन-राइट शेयरिंग पाथनेम हटाए जाने के बाद भी ब्लॉक्स को बनाए रख सकते हैं। फ़ाइल सिस्टम के अपने स्पेस, सबवॉल्यूम या डेटासेट, स्नैपशॉट और कोटा दृश्यों का उपयोग करें; संदर्भित को अनन्य आवंटन से अलग करें; और स्नैपशॉट को केवल एक स्पष्ट प्रतिधारण नीति के तहत हटाएं। ext4 आरक्षित-ब्लॉक तर्क और tune2fs स्थानांतरित नहीं होते हैं।

फ़ॉलो-अप 4: क्या हम तुरंत पुनर्प्राप्त करने के लिए ext4 आरक्षित प्रतिशत को शून्य पर सेट कर सकते हैं?

केवल क्षमता और विश्वसनीयता समीक्षा के बाद। रिजर्व विशेषाधिकार प्राप्त प्रोसेस को जारी रखने की अनुमति देता है और विखंडन को कम कर सकता है। यह अनप्रिविलेज्ड उपलब्धता को पुनर्स्थापित कर सकता है, लेकिन यह उपयोग किए गए ब्लॉक्स को नहीं हटाता है या डिलीट-ओपन एलोकेशन की व्याख्या नहीं करता है। पहले ज्ञात क्षमता को पुनः प्राप्त करें या उसका विस्तार करें, फिर वॉल्यूम भूमिका और परिचालन नीति के अनुसार रिजर्व को ट्यून करें।

फ़ॉलो-अप 5: आप डिलीट-ओपन व्यवहार को सुरक्षित रूप से कैसे पुनरुत्पादित करेंगे?

एक डिस्पोजेबल फ़ाइल सिस्टम या टेस्ट होस्ट का उपयोग करें: एक प्रोसेस के साथ एक बड़ी टेस्ट फ़ाइल खोलें, डिस्क्रिप्टर खुले रहने के दौरान इसके पाथनेम को अनलिंक करें, df और du की तुलना करें, इसे lsof +L1 के साथ देखें, फिर डिस्क्रिप्टर को बंद करें और पुष्टि करें कि ब्लॉक्स वापस आ गए हैं। प्रोडक्शन वॉल्यूम पर प्रयोग न करें या वास्तविक सर्विस के डिस्क्रिप्टर का पुन: उपयोग न करें।

फ़ॉलो-अप 6: दीर्घकालिक अलर्ट को क्या मापना चाहिए?

फ़ाइल सिस्टम और नेमस्पेस द्वारा विभाजित ब्लॉक्स और inodes दोनों के लिए समाप्ति का समय (time-to-exhaustion) और न्यूनतम हेडरूम पर अलर्ट करें। डिलीट-ओपन रेगुलर फ़ाइलों, लॉग-रोटेशन विफलताओं, स्नैपशॉट वृद्धि, और माउंट टोपोलॉजी परिवर्तनों के लिए एक गेज या आवधिक इन्वेंट्री जोड़ें। अलर्ट को एक ऐसे रनबुक से लिंक होना चाहिए जो स्कोप संरेखण के साथ शुरू होता है और विनाशकारी रिकवरी से पहले ओनर की मंजूरी की आवश्यकता होती है।