सामान्य इंटरव्यू: जब डिस्क स्पेस बचा हो, तब आप Inode Exhaustion का निदान कैसे करते हैं?

प्रश्न और दायरा

सामान्य बाइट उपयोग यह साबित नहीं करता कि फ़ाइल सिस्टम एक और फ़ाइल बना सकता है। ext4 और समान फ़ाइल सिस्टम डेटा ब्लॉक और inode को प्रबंधित करते हैं; लाखों छोटी फ़ाइलें, कैश टुकड़े, मेल कतारें, या कंटेनर लेयर पहले inode को समाप्त कर सकते हैं। कार्य यह है कि किसी अज्ञात डायरेक्टरी को हटाए बिना या पुनरारंभ (restart) के साथ साक्ष्य छिपाए बिना, सर्विस के चलने के दौरान कारण का पता लगाया जाए।

सार्वजनिक Linux और DevOps इंटरव्यू सामग्री अक्सर "डिस्क फुल" को एक डायग्नोस्टिक परिदृश्य के रूप में उपयोग करती है। df मैनुअल और Linux कर्नेल ext4 दस्तावेज़ ब्लॉक, inode और डायरेक्टरी प्रविष्टियों के बीच की सीमाओं को परिभाषित करते हैं, इसलिए एक मजबूत उत्तर क्लीनअप कमांड को दोहराने के बजाय साक्ष्य से कार्रवाइयां प्राप्त करता है।

इंटरव्यूअर क्या जांच रहा है

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

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

विफल प्रक्रिया किस पाथ और माउंट पर लिखती है? क्या यह होस्ट, कंटेनर या अस्थायी फ़ाइल सिस्टम है?
df -h और df -i क्या रिपोर्ट करते हैं? क्या उपयोगकर्ता या प्रोजेक्ट कोटा शामिल हैं?
क्या विफलता फ़ाइल बनाते समय, फ़ाइल बढ़ाते समय, या overlay, tmpfs, या नेटवर्क फ़ाइल सिस्टम पर लिखते समय हो रही है?
क्या कोई डिप्लॉय, लॉग रोटेशन, बैकअप या बैच जॉब चल रहा है? क्या प्रतिधारण (retention) नियम हटाने को प्रतिबंधित करते हैं?
क्या सर्विस को थोड़े समय के लिए थ्रॉटल किया जा सकता है, और क्या कोई रोलबैक या हेल्थ-चेक विंडो है?

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

“मैं विफल प्रक्रिया, माउंट और समय सीमा का निर्धारण करूंगा, फिर df -h की तुलना df -i से करूंगा। यदि inode उपयोग 100% के करीब है, तो मैं फ़ाइल-गणना हॉटस्पॉट का पता लगाऊंगा और कंटेनर राइटेबल लेयर, लॉग रोटेशन और कोटा का निरीक्षण करूंगा। यदि inode स्वस्थ हैं, तो मैं ब्लॉक, आरक्षित स्थान, कोटा और डिलीट-की-गई-लेकिन-खुली फ़ाइलों की जांच करूंगा। रिकवरी एक नियंत्रित रोटेशन, संपीड़न, पुष्ट अस्थायी डेटा की सफाई, या साक्ष्य को संरक्षित करते हुए विस्तार के साथ शुरू होगी। अंत में मैं केवल एक डिस्क प्रतिशत के बजाय बाइट्स, inode, फ़ाइल गणना, विकास दर और सुधार के समय पर अलर्ट करूंगा।”

विस्तृत उत्तर

चरण 1: दोष सीमा (fault boundary) स्थापित करें

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

चरण 2: ब्लॉक और inode की एक साथ जांच करें

bash

df -hT /
df -iT /
findmnt -T /var/lib/app

df -h डेटा ब्लॉक की रिपोर्ट करता है और df -i inode की रिपोर्ट करता है। विफल पाथ के स्वामित्व वाले माउंट के लिए दोनों को पढ़ें। यदि बाइट्स शेष रहते हुए inode का उपयोग 100% के करीब है, तो छोटी-फ़ाइल विश्लेषण को प्राथमिकता दें; यदि नहीं, तो ब्लॉक, कोटा, रीड-ओनली स्थिति और कंटेनर सीमाओं का निरीक्षण करें।

चरण 3: गणना के अनुसार डायरेक्टरी हॉटस्पॉट का पता लगाएं

अनावश्यक I/O से बचने के लिए फ़ाइल सामग्री पढ़ने से पहले डायरेक्टरी प्रविष्टियों की गणना करें। खोज को डायरेक्टरी के आधार पर सीमित करें और सबसे तेजी से बढ़ने वाली शाखा में उतरें। find को ज्ञात पाथ तक सीमित रखें, अन्य माउंट को बाहर करें, और पीक ट्रैफ़िक के दौरान ट्रैवर्सल को एक संसाधन बजट दें। छोटी फ़ाइलों से भरी डायरेक्टरी बहुत कम बाइट स्पेस का उपयोग करते हुए inode का उपभोग कर सकती है।

चरण 4: माउंट सीमाओं से फ़ाइलों को अलग करें

Overlay फ़ाइल सिस्टम, बाइंड माउंट, tmpfs, और लॉग वॉल्यूम होस्ट पाथ को उस लेयर से भिन्न बना सकते हैं जहाँ प्रक्रिया लिखती है। प्रक्रिया की वर्किंग डायरेक्टरी, कंटेनर कॉन्फ़िगरेशन और findmnt -T की क्रॉस-जांच करें। होस्ट से कंटेनर-लेयर फ़ाइलों को न हटाएं; रनटाइम, वॉल्यूम नीति, या एप्लिकेशन क्लीनअप पाथ का उपयोग करें।

