डीफ़्रेग्मेंटिंग सी ड्राइव ने मेरी मुफ्त डिस्क स्पेस को 10 जीबी क्यों बढ़ाया?

मैंने अपने 100 GB C: \ ड्राइव पर खाली जगह को डीफ्रैग्लर करने के लिए डिफ्रैग्लर का उपयोग किया, जो 85 जीबी पूर्ण था। डीफ़्रैग्मेन्टेशन के बाद, ड्राइव केवल 75 जीबी पूर्ण दिखा। जादुई रूप से 10 जीबी मुक्त स्थान कैसे दिखाई दिया? क्या मैंने कोई डेटा खो दिया?

मैंने डीफ़्रेग्मेंटिंग से पहले एक डिस्क क्लीनअप किया था और मेरा कचरा केवल 11 एमबी था, इसलिए यह अस्थायी फ़ाइलों की सफाई के कारण नहीं हो सकता है। ध्यान दें कि मैंने "मुक्त स्थान" को डीफ़्रैग्मेन्ट किया है जिसका अर्थ है कि इसे खाली ब्लॉकों को सन्निहित होना चाहिए।

ntfs disk-space defragment

— goweon
स्रोत

संभवतः छाया प्रति के साथ एक बातचीत: उदाहरण के लिए देखें ( piriform.com/docs/defraggler/technical-information/… )

— क्षितिज 14

इसके अलावा, डीफ़्रैग्लर के पास डीफ़्रेग्मेंटिंग से पहले रीसायकल बिन को खाली करने का विकल्प होता है।

— oKtosiTe

जवाबों:

शायद यह क्या हुआ कि डीफ़्रैग ऑपरेशन ने विंडोज को स्नैपशॉट को पुनर्स्थापित करने के लिए कुछ सिस्टम को बाहर करने के लिए मजबूर किया। यह विखंडन का एक पैथोलॉजिकल मामला होगा, जो मेटाडेटा ओवरहेड का कारण बनता है, जो कि विंडोज़ के सामान्य रूप से उपयोग किए जाने पर आपके ड्राइव स्पेस का 10% हिस्सा होता है। फिर भी, मुझे यकीन नहीं है कि यह संभव है।

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

जब आप वॉल्यूम को डीफ़्रैग्मेंट करते हैं तो छाया प्रतियां खो सकती हैं : इसका कारण यह है कि डिफ़ॉल्ट रूप से, VSS डिफ़ॉल्ट रूप से 16 KB क्लस्टर के साथ काम करता है, जबकि अधिकांश NTFS वॉल्यूम 4 KB क्लस्टर के साथ स्वरूपित होते हैं। इसलिए यदि एक डीफ़्रेग ऑपरेशन डेटा को स्थानांतरित कर रहा है जो 16 केबी क्लस्टर (या "दूरी" का एक से अधिक भाग नहीं है जो कि 16 केबी से अधिक नहीं है), तो वीएसएस इसे एक बदलाव के रूप में ट्रैक करेगा और आपके सभी को शुद्ध कर सकता है स्नैपशॉट।

MSDN: Defragmenting फ़ाइलें :

जब संभव हो, ब्लॉक में डेटा को एक-दूसरे के सापेक्ष 16-किलोबाइट (KB) वृद्धि में संरेखित करें। यह कॉपी-ऑन-राइट ओवरहेड को कम कर देता है जब छाया प्रतियां सक्षम हो जाती हैं, क्योंकि छाया कॉपी स्पेस बढ़ जाती है और निम्न स्थितियां होने पर प्रदर्शन कम हो जाता है:

चाल अनुरोध ब्लॉक का आकार 16 KB से कम या उसके बराबर है।

चाल डेल्टा 16 केबी की वृद्धि में नहीं है।

विस्टा के डीफ़्रैग में निर्मित यह नहीं करता है :

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

— afrazier
स्रोत

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

— Slartibartfast

@Slartibartfast: यदि ऐप सही तरीके से नहीं लिखा गया है तो यह एक समस्या है। मैं अपने उत्तर को और सबूतों के साथ अपडेट करूंगा, अब जब मैं अपने फोन पर नहीं हूं। :-)

— पूर्वोक्त

@afrazier - हालाँकि मुझे लगता है कि ThouArtNotDoc का अद्यतन उत्तर एक बेहतर सामान्य उत्तर है। मुझे इस बात से सहमत होना होगा कि छाया प्रतियां संभवतः ओपी की स्थिति में भूमिका निभा रही हैं। मैंने यह भी पाया: "यदि आप उन वॉल्यूमों को डीफ़्रैग्मेन्ट करने की योजना बनाते हैं, जिन पर छाया प्रतियाँ सक्षम हैं, तो यह अनुशंसा की जाती है कि आप 16 KB या उससे बड़े आकार के क्लस्टर (या आवंटन इकाई) का उपयोग करें। यदि आप नहीं करते हैं, तो परिवर्तनों की संख्या। डीफ़्रैग्मेन्टेशन प्रक्रिया द्वारा छाया प्रतियों को अपेक्षा से अधिक तेज़ी से हटाया जा सकता है। " - MS: "एक छाया प्रति की रणनीति डिजाइनिंग" Technet.microsoft.com/en-us/library/cc728305(WS.10).aspx

