फ़ाइल शेयर के लिए बड़े NTFS डिस्क आवंटन आकार का उपयोग करने से कोई फर्क पड़ता है?


9

मैं NTFS का उपयोग कर एक ड्राइव को प्रारूपित कर रहा हूं जो उपयोगकर्ताओं के लिए एक फाइल शेयर के रूप में समर्पित होगा जो उनकी फाइलों को केंद्र में रखता है। फ़ाइलें बड़ी (10 से 100 मेगाबाइट की) की संभावना होगी।

किसी ने सुझाव दिया कि डिफ़ॉल्ट 4k (जैसे 64k) की तुलना में बड़े आवंटन इकाई आकार का उपयोग करना बेहतर प्रदर्शन करेगा। मुझे लगता है कि मैं इसके पीछे मूल सिद्धांत को समझता हूं, लेकिन मुझे यकीन नहीं है कि अगर यह व्यवहार में वैध है। क्या इससे वास्तव में कोई फर्क पड़ेगा या यह कुछ ऐसा है जो इसे हल करने की तुलना में अधिक समस्याएं पैदा कर सकता है?

जवाबों:


9

बड़ी फ़ाइलों का उपयोग करते समय बड़ा आवंटन आकार प्रदर्शन बढ़ाएगा। यदि वे सभी बड़ी फाइलें बनने जा रहे हैं, तो यह आवंटन आकार को 32KB या 64KB तक बढ़ाने का भुगतान कर सकता है।

ध्यान रखें कि आवंटन इकाई का आकार जितना बड़ा होगा, डिस्क स्थान उतना ही अधिक व्यर्थ होगा। यह वॉल्यूम पर संग्रहीत फ़ाइलों के आकार की परवाह किए बिना सच है। यदि आवंटन इकाई का आकार 64K है और आप 50K फ़ाइल सहेजते हैं, तो 14K बर्बाद हो जाएगा। यदि आप 800K फ़ाइल सहेजते हैं, तो इसे 13 चंक्स में विभाजित किया जाएगा, लेकिन 13 वें चंक में केवल 32K डेटा होगा जिसके परिणामस्वरूप व्यर्थ डिस्क स्थान का 32K होगा।

NTFS ड्राइव के प्रदर्शन ट्यूनिंग के लिए एक संसाधन यहां पाया जा सकता है: http://www.windowsdevcenter.com/pub/a/windows/2005/02/08/NTFS_Hacks.html

सौभाग्य, किसी भी आगे के सवाल पूछने में संकोच नहीं करते।

लीमा


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

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

1
@ ट्विस्टी की टिप्पणी में जोड़ने के लिए: अपेक्षित बर्बाद स्थान = अपेक्षित # फ़ाइलों की # आवंटन इकाई का आकार / 2. इसलिए यदि मैं 64k (65,536 बाइट्स) का आवंटन इकाई आकार चुनता हूं, और मेरी फाइलें सभी बहुत बड़ी हैं, तो मेरे पास केवल 3,000 है, मैं 3,000 * 65,536 / 2 = 98,304,000 बाइट्स, या लगभग 98 एमबी बर्बाद करने की उम्मीद कर सकता हूं। इस कचरे को आंतरिक विखंडन (धन्यवाद, आवश्यक सीएस कक्षाएं) के रूप में जाना जाता है ।
जेक

5

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

बाहर देखने के लिए कुछ चीजें हैं:

  • फ़ाइलें अधिक स्थान ले लेंगी, इसलिए यदि आपके पास बहुत सारी छोटी फ़ाइलें हैं तो यह एक समस्या होगी
  • छोटी फ़ाइलों तक पहुँच धीमी हो सकती है क्योंकि सिस्टम एक बार में पूरे ब्लॉक पढ़ता है (इसलिए यदि आप 64Kb ब्लॉक का उपयोग करते हैं तो 1Kb फ़ाइल के लिए 64Kb पढ़ना), हालाँकि आपके ड्राइव के रीड-फॉरवर्ड व्यवहार के आधार पर यह ध्यान देने योग्य नहीं है।
  • आप पा सकते हैं कि यह वास्तव में प्रदर्शन को नुकसान पहुँचाता है जब एक्सेस पैटर्न बहुत यादृच्छिक होता है और / या नेटवर्क पर संसाधन तक पहुँचने वाली कई समवर्ती प्रक्रियाएँ होती हैं।

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


0

मुझे लगता है कि सामान्य विचार यह है कि डिस्क स्थान की कीमत पर बड़ा = बेहतर प्रदर्शन।

ऑनलाइन एक गड़गड़ाहट है कि डिफ़ॉल्ट आकार बदलने से त्रुटि या असफलता के लिए बुरी तरह से कोडित डिस्क उपयोगिताओं का कारण होगा, इसलिए यदि आप बैकअप के लिए योजना नहीं बनाने की योजना बनाते हैं, तो आप इसे ध्यान में रखना चाहते हैं; ;-)


1
मानक उपकरणों के साथ प्रदर्शन नहीं किया जा सकता है कि आपदा वसूली कार्यों में छोड़कर, गैर मानक डिस्क उपयोगिताओं से स्पष्ट रहें। बैकअप की योजना नहीं बनाने की योजना आपदा के लिए योजना बना रही है।
Thecarpy
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.