"इनोड आकार" और "बाइट्स प्रति इनोड" के बीच क्या अंतर है


18

नीचे दी गई जानकारी मैन पेज से ली गई है, मैं बाइट्स-प्रति-इनकोड और इनोड-आकार के बीच अंतर जानना चाहूंगा?

-i bytes-per-inode

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

-I inode-size

प्रत्येक inode का आकार निर्दिष्ट करें bytes.mke2fs डिफ़ॉल्ट रूप से 256-बाइट इनकोड बनाता है। 2.6.10 के बाद कर्नेल में और कुछ पहले के विक्रेता कर्नेल में बेहतर प्रदर्शन के लिए विस्तारित विशेषताओं को संग्रहीत करने के लिए 128 बाइट्स से बड़े इनोड का उपयोग करना संभव है। इनोड के आकार का मान 2 बड़ा या 128 के बराबर होना चाहिए। बड़ा इनोड -अधिक स्थान पर इनोड टेबल का उपभोग करेंगे, और यह फाइलसिस्टम में प्रयोग करने योग्य स्थान को कम कर देता है और प्रदर्शन को भी नकारात्मक रूप से प्रभावित कर सकता है। बड़े इनोड में संचित गुण पुरानी गुठली के साथ दिखाई नहीं देते हैं, और ऐसे फाइल सिस्टम 2.4 केर्नल्स के साथ माउंटेबल नहीं होंगे। बिल्कुल भी। फ़ाइल सिस्टम बनने के बाद इस मान को बदलना संभव नहीं है।

जवाबों:


13

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

-आई बाइट्स-प्रति-आयोड (उर्फ इनोड_रैटो)

किसी अज्ञात कारण से यह पैरामीटर कुछ समय बाइट्स-प्रति- इनोड के रूप में और कुछ समय इनोड_र अनुपात के रूप में प्रलेखित है । प्रलेखन के अनुसार, यह बाइट्स / इनोड अनुपात है । अधिकांश मानव को तब और भी अच्छी समझ होगी जब उन्हें (मेरी अंग्रेजी को माफ करना) कहा जाता है:

  • भंडारण के हर X बाइट्स के लिए 1 इनकोड (जहां X बाइट्स-प्रति-इनोड है)।
  • सबसे कम औसत-फ़ाइल आप फिट कर सकते हैं।

सूत्र ( mke2fs स्रोत कोड से लिया गया ):

inode_count = (blocks_count * blocksize) / inode_ratio

या यहां तक ​​कि सरलीकृत ("विभाजन का आकार" मानते हुए लगभग बराबर है blocks_count * blocksize, मैंने आवंटन की जांच नहीं की है):

inode_count = (partition_size_in_bytes) / inode_ratio

नोट 1: यहां तक ​​कि अगर आप एफएस निर्माण समय ( mkfs -N ...) में एक निश्चित संख्या में इनोड प्रदान करते हैं , तो मान एक अनुपात में बदल जाता है, इसलिए आप फाइल सिस्टम के आकार का विस्तार करते हुए अधिक इनोड फिट कर सकते हैं।

नोट 2: यदि आप इस अनुपात को ट्यून करते हैं, तो सुनिश्चित करें कि आपके द्वारा उपयोग की जाने वाली योजना की तुलना में काफी अधिक इनकोड आवंटित करना है ... आप वास्तव में अपने फाइल सिस्टम को सुधारना नहीं चाहते हैं।

-मैं अंदर-आकार

यह उस बाइट की संख्या है जो फाइल सिस्टम को इनकोड के लिए आवंटित / आरक्षित करेगा। अंतरिक्ष का उपयोग इनोड की विशेषताओं को संग्रहीत करने के लिए किया जाता है ( इन्ट्रो इनोड्स पढ़ें )। Ext3 में, डिफ़ॉल्ट आकार 128 था। Ext4 में, डिफ़ॉल्ट आकार 256 है ( extra_isizeइनलाइन विस्तारित-विशेषताओं के लिए स्थान संग्रहीत और प्रदान करने के लिए)। लिनक्स पढ़ें : इनकोड का आकार क्यों बदलें?

नोट: प्रत्येक आवंटित इनोडेक के लिए एक्सजाइटस्पेस का एक्स बाइट्स आवंटित किया गया है, चाहे वह स्वतंत्र हो या इस्तेमाल किया गया हो, जहां एक्स = इनोड आकार।


