जवाबों:
फाइलसिस्टम को फ़ाइल आकार (या तो बाइट्स में, या कुछ फाइल सिस्टम पर निर्भर इकाई जैसे सेक्टर या ब्लॉक) को स्टोर करने की आवश्यकता होती है। आकार के लिए आवंटित बिट्स की संख्या आमतौर पर पत्थर में तय की जाती है जब फाइलसिस्टम डिज़ाइन किया जाता है।
यदि आप आकार के लिए बहुत अधिक बिट्स की अनुमति देते हैं, तो आप प्रत्येक फ़ाइल को थोड़ा और कमरा लेते हैं, और प्रत्येक ऑपरेशन थोड़ा धीमा होता है। दूसरी ओर, यदि आप आकार के लिए बहुत कम बिट्स की अनुमति देते हैं, तो एक दिन लोग शिकायत करेंगे क्योंकि वे एक 20EB फाइल को स्टोर करने की कोशिश कर रहे हैं और आपका बकवास फाइल सिस्टम उन्हें नहीं होने देगा।
जिस समय आपके द्वारा उल्लेखित फाइलसिस्टम का डिज़ाइन किया गया था, उस समय एक डिस्क बड़ी होने के कारण विज्ञान-कथा की तरह लग रही थी। (FAT32 को छोड़कर, लेकिन इसे बढ़ावा देने वाली कंपनी ने इसे एक मध्यवर्ती उपाय के रूप में लक्षित किया, इससे पहले कि हर कोई अपने चमकदार नए NTFS को अपनाए, साथ ही वे बढ़ती आवश्यकताओं की आशा में कभी भी बहुत अच्छे नहीं थे।)
एक और बात यह है कि पिछली शताब्दी के अंत तक, अधिकांश उपभोक्ता (और यहां तक कि सर्वर) हार्डवेयर केवल 32-बिट मानों के साथ तेजी से संगणना को समायोजित कर सकते थे, और ऑपरेटिंग सिस्टम फ़ाइल आकार सहित अधिकांश चीजों के लिए 32-बिट मानों का उपयोग करने के लिए रुझान था। 32 बिट्स का मतलब 4GB है, इसलिए ऑपरेटिंग सिस्टम को फाइल सिस्टम की परवाह किए बिना 4GB फ़ाइलों तक सीमित किया जाता है, अक्सर 2GB भी क्योंकि वे हस्ताक्षर किए गए पूर्णांक का उपयोग करते हैं। कोई भी गंभीर डेस्कटॉप या सर्वर OS आजकल फ़ाइल साइज़ और ऑफ़सेट के लिए 64 बिट्स का उपयोग करता है, जो 8EB की सीमा रखता है।
ऑन-डिस्क डेटा संरचनाएं आमतौर पर सीमा होती हैं। अनुसंधान करें कि ये ऑपरेटिंग सिस्टम उनके डिस्क को कैसे प्रारूपित करते हैं और वे डिस्क पर फ़ाइलों के भाग को कैसे ट्रैक करते हैं, और आप समझेंगे कि उनकी ये सीमाएँ क्यों हैं। एफएटी फाइल सिस्टम बहुत अच्छी तरह से ऑन-लाइन प्रलेखित है ( उदाहरण के लिए विकिपीडिया देखें ), और आप देख सकते हैं कि कुछ डिस्क संरचना फ़ील्ड के लिए पूर्णांक आकार की उनकी पसंद फ़ाइल के समग्र आकार को सीमित करती है जिसे आप इस डिस्क प्रारूप के साथ स्टोर कर सकते हैं।
सीमा केवल इस तथ्य के कारण है कि जब फाइलिंग सिस्टम के विनिर्देशों को लिखा गया था, तो यह कभी नहीं सोचा गया था कि हार्ड ड्राइव बहुत बड़ी होगी .... या अन्य तकनीकी सीमाएँ विनिर्देशों को डिज़ाइन करते हुए।
मुझे लगता है कि आजकल, नए फाइलिंग सिस्टम में सीमाएं आम तौर पर उस ओर जाती हैं जो अपेक्षित उपयोग होगा।
... किसी भी तकनीकी टीम के लिए फाइलिंग सिस्टम को जारी करना कठिन होगा और यह कहेगा कि यह उस पर परीक्षण किए बिना 500 पेटाबाइट हार्ड ड्राइव का समर्थन करता है।
मेरा पहला लैपटॉप एक 40 एमबी हार्ड ड्राइव के साथ 286 था ... मैं उस समय कभी भी एफएटी की आवश्यकता (या सीमा को मारने) की कल्पना नहीं करता था!
मुझे लगता है कि वर्तमान NTFS सीमा 16TB प्रति वॉल्यूम, प्रति फ़ाइल 2TB के आसपास है ... काफी स्पष्ट रूप से, (और) कुछ समय के लिए अच्छा है - 2TBs से बड़ी फ़ाइलों को लिखने में सक्षम (या ज़रूरत) कुछ भी करने की क्षमता आमतौर पर होती है विभाजन फ़ाइलें और / या इसी तरह की प्रशासनिक सुविधाएँ (जैसे SQL सर्वर)।
सरल उत्तर: आपको फ़ाइल को पढ़ने में सक्षम होना चाहिए, इसलिए आपको फ़ाइल को संबोधित करने में सक्षम होना चाहिए। यह पहुंच उन सीमांत संरचनाओं के माध्यम से होगी जिनकी सीमाएँ हैं। आप सबसे कम आम भाजक के साथ फंस जाएंगे; भौतिक (डिस्क, एसडी कार्ड, आदि) सीमाएँ, फ़ाइल सिस्टम सीमाएँ, और OS सीमाएँ।
हर फ़ाइल का आकार जानना केवल एक सरलीकरण है जिसका हमने उपयोग किया है। यह इस तरह से नहीं होता है और हमेशा ऐसा नहीं होता है।
पुराने मेनफ्रेम कभी भी नए नहीं थे कि टेप फाइल कितनी बड़ी थी, जब तक कि यह इसके अंत तक नहीं पढ़ा था (और तब भी यह आकार का ट्रैक नहीं रख सकता था)। यहां तक कि डिस्क फ़ाइलों को अक्सर क्रमिक रूप से एक्सेस किया जाता था और जैसे ही उन्हें बढ़ाया जाता था, वैसे ही बढ़ता जाता था। उनके आकार (बाइट्स में) दर्ज नहीं किए गए थे और सामान्य तौर पर, उन्हें परिवर्तनशील क्षेत्र के आकार और अन्य विषम विशेषताओं के कारण पूर्ण रूप से पढ़े बिना गणना नहीं की जा सकती थी।
फ़ाइल-सिस्टम को डिज़ाइन करना मुश्किल नहीं होगा, जो फ़ाइल आकार का ट्रैक नहीं रखता और उन्हें अनबाउंड बढ़ने की अनुमति देता है।