— 8cʜιᴇ007

@afrazier: पुष्टि की। पिछले सभी सिस्टम पुनर्स्थापना बिंदु चले गए हैं। कॉन्फ़िगरेशन में, मेरे पास 12% सेट है क्योंकि छाया प्रतियों के लिए अधिकतम स्थान की अनुमति है, इसलिए 10 जीबी अनुचित नहीं है। दूसरी ओर, मैंने सिर्फ एक 9 जीबी गेम स्थापित किया है, जो पिछले पुनर्स्थापना बिंदुओं को ओवरवोट कर सकता है।

— ग्वून जूल

@firebat: सिस्टम रिस्टोर द्वारा उपयोग किया जाने वाला स्थान मौजूदा (स्नैपशॉट) फ़ाइलों में परिवर्तन पर नज़र रखने के लिए है, नए नहीं। एक नया गेम इंस्टॉल करने से सिस्टम रिस्टोर नहीं होगा, बल्कि एक बड़ा पैच हो सकता है।

— १

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

एक उदाहरण: मान लीजिए कि आपके पास 1000 खंडों वाली एकल फ़ाइल है। इस प्रकार आपकी फ़ाइल यादृच्छिक ब्लॉकों के संग्रह के माध्यम से संग्रहीत की जाती है .. बल्कि एक ही निरंतर ब्लॉक में। इसका मतलब है कि खंडित फ़ाइल को फ़ाइल सिस्टम की पाइपलाइन के भीतर 1000x अधिक संग्रहण स्थान की आवश्यकता होती है, यदि केवल प्रत्येक टुकड़े के लिए पते संग्रहीत करने के लिए। फ़ाइल सिस्टम प्लंबिंग फ़ाइल के प्रत्येक टुकड़े के स्थान पर थोड़े शब्दकोशों / डेटाबेस / मैप्स / टेबल / सूची रखता है। इसलिए, फ़ाइल सिस्टम प्लंबिंग के लिए, 1000 विखंडन बिंदुओं की सूची की तुलना में, एक एकल फ़्रेग्मेंट पॉइंटर की सूची को संग्रहीत करने के लिए अधिक स्थान की आवश्यकता नहीं होती है।

लेकिन हे, शायद मैं गलत हूँ ...

संपादित करें: यहाँ से सहायक सूचना :

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

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

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

— जेम्स टी स्नेल
स्रोत

पुनश्च - कि कुछ कट्टर विखंडन रहा होगा।

— जेम्स टी स्नेल

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

— कुशल

डनो, 10 जी बहुत कुछ लगता है, लेकिन आईएमई, बहुत पूर्ण डिस्क कम खंडित डिस्क की तुलना में बहुत अधिक तेजी से टुकड़े करते हैं। यदि वह पहले से 85% पर था (क्योंकि वह प्रोब्स का मतलब 85GiB लेकिन 100GB डिस्क है), और संभवतः इस बीच फुलर, तो वह शानदार उच्च विखंडन, और परिचर डरावने प्रदर्शन कर सकता था।

— बेरंड हग जूल

जब तक उस मात्रा पर अवरोधन बहुत अधिक नहीं होता है, तब तक मैं व्यक्तिगत रूप से 10GB स्थान में विश्वास नहीं कर सकता, केवल टुकड़ों को ट्रैक नहीं करके मुक्त किया जा सकता है। 4096k के एक blockize और प्रत्येक टुकड़े को संभालने के लिए ट्रैक करने के लिए एक पूर्ण ब्लॉक की आवश्यकता होती है (जो कि गलत है), जिसे पूर्व में ट्रैक किए गए 2.5 मिलियन टुकड़े की आवश्यकता होगी, लेकिन उस स्थान को खाली करने के लिए और अधिक नहीं।

— कार्लफ

@ डॉक - एक पॉइंटर पूरे ब्लॉक नहीं लेगा। यदि (जैसा कि संभावना है) प्रत्येक आवंटन ब्लॉक कई सेक्टर हैं, तो आपको कम पॉइंटर्स की आवश्यकता होती है क्योंकि आपके डेटा को ट्रैक करने के लिए कम ब्लॉक होते हैं - इसलिए सभी टुकड़ों को ट्रैक करने के लिए अधिकतम संभव ओवरहेड 3% से कम होगा। मुझे एनटीएफएस का सटीक विवरण नहीं पता है, लेकिन (अपेक्षाकृत अक्षम) एफएटी फाइलिंग सिस्टम के साथ, आप अभी भी फ़ाइल आवंटन तालिका (उन खंड-ट्रैकिंग बिंदुओं) के लिए 10% ओवरहेड प्राप्त नहीं कर सके, जो एफएटी के नाम पर रखा गया था।

— स्टीव