चरण 5: रोटेशन, कैश और डिलीट-की-गई-खुली फ़ाइलों का निरीक्षण करें

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

चरण 6: रिकवरी कार्रवाई चुनें

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

चरण 7: रिकवरी और साइड इफेक्ट्स सत्यापित करें

df -hT और df -iT को फिर से चलाएं, फिर एक वास्तविक अस्थायी-फ़ाइल निर्माण, लॉग राइट और महत्वपूर्ण अनुरोध निष्पादित करें। पुष्टि करें कि inode उपयोग, त्रुटि दर और विलंबता (latency) ठीक हो गई है। कंटेनरों के लिए, सत्यापित करें कि पुनर्निर्माण या पुनरारंभ करने से फ़ाइल-गणना स्पाइक तुरंत फिर से नहीं बनता है।

चरण 8: टिकाऊ सुरक्षा उपाय बनाएं

ब्लॉक और inode उपयोग, प्रति माउंट फ़ाइलें, डायरेक्टरी वृद्धि, रोटेशन विलंब, डिलीट-की-गई-खुली फ़ाइलें और कंटेनर-लेयर आकार की निगरानी करें। एक सार्वभौमिक 90% संख्या के बजाय विकास दर और प्रतिक्रिया समय से सीमाएं (thresholds) निर्धारित करें। क्लीनअप, विस्तार, रोटेशन रिकवरी और सत्यापन को एक निष्पादन योग्य रनबुक में रखें और इसका अभ्यास करें।

ट्रेड-ऑफ और सीमाएं

क्लीनअप बनाम विस्तार

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

मापन सटीकता बनाम ऑनलाइन लागत

पूरी डिस्क का find सटीक है लेकिन महंगा है। डायरेक्टरी गणना और नमूनाकरण निरंतर निगरानी के लिए उपयुक्त हैं। किसी घटना के दौरान, I/O दबाव में पूरे फ़ाइल सिस्टम को पुनरावर्ती (recursively) रूप से पढ़ने के बजाय दायरे को उत्तरोत्तर सीमित करें।

होस्ट बनाम कंटेनर

होस्ट मेट्रिक्स वॉल्यूम और overlay मेट्रिक्स की जगह नहीं लेते हैं। प्रत्येक लिखने योग्य लेयर को एक कोटा, स्वामी और क्लीनअप सीमा की आवश्यकता होती है; क्रॉस-लेयर विलोपन अप्रत्याशित इमेज या वॉल्यूम व्यवहार बना सकता है।

विफलता अभ्यास (Failure drills) और विकास

विफलता: केवल df -h देखना

Inode शून्य होने पर भी बाइट्स शेष रह सकते हैं। पहले-प्रतिक्रिया डायग्नोस्टिक्स में df -i को शामिल करें और माउंट द्वारा अलर्ट इतिहास रखें।

विफलता: सबसे बड़ी डायरेक्टरी पर rm -rf चलाना

इसमें कतारें, साक्ष्य या लिखी जा रही फ़ाइलें शामिल हो सकती हैं। स्वामित्व, प्रतिधारण, ओपन हैंडल और रोलबैक की पुष्टि करें, फिर सीमित बैचों में सफाई करें।

विफलता: रिकवर करने के बजाय रीस्टार्ट करना

एक रीस्टार्ट साक्ष्य को नष्ट करने और जनरेटर को छिपाने के साथ-साथ डिलीट-की-गई-खुली फ़ाइलों को अस्थायी रूप से रिलीज़ कर सकता है। स्वामी को सुरक्षित रूप से फ़ाइलों को बंद करने दें और अगले राइट को सत्यापित करें।

सामान्य गलतियां और फॉलो-अप

गलती: inode का उपयोग केवल फ़ाइल आकार से संबंधित है

Inode मुख्य रूप से फ़ाइल गणना और फ़ाइल सिस्टम प्रारूप द्वारा उपभोग किए जाते हैं; शून्य-बाइट और छोटी फ़ाइलें भी उनका उपभोग करती हैं।

फॉलो-अप: फ़ाइल हटाने से स्थान खाली क्यों नहीं हुआ?

प्रक्रिया अभी भी अपने फ़ाइल डिस्क्रिप्टर को बनाए रखती है। डायरेक्टरी प्रविष्टि चली गई है, लेकिन डिस्क्रिप्टर बंद होने तक ब्लॉक और inode आवंटित रहते हैं।

फॉलो-अप: आप कोटा में अंतर कैसे करते हैं?

फ़ाइल सिस्टम-व्यापी मेट्रिक्स की तुलना उपयोगकर्ता, प्रोजेक्ट और कंटेनर कोटा से करें, फिर उसी पाथ पर उसी पहचान के रूप में एक नियंत्रित निर्माण परीक्षण चलाएं।

फॉलो-अप: आप लॉग रोटेशन को कैसे मान्य करते हैं?

सत्यापित करें कि प्रक्रिया नई फ़ाइल खोलती है, पुराने हैंडल को बंद करती है, और फ़ाइल गणना और inode उपयोग बजट के भीतर आते हैं; केवल एक नया फ़ाइल नाम प्रमाण नहीं है।

फॉलो-अप: आप छोटी-फ़ाइलों के स्टॉर्म को कैसे रोकते हैं?

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

फॉलो-अप: विस्तार कब मदद नहीं करता है?

यदि inode घनत्व तय है और नया फ़ाइल सिस्टम समान inode डिज़ाइन प्रदान करता है, तो बाइट्स जोड़ने से inode की कमी का समाधान नहीं होता है। माइग्रेट करें, पुनर्निर्माण करें, या फ़ाइल ग्रैन्युलैरिटी बदलें।