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


जैसा कि आप नीचे देख सकते हैं, के बीच बहुत अंतर है आकार तथा डिस्क का माप मेरे फ़ोल्डर में फ़ील्ड। ऐसा क्यों है?

Screenshot showing 50,875 files in 1,504 folders, 105 MB being 1.43 GB on disk

मुझे पता है कि डिस्क का माप से थोड़ा अधिक होना चाहिए आकार विंडोज़ में आवंटन इकाइयों की वजह से, लेकिन इतना अंतर क्यों? क्या यह बड़ी संख्या में फाइलों के कारण हो सकता है?

बीटीडब्ल्यू, यह फ़ोल्डर मेरे एंड्रॉइड फोन के एसडी कार्ड पर है। इसके अंदर, मेरे मानचित्र ऐप अपने कैश किए गए मानचित्र संग्रहीत करता है और ऐप को Google मानचित्र से अपना नक्शा मिलता है।


297
2018-01-20 09:48


मूल


हैलो thelastblack, और SuperUser में आपका स्वागत है। मैंने डीफ्रैग्मेंटिंग के बारे में हिस्से को हटाने के लिए अपना प्रश्न संपादित किया है, क्योंकि दो मौजूदा उत्तर डिस्क विसंगति पर आकार / आकार पर ध्यान केंद्रित करते हैं और स्टैक एक्सचेंज प्रारूप सबसे अच्छा काम करता है जब प्रत्येक प्रश्न पोस्ट किया जाता है। हालांकि, आप निश्चित रूप से एक अलग प्रश्न के रूप में फिर से पूछ सकते हैं, हालांकि मुझे लगता है कि इस प्रश्न पर अब तक आपके द्वारा प्राप्त उत्तरों से पता चलता है कि डीफ्रैग्मेंटेशन आपकी मदद नहीं करेगा। (यह आमतौर पर ठोस-राज्य मीडिया पर अच्छा नहीं है।) मुफ्त में महसूस करें संपादित करें आपका प्रश्न आगे अगर आपको लगता है कि मैंने अपना इरादा किसी भी तरह से बदल दिया है। - α CVn
@ माइकल Kjörling हे, मैं सिर्फ विखंडन पर एक मामूली चर्चा में संपादित (थोड़ा पहले विचलित हो गया) - Bob
@ MichaelKjörling नहीं उत्तर फिट करने के लिए प्रश्नों को पीछे से संपादित करें। उत्तर में से एक ओपी के प्रश्न के विखंडन भाग को संबोधित करता है। भ्रम से बचने के लिए आपके संपादन को वापस लुढ़का जाना चाहिए। - DanteTheEgregore
@DanteTheEgregore यदि आप बॉब के उत्तर का जिक्र कर रहे हैं, जिसे वास्तव में विखंडन के प्रभावों पर चर्चा करने के लिए संपादित किया गया है, तो बंदूक कूदने से पहले, कृपया उस उत्तर और प्रश्न पर संपादन इतिहास और टाइमस्टैम्प देखें। मेरे संपादन के समय, बॉब के जवाब में विखंडन के मुद्दे को शामिल नहीं किया गया था। यदि ओपी ऐसा करना चाहता है, तो "मीडिया को डिफ्रैगमेंट करने से मुझे इसमें मदद मिलेगी?" किसी भी उत्कृष्ट भ्रम को हल करना चाहिए, हालांकि मुझे अभी भी लगता है जिसे एक अलग सवाल के रूप में बेहतर कहा जाता है; आईएमओ दो मूल्यों के बीच अंतर का मामला असंबंधित है। - α CVn
मुझे लगता है कि इस ऐप की गंभीरता से प्रोग्रामिंग की गई है - एक बग रिपोर्ट दर्ज करने पर विचार करें। मैं किसी भी पेशेवर प्रोग्रामर से नहीं हूं, लेकिन मैंने एक बार जावाएमई में एक जैसे कुछ हैक किया है, और निश्चित रूप से मुझे हल करने वाली समस्याओं में से एक यह था कि उन सभी छोटे नक्शा टाइल्स को कंटेनर में कुशलतापूर्वक (स्टोरेज और एक्सेस) को कैसे स्टोर किया जाए। मैं असंपीड़ित ज़िप फ़ाइलों का उपयोग कर समाप्त हो गया। - A. Donda


जवाब:


मैं मानता हूं कि आप यहां एफएटी / एफएटी 32 फाइल सिस्टम का उपयोग कर रहे हैं, क्योंकि आप इसका उल्लेख करते हैं कि यह एक एसडी कार्ड है। एनटीएफएस और एक्सएफएटी आवंटन इकाइयों के संबंध में समान व्यवहार करते हैं। अन्य फाइल सिस्टम अलग-अलग हो सकते हैं, लेकिन वे विंडोज़ पर भी समर्थित नहीं हैं।

यदि आपके पास बहुत सी छोटी फाइलें हैं, तो यह निश्चित रूप से संभव है। इस पर विचार करो:

  • 50,000 फाइलें

  • 32 केबी क्लस्टर आकार (आवंटन इकाइयां), जो कि FAT32 के लिए अधिकतम है

ठीक है, अब न्यूनतम ली गई जगह 50,000 * 32,000 = 1.6 जीबी (गणित को सरल बनाने के लिए बाइनरी नहीं, एसआई उपसर्ग का उपयोग कर रही है)। प्रत्येक फाइल डिस्क पर ले जाने वाली जगह हमेशा आवंटन इकाई आकार का एक बहु होता है - और यहां हम मानते हैं कि प्रत्येक फ़ाइल वास्तव में एक इकाई के भीतर फिट होने के लिए काफी छोटा है, कुछ (बर्बाद) स्थान शेष है।

यदि प्रत्येक फ़ाइल का औसत 2 केबी होता है, तो आपको लगभग 100 एमबी कुल मिल जाएगा - लेकिन आवंटन इकाई आकार के कारण आप औसतन 15x बर्बाद कर रहे हैं (प्रति फ़ाइल 30 केबी)।


गहराई से स्पष्टीकरण

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

तो क्या होता है यदि आपके पास बहुत छोटी फ़ाइल है? खैर, फाइल सिस्टम 0 केबी, 2 केबी या यहां तक ​​कि 15 केबी है, तो फाइल सिस्टम को परवाह नहीं है, यह इसे कम से कम स्थान दे सकता है - ऊपर दिए गए उदाहरण में, यह 32 केबी है। आपकी फ़ाइल केवल इस स्पेस की एक छोटी राशि का उपयोग कर रही है, और बाकी मूल रूप से बर्बाद हो गई है, लेकिन फिर भी फ़ाइल से संबंधित है - एक शयनकक्ष की तरह आप अनचाहे छोड़ देते हैं।

अलग आवंटन इकाई आकार क्यों हैं? खैर, यह एक बड़ी मेज (एड्रेस बुक, उदाहरण के लिए कह रहा है कि जॉन के पास 123 नकली स्ट्रीट, 124 नकली स्ट्रीट, 666 शैतान लेन, आदि) में एक घर है, या प्रत्येक यूनिट (घर) में अधिक बर्बाद जगह है। यदि आपके पास बड़ी फाइलें हैं, तो यह बड़ी आवंटन इकाइयों का उपयोग करने के लिए अधिक समझ में आता है - क्योंकि फ़ाइल को एक नई इकाई (घर) नहीं मिलती है जब तक कि सभी अन्य भरे नहीं जाते हैं। यदि आपके पास बहुत सी छोटी फाइलें हैं, तो, आपके पास एक बड़ी टेबल (एड्रेस बुक) होगी, वैसे भी उन्हें छोटी इकाइयां (घर) भी मिल सकती हैं।

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


विखंडन?

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


संभव समाधान

जैसा gladiator2345 सुझाव दिया, इस बिंदु पर आपके एकमात्र वास्तविक विकल्प इसके साथ रहना या छोटे आवंटन इकाइयों के साथ सुधार करना है।

आपका कार्ड एफएटी 16 में स्वरूपित किया जा सकता है, जिसमें टेबल आकार पर एक छोटी सी सीमा है और इसलिए बड़ी मात्रा में पता लगाने के लिए बहुत बड़ी आवंटन इकाइयों की आवश्यकता होती है (32 केबी आवंटन इकाइयों के साथ 2 जीबी की ऊपरी सीमा के साथ)। स्रोत के सौजन्य से Braiam। यदि ऐसा है, तो आप किसी भी तरह से FAT32 के रूप में सुरक्षित रूप से प्रारूपित करने में सक्षम होना चाहिए।


300
2018-01-20 09:54



