FAT16 2 जीबी से अधिक स्टोर क्यों नहीं कर सकता है?


25

सभी साइटें जो मैं FAT16 पर informations के लिए देखने जा रहा हूं, केवल घोषित रूप से यह बताता है कि यह 2 GB से अधिक आवंटित नहीं कर सकता है। ठीक है। महान। मुझे तुम पर विश्वास है। लेकिन आप उस निष्कर्ष पर कैसे आते हैं (केवल इसे परीक्षण करने के अलावा)?

क्या किसी प्रकार का सूत्र यह निर्धारित करने के लिए उपयोग कर सकता है कि एक FAT16 सिस्टम कितना पकड़ सकता है?


21
FAT16 के नाम में "16" होने का एक कारण है। :-)
एरिक लिपर्ट

28
@ EricLippert, निष्पक्ष होने के लिए, उस 16 और 2 GiB के बीच संबंध तुरंत स्पष्ट नहीं है कि एफएस कैसे काम करता है।
जॉय

18
मैं 100% आश्वस्त नहीं हूं कि यह प्रश्न वास्तव में इस साइट के लिए विषय है। शायद इसे retrocomputing.stackexchange.com पर ले जाना चाहिए?
जूल्स

3
यह ध्यान देने योग्य है कि 2GB की सीमा MS-DOS और प्रारंभिक Windows FAT16 को कैसे नियंत्रित करती है, इसका एक व्यावहारिक सीमा थी। यह वैचारिक रूप से 2GB से अधिक संभव है, लेकिन Microsoft-संगत तरीके से नहीं।
phyrfox 16

3
@ LưuV LnhPhúc टिप्पणी सही है। मैंने कहा "एमएस-डॉस और शुरुआती विंडोज।" आधुनिक सिस्टम FAT16 में 2GB से अधिक का उपयोग कर सकते हैं। एक 4GB FAT16 विभाजन पुराने MS-DOS / Win3.1 सिस्टम में काम नहीं करेगा, उदाहरण के लिए। और कई स्रोतों ने कहा कि 2GB सीमा थी या तो क्योंकि वे लिखे गए थे जब वह सीमा एक वास्तविकता थी, या कुछ ही समय बाद, जहां आपको सलाह दी गई थी क्योंकि थोड़ा पुराने सिस्टम इसे संभाल नहीं सकते थे। बाद में सिस्टम इसे ठीक से संभाल सकता है, लेकिन 2GB की सीमा के बारे में 2000 या उससे पहले अंगूठे का नियम था, और अगले कुछ वर्षों के बाद पुरानी, ​​पुरानी सीमाओं का हवाला देते हुए।
फेयरफॉक्स

जवाबों:


66

FAT16 क्लस्टर की पहचान करने के लिए 16 बिट्स का उपयोग करता है। इस प्रकार आपके पहचानकर्ताओं के बाहर चलाने से पहले अधिकतम 65536 क्लस्टर हैं, और कुछ पहचानकर्ता गैर-फ़ाइल उपयोगों के लिए आरक्षित हैं। प्रत्येक फ़ाइल कम से कम एक क्लस्टर में रहती है। बड़ी क्लस्टर प्रति फ़ाइल न्यूनतम आवंटन बढ़ाता है, छोटी फ़ाइलों के ओवरहेड को बढ़ाता है।

क्लस्टर आकार तब आपको अधिकतम पहचान योग्य मात्रा बताता है। 32KiB क्लस्टर के लिए, यह 32 * 1024 * 65536 B = 2GiB है।

आप अपने ऑन-डिस्क सेक्टरों के आकार को बढ़ाकर क्लस्टर आकार को अनिश्चित काल तक बढ़ा सकते हैं , लेकिन आप अधिकतम फ़ाइलों तक सीमित रहते हैं। आप डिफ़ॉल्ट सेक्टर आकार (512B) मानने वाले सॉफ़्टवेयर के साथ समस्याओं में भी भाग लेंगे

इस बिंदु पर जहां आसानी से उपलब्ध होने वाले ~ 2GiB के भौतिक वॉल्यूम थे, प्रोसेसर और ओएस 32 बिट थे, इसलिए FAT32 में जाना एक समझदार विकल्प था, जो छोटे समूहों में बहुत अधिक फ़ाइलों की अनुमति देता है


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