5

बाइट्स-प्रति-इनोड निर्धारित करता है कि फ़ाइल सिस्टम के लिए कितने इनोड बनाए गए हैं; इनोड का आकार यह निर्धारित करता है कि प्रत्येक इनोड कितना बड़ा है।

यदि आप फ़ाइलों पर बहुत सी छोटी फ़ाइलों (और / या बहुत सारी निर्देशिकाओं) को रखने का इरादा रखते हैं, तो आपको बहुत सारे इनकोड की आवश्यकता होती है।

AFAIK, आपको वास्तव में केवल इन बाइट्स की आवश्यकता होती है जो 256 बाइट्स के डिफ़ॉल्ट आकार से बड़े होते हैं यदि आप अपनी फ़ाइलों के लिए विस्तारित विशेषताओं को संग्रहीत करना चाहते हैं । मानुषी टिप्पणियों में कहती हैं कि यह सही नहीं है।


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

1

अत्यधिक रफ फाइलसिस्टम योजनाबद्ध:

|_|__inodes__|_______________________DATA_________________________________|
  • इनडेटा अनुपात / बाइट्स-प्रति-इनोड = डेटा क्षेत्र के लिए इनोड्स की मात्रा
  • इनोड का आकार = इनोड्स क्षेत्र में प्रत्येक इनोड का आकार

0

मुझे वास्तव में साजाओं का उत्तर पसंद आया, यह अंतर का सार देता है।

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

व्यक्ति / वस्तुएं: - भंडारण उपकरणों में डेटा की मात्रा (ओं) - मात्रा में फाइलें (भंडारण) - भंडारण उपकरण, वे स्वरूपित होते हैं और बाइट्स और उनके पते के ब्लॉक प्रदान करते हैं - भंडारण में फ़ाइलों के स्थान

कार्य: स्टोरेज में ऑपरेटिंग सिस्टम द्वारा फाइल और फोल्डर को बनाना / हटाना / हटाना, फाइल रीड / राइट / मूव्स, चेंज ऑफ चेंजेस आदि।

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

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

प्रश्न में दो सेटिंग्स बदलने के प्रभाव:

चेंजिन इनोड-आकार - आमतौर पर बदलने की आवश्यकता नहीं होती है, डिफ़ॉल्ट के साथ छड़ी होती है (एक चर्चा में पिछले उत्तर में पोस्ट किए गए लिंक के अनुसार)

बाइट्स-प्रति-इनोड - उन फ़ाइलों की अधिकतम संख्या को प्रभावित करता है जो संभवतः वॉल्यूम में बना सकते हैं (संभवतः अप्रयुक्त बाइट्स का प्रदर्शन और "अपव्यय")

पेपर रोल सादृश्य के लिए वापस जाना: ऐसी प्रणाली (या विभिन्न आकार के कई दस्तावेज़) में विशेष आकार (एक फ़ाइल) के एक दस्तावेज़ को लिखने और संग्रहीत करने की कल्पना करें - यदि पृष्ठ का आकार, जो "लेखन और भंडारण प्रणाली के दौरान निर्धारित है "परिभाषा और लचीली नहीं है, बहुत ही दस्तावेज़ को कई पृष्ठों की आवश्यकता हो सकती है, यदि" सिस्टम "पृष्ठ का आकार बहुत बड़ा है और दस्तावेज़ का आकार छोटा है, तो बहुत सारे कागज संभवतः रिक्त हो सकते हैं और एक पृष्ठ में छोटी फ़ाइलों को फिटिंग कर सकते हैं। यदि पृष्ठ का आकार बड़ा है - ऐसे कम पृष्ठ हैं जिनका उपयोग दस्तावेज़ के लिए करने की आवश्यकता है, लेकिन उपयोग किए गए अंतिम पृष्ठ में बहुत सारे "व्यर्थ खाली स्थान" हो सकते हैं। तो यह सब निर्भर करता है ... उन फ़ाइलों के आकार पर जिनका उपयोग किया जाएगा और कितने। अन्य विचार कई पृष्ठों के दस्तावेज़ को खोजने और लाने की गति है।

आशा है कि यह समझ में आता है (यह मेरे लिए करता है) और कृपया टिप्पणी करें कि क्या मैंने ext design या mkfs विकल्पों के किसी भी भाग का गंभीरता से दुरुपयोग किया है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.