न्यूनतम आवंटन आकारों के कारण बर्बाद जगह वास्तव में तकनीकी रूप से "आंतरिक विखंडन" कहा जाता है, इसलिए आप सकता है कहते हैं कि विखंडन अपराधी है। लेकिन यह अभी भी कुछ नहीं है कि किसी भी "defragment" उपकरण के बारे में कुछ भी कर सकते हैं। - hobbs
(कम तकनीकी रूप से, इसे सिर्फ "ढीला" कहा जाता है।) - hobbs
क्लस्टर आकार अधिकतम फ़ाइल सिस्टम आकार को भी सीमित करते हैं। उदाहरण के लिए, यदि आपका पता स्थान 32-बिट है, तो आपके पास कुल ~ 4.2 9 बिलियन कुल क्लस्टर हैं। अब, यदि आप एनटीएफएस (512 बाइट्स) द्वारा समर्थित सबसे छोटे क्लस्टर आकार का उपयोग करते हैं, तो आप अधिकतम 512 * 2 ^ 32 बाइट्स = 2 जीआईबी को संबोधित कर सकते हैं। यदि आपको एक वॉल्यूम की आवश्यकता है जो 2 जीबी डेटा से अधिक स्टोर कर सकता है, तो आपको क्लस्टर आकार में वृद्धि करना होगा। यह उन सभी वास्तविकतम फ़ाइल से स्वतंत्र है जिन्हें आप स्टोर करने का प्रयास करते हैं, बशर्ते आप 2 जीबी से बड़ी फ़ाइल को स्टोर न करें जो आपकी समस्याओं में से कम से कम है। - Andon M. Coleman
4 कीबी क्लस्टर आपको वॉल्यूम में 16 टीआईबी तक की मात्रा में फाइलों को संबोधित करने की अनुमति देंगे, जो निकट भविष्य के लिए पर्याप्त होना चाहिए। - Andon M. Coleman
खैर, वह छोटी फाइलों के अपने संग्रह को एक बड़ी फाइल में संपीड़ित कर सकता था। - einpoklum


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

इसके अंदर, मेरे मानचित्र ऐप अपने कैश किए गए मानचित्र संग्रहीत करता है और ऐप को Google मानचित्र से अपना नक्शा मिलता है

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


46
2018-01-20 15:03



> इसके अंदर, मेरे मानचित्र ऐप अपने कैश किए गए मानचित्र संग्रहीत करता है और ऐप को Google मानचित्र से अपना नक्शा मिलता है। दुर्भाग्यवश, इस मामले में, संपीड़न (जो मूल आधार से प्रभावी रूप से एक फ़ाइल सिस्टम है) को इस मैपिंग ऐप से समर्थन की आवश्यकता होगी। - Bob
@ बॉब तो समाधान डेवलपर पक्ष डी से आता है डी: - Braiam
यह पूरी तरह से सच है। मुझे लगता है कि समय के लिए, मुझे अपना ऐप बदलना चाहिए। - vfsoraki
@ ब्रायम यह फ़ाइल सिस्टम को यह सोचने में नहीं लगा रहा है कि केवल एक फ़ाइल है; क्या आप वहां मौजूद हैं है केवल एक फाइल क्यों डेवलपर्स कैश की जानकारी को संग्रह में संग्रहीत नहीं करते हैं, ऐसा शायद इसलिए है क्योंकि अधिकांश संग्रह प्रारूपों को तेज़ यादृच्छिक लेखन के लिए डिज़ाइन नहीं किया गया है, जिसे कैश को निश्चित रूप से चाहिए। SQLite जैसे लाइटवेट डेटाबेस लाइब्रेरी का उपयोग करने के लिए एक बेहतर विकल्प हो सकता है। - bcrist
बिल्कुल सच ..... +1 - arundevma


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

यह केवल मेरे ज्ञान के लिए एनटीएफएस पर लागू होता है। एडीएस वैध और वैध दोनों प्रयोगों के लिए जाने जाते हैं:

  • इंटरनेट से डाउनलोड की गई फ़ाइल को टैग करने के लिए
  • मेटाडेटा को स्टोर करने के लिए (माइक्रोसॉफ्ट कुछ ऐप्पल ओएस फीचर को शामिल करना चाहता था, जैसे फ़ाइल के प्रकार को निर्धारित करने के लिए फ़ाइल एक्सटेंशन का उपयोग नहीं करना)
  • मैलवेयर के संदर्भ में डेटा या कोड छिपाने के लिए

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

मुख्य बिंदु यह है कि बड़े फ़ाइल आकार के अंतर के मामले में, एडीएस, और छुपा मैलवेयर की संभावना को नजरअंदाज न करें।

एक और लिंक