3
स्पष्ट नोटों के एक जोड़े: 32KiB डॉस और विंडोज के विभिन्न संस्करणों के लिए अधिकतम क्लस्टर आकार था, लेकिन Windows NT परिवार ने NT 4.0 से बड़े क्लस्टर आकार का समर्थन किया है (और इसलिए XP के बाद से Windows के उपभोक्ता संस्करणों ने भी इसका समर्थन किया है, क्योंकि वे ' एनटी कर्नेल पर आधारित)। यह 16GiB तक के आकार की अनुमति देता है, हालांकि उत्तर में वर्णित अक्षमता के कारण यह उपयोगी होने की संभावना नहीं है। आप सकता है अनुग्राह्यतापूर्वक एक ऐसी प्रणाली है, तो आप मुख्य रूप से बड़ी फ़ाइलों को स्टोर करने के लिए उसका उपयोग, खासकर अगर वे 256KiB क्लस्टर आकार के गुणकों में आया था आप का उपयोग करना होगा ...
जूल्स

5
... लेकिन फिर आपको अगली सीमा पर पहुंचने की संभावना होगी, जो कि FAT16 और FAT32 दोनों के लिए एक समस्या है: अधिकतम फ़ाइल आकार इस तथ्य से 4GiB के 1 बाइट तक सीमित है कि इसमें स्टोर करने के लिए केवल 4 बाइट आवंटित हैं निर्देशिका प्रविष्टियों। OTOH, अगर आपको पावर-ऑफ-टू साइज़ के साथ लगभग 256KiB के 2GiB तक के साइज़ में बड़ी-ish फाइलों को स्टोर करने की आवश्यकता होती है, और कुल साइज़ <16GiB, FAT16 उनके लिए संभवतः सबसे कुशल फॉर्मेट है।
जूल्स

@ जूल्स: केवल संभावित। याद रखें कि प्रति-क्लस्टर-ओवरहेड है। फ़ाइल-सिस्टम रनिंग की अनुमति देता है अगर थोड़ा विखंडन होता है तो अधिक कुशल होते हैं।
Deduplicator

12

विभिन्न सीमाओं के साथ वर्षों में "FAT16" के कई संस्करण थे, लेकिन विंडोज़ 95 के माध्यम से "कॉम्पैक डीओएस 3.31" से बने संस्करण पर विचार करने देता है।

वसा संस्करणों को समूहों में विभाजित किया गया है। प्रत्येक क्लस्टर दो संख्या वाले क्षेत्रों की शक्ति से बना है। FAT16 पर प्रति क्लस्टर क्षेत्रों की संख्या को 8 बिट हस्ताक्षरित संख्या के रूप में संग्रहीत किया जाता है। तो प्रति क्लस्टर अधिकतम संभव सेक्टर 64 है।

क्लस्टर संख्या को 16 बिट अहस्ताक्षरित मान के रूप में संग्रहीत किया गया था। कुल समूहों को 65536 तक सीमित करना। अधिकतम समूहों द्वारा प्रति क्लस्टर गुणा करें और आपको 4194304 सेक्टरों की सीमा मिलती है।

हार्ड ड्राइव का (तार्किक) सेक्टर आकार 512 बाइट्स है। ऊपर उल्लिखित सेक्टरों की संख्या को सीमा से गुणा करें और आप अपनी 2GiB की सीमा प्राप्त करें। Priciple में बड़े क्षेत्र के आकार के साथ एक माध्यम एक बड़े FAT16 वॉल्यूम का समर्थन कर सकता है, लेकिन मुझे नहीं लगता कि व्यवहार में ऐसा हुआ है।

विंडोज NT ने "सेक्टर प्रति क्लस्टर" फ़ील्ड की व्याख्या को 8 बिट अहस्ताक्षरित कर दिया। इसने 512 बाइट सेक्टरों के साथ 4GIB FAT16 विभाजन की अनुमति दी (और सैद्धांतिक रूप से बड़े क्षेत्रों के साथ ड्राइव पर बड़ा)। AIUI विंडोज़ 98 ने इस तरह के विभाजन को पढ़ने और लिखने के लिए समर्थन जोड़ा, लेकिन यह उन्हें नहीं बना सका और यह डिस्क उपयोगिताओं की मरम्मत नहीं कर सका।


यह निश्चित रूप से बड़े समूहों और इसलिए बड़े संस्करणों का समर्थन करने के लिए फाइलसिस्टम प्रारूप में अपेक्षाकृत मामूली बदलाव करना संभव होगा। हालाँकि, MS ने FAT32 का निर्माण करने वाले विंडोज़ 95 OSR2 के साथ 32-बिट क्लस्टर इंडेक्स में जाने के अधिक कट्टरपंथी विकल्प के लिए जाने का फैसला किया।

मैं अधिक कट्टरपंथी विकल्प के लिए जाने का कारण अंतरिक्ष दक्षता था। 32kiB क्लस्टर्स पहले से ही बहुत बेकार हैं और उस समय भी बड़ी चाल होती थी।


4
मुझे "अधिकतम संभव सेक्टर प्रति क्लस्टर 64 है" पर कठिन सोचना पड़ा, जब तक कि मुझे यह नहीं मिल गया: 64 वास्तव में सबसे बड़ा पावर ऑफ़ है -2 आप एक हस्ताक्षरित बाइट में प्रतिनिधित्व कर सकते हैं: 128 अधिकतम सकारात्मक हस्ताक्षरित के रूप में संभव नहीं है बाइट का मूल्य 127 है।
राल्फ क्लेरहॉफ

3
@RalfKleberhoff जो स्वाभाविक रूप से एक फॉलोअप प्रश्न का कारण बनता है, हालांकि: यदि आप दो की शक्ति का भंडारण कर रहे हैं, तो दो पर घातांक की बजाय संख्या को ही क्यों स्टोर करें?
डैनियल वैगनर

@DanielWagner मैं बिल्कुल सहमत हूँ। विशेष रूप से वापस तब जब FAT16 बनाया गया था, स्थानांतरण निश्चित रूप से गुणा करने की तुलना में एक सस्ता ऑपरेशन था। लेकिन शायद वे इसे चलाने के लिए खुश थे, और भविष्य में दशकों तक सॉफ्टवेयर-इंजीनियरिंग नहीं ...
राल्फ क्लेबॉर्फ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.