एडीएस के साथ सुरक्षित रूप से प्रयोग करने के लिए, इसे डॉस / सीएमडी स्तर पर आज़माएं ...

सी के रूट में फ़ाइल की सामग्री बनाएं और फिर प्रदर्शित करें:

C:\> echo The main data stream> test.txt
C:\> type test.txt

परिणाम:

C:\> The main data stream

अब एक ही विधि के साथ एक एडीएस जोड़ें, फ़ाइल नाम के अतिरिक्त केवल एडीएस नाम निर्दिष्ट करें:

C:\> echo The secret message> test.txt:secret

आपने फ़ाइल में गुप्त संदेश छुपाया है। ध्यान दें कि एक्सप्लोरर में फ़ाइल का आकार बदल नहीं गया है, इसके बावजूद हमने एडीएस "गुप्त" में बाइट जोड़े।

एडीएस सामग्री प्रदर्शित करने का प्रयास करें:

C:\> type test.txt:secret

परिणाम:

The filename, directory name, or volume label syntax is incorrect.

अध्यक्ष एवं प्रबंध निदेशक type एडीएस की सामग्री प्रदर्शित करने में सक्षम नहीं है। हम इसके बजाय नोटपैड का उपयोग करेंगे:

notepad test.txt:secret

नोटपैड में हम एडीएस की सामग्री देख सकते हैं:

The secret message

आप एक निर्दोष पाठ फ़ाइल के एडीएस में पूर्ण निष्पादन योग्य भी छिपा सकते हैं, और इसे किसी भी समय चला सकते हैं। धन हैकर्स के लिए नुकसान नहीं पहुंचाता :-)


25
2018-01-21 07:37



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


समस्या क्लस्टर आकार की वजह से हो सकती है।

इसके अनुसार माइक्रोसॉफ्ट:

यदि आप किसी भी फाइल या फ़ोल्डर्स के लिए एनटीएफएस संपीड़न का उपयोग नहीं कर रहे हैं   वॉल्यूम पर निहित, डिस्क पर SIZE और SIZE के बीच का अंतर   एक आवश्यक क्लस्टर आकार की वजह से बर्बाद जगह है। आप   इष्टतम क्लस्टर आकार का उपयोग करने का प्रयास करना चाहिए ताकि डिस्क पर आकार   मान जितना संभव हो सके SIZE मान के करीब है। एक अत्यधिक   डिस्क पर आकार और SIZE मान के बीच विसंगति एक है   संकेत है कि डिफ़ॉल्ट क्लस्टर आकार औसत के लिए बहुत बड़ा है   फ़ाइल आकार जो आप वॉल्यूम पर संग्रहीत कर रहे हैं, और यह होना चाहिए   की कमी हुई। यह केवल वॉल्यूम का बैक अप ले कर और फिर किया जा सकता है   स्वरूप कमांड और / स्विच का उपयोग कर वॉल्यूम को दोबारा सुधारना   उचित आवंटन आकार निर्दिष्ट करने के लिए: आईई: format D: /a:2048   (यह उदाहरण 2-केबी क्लस्टर आकार का उपयोग करता है)।

छोटे क्लस्टर आकार के साथ अपने ड्राइव स्वरूपण करने का प्रयास करें।


19
2018-01-20 09:57



ऐसा कहा जाता है कि किसी को क्लस्टर आकार 4096 बाइट से कम नहीं करना चाहिए या सिर्फ इस संख्या के एकाधिक नहीं होना चाहिए। 32 बिट ओएस उन पृष्ठों के साथ काम करता है जो (गैर-पीएई मामले में) 40 9 6 बाइट्स हैं, इसलिए गैर-एकाधिक क्लस्टर का उपयोग फ़ाइल सिस्टम प्रदर्शन को नकारात्मक रूप से प्रभावित कर सकता है। यही कारण है कि डिफ़ॉल्ट आकार 4096 बाइट्स पर सेट है। - Ruslan
@Ruslan ने जो कहा, उसे जोड़ने के लिए, नए हार्ड ड्राइव में अब 4 केबी सेक्टर का आकार है, और फाइल सिस्टम को भौतिक क्षेत्रों में संरेखित करना इष्टतम होगा, और आवंटन इकाई आकार के रूप में भौतिक क्षेत्र के आकार का एक से अधिक होना चाहिए। - Bob
@ रूस्लान मेरा मानना ​​है कि आप कहने का मतलब है कि यह दो बार 4096 की शक्ति होनी चाहिए। 12288 (3 × 40 9 6) और 20480 (5 × 40 9 6) बहुत अच्छे विकल्प नहीं हैं। - Scott


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

आप NAND के क्लस्टर आकार को नहीं बदल सकते हैं (यह आपके एसडी कार्ड के हार्डवेयर की भौतिक विशेषता है)।

अपने एसडी कार्ड पर सबसे पहले स्कैंडिस्क / चकडस्क चलाएं ताकि यह सुनिश्चित किया जा सके कि आकार रिपोर्ट समस्या दूषित फाइल सिस्टम में नहीं है।

दूसरा, मैं सुझाव दूंगा कि आप Google मानचित्र देवताओं को बग की रिपोर्ट करें, क्योंकि उनमें से एक को दोषी ठहराया जा रहा है। वे एक बेहतर भंडारण विधि का उपयोग करना चाहिए। इसे ठीक करने से ऐप को कम I / O और फ़ाइल सिस्टम की ड्राइवर गतिविधि के कारण कई उपकरणों पर तेजी से चलना चाहिए।


9
2018-01-21 18:20



असल में, यह Google मानचित्र नहीं था, लेकिन Google के मानचित्र का उपयोग करके एक और ऐप। मैंने डेवलपर को सूचित किया, और बस उन फ़ाइलों को मेरे एसडी से हटा दिया। - vfsoraki


यह कई फाइल सिस्टम के साथ एक सामान्य मुद्दा है। यहां काम करने के दो कारक हैं, फाइल सिस्टम "ब्लॉक" की अधिकतम संख्या प्रति लॉजिकल वॉल्यूम और स्टोरेज माध्यम के भौतिक प्रतिबंधों को संभाल सकती है। किसी भी दिए गए ब्लॉक को केवल 1 फ़ाइल आवंटित की जा सकती है (फाइलें आमतौर पर जितनी आवश्यकता होती है उतनी ब्लॉक लेती हैं)। इसलिए 64 बाइट्स वाली एक टेक्स्ट फ़ाइल अक्सर 4k से 32k तक ले सकती है, जो उस फाइल सिस्टम के ब्लॉक आकार के आधार पर होती है।

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

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

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

तो उस मामले में मेरा एक पेज दस्तावेज़ अभी भी एक बॉक्स पर कब्जा कर लेगा, और इसे साझा करने के अलावा कुछ भी नहीं।

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


7
2018-01-20 14:50





क्लस्टर आकारों के अलावा, आप निम्न स्थितियों के कारण एक विसंगति भी प्राप्त कर सकते हैं:

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

6
2018-01-20 17:42



आम तौर पर, यह सच हो सकता है। लेकिन मेरे मामले में, उच्च आवंटन इकाई समस्या थी। - vfsoraki
हाँ, मैं विसंगति के लिए और अधिक संभावित कारण देकर जवाब में जोड़ने की कोशिश कर रहा हूं। - Archimedes Trajano


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

सभी को डिस्क को दोबारा सुधारने की आवश्यकता के असुविधाजनक हैं।

कुछ मामलों में केवल उन फ़ाइलों को संग्रह में संग्रहीत करने से समस्या ठीक हो जाएगी (और फ़ाइलों के अंत में खोने वाली जगह को रोकने के अलावा छोटी फ़ाइलों को भी संपीड़ित किया जाएगा)। यह डिकंप्रेशन के लिए कुछ समय बिताने का असुविधाजनक है।

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

http://en.wikipedia.org/wiki/Tail_packing


6
2018-01-20 15:00





मैंने एक व्यक्तिगत फ़ाइल पर विंडोज 10 में बड़ी फ़ाइल आकार विसंगतियों को नोट किया, लेकिन यदि मैं उसी स्थान से एक ही फ़ाइल (नेटवर्क ड्राइव) से समान फ़ाइल के गुणों को देखता हूं, तो विंडोज़ XP के साथ, बड़ी विसंगति नहीं होती है; बस एक छोटा सा अंतर, जो आप उम्मीद करेंगे। मुझे लगता है कि विंडोज 10 में एक बग है। 44 9 एमबी की एक फाइल शायद 3.99 जीबी नहीं लेती है, जो विंडोज 10 मुझे बता रही है।


0
2018-06-15 17:57



सिर्फ एक एफवाईआई, इस सवाल का विंडोज़ 10 के साथ कुछ लेना देना नहीं है। ओपी विंडोज 7 का उपयोग कर रहा है। - TheKB