সি ড্রাইভে ডিফ্র্যাগমেন্টিং কেন আমার ফ্রি ডিস্কের স্থানটি 10 ​​জিবি বাড়িয়েছে?


27

আমি আমার 100 গিগাবাইট সি: \ ড্রাইভে 85 ডিগ্রি পূর্ণ ছিল এমন ড্রাইভে ফ্রি স্পেস ডিফ্র্যাগমেন্ট করতে ডিফ্রেগ্লার ব্যবহার করেছি। ডিফ্র্যাগমেন্টেশন হওয়ার পরে, ড্রাইভটি কেবল 75 গিগাবাইট পূর্ণ দেখায়। 10 গিগাবাইট খালি স্থান কীভাবে যাদুকরীভাবে উপস্থিত হয়েছিল? আমি কি কোন ডেটা হারিয়েছি?

ডিফ্র্যাগমেন্টিংয়ের আগে আমি একটি ডিস্ক ক্লিনআপ করেছিলাম এবং আমার ট্র্যাশটি প্রায় 11 এমবি ছিল, তাই অস্থায়ী ফাইলগুলি পরিষ্কার করার কারণে এটি হতে পারে না। মনে রাখবেন যে আমি "ফ্রি স্পেস" ডিফ্র্যাগমেন্ট করেছি যার অর্থ এটি খালি ব্লকগুলিকে সামঞ্জস্য করার জন্য পুনরায় সাজানো উচিত।


1
সম্ভবত ছায়ার অনুলিপিটির সাথে একটি মিথস্ক্রিয়া: উদাহরণস্বরূপ দেখুন ( piriform.com/docs/defraggler/technical-inifications/… )
হোরাটিও

2
এছাড়াও, ডিফ্রেগলারের কাছে ডিফ্র্যাগমেন্টিংয়ের আগে রিসাইকেল বিনটি খালি করার বিকল্প রয়েছে।
oKtosiTe

উত্তর:


14

সম্ভবত যা ঘটেছিল তা হ'ল ডিফ্রেগ অপারেশন উইন্ডোজকে কিছু সিস্টেম পুনরুদ্ধার স্ন্যাপশট ফেলে দিতে বাধ্য করেছিল। উইন্ডোজ সাধারনত যা ব্যবহার করে তার উপরে মেটাডেটা ওভারহেড আপনার ড্রাইভের পুরো 10% স্থানের কারণ হতে পারে এটি খণ্ডিত হওয়ার একটি প্যাথলজিকাল কেস হবে। তারপরেও, আমি নিশ্চিত যে এটি সম্ভব।

আমি ডিফ্রাগ্লারের সংস্করণ ইতিহাস বা ডকুমেন্টেশনে এমন কোনও কিছুই দেখতে পাচ্ছি না যা ইঙ্গিত করে যে এটি ছায়ার অনুলিপিগুলি পরিষ্কার করার জন্য ফাইলগুলি সঠিকভাবে ডিফ্র্যাগমেন্ট করতে সক্ষম হয়েছে। প্রকৃতপক্ষে, ডিফ্রাগ্লারের সমর্থন ফোরামের এই থ্রেডটি ইঙ্গিত দেয় যে তারা জানে যে এটি ঘটছে (থ্রেডে "অফিসিয়াল পিরিফর্ম বাগ ফিক্সার" নামে একটি বোর্ড প্রশাসকের একটি পোস্ট রয়েছে) তবে তারা এটি ঠিক করতে চলেছে কি না তা নির্দেশ করে না।

আপনি কোনও ভলিউম ডিফল্ট করলে শ্যাডো অনুলিপিগুলি হারিয়ে যেতে পারে : এর কারণ হ'ল ডিফল্টরূপে, ভিএসএস 16 কেবি ক্লাস্টারগুলি ডিফল্টরূপে পরিচালনা করে, যখন বেশিরভাগ এনটিএফএস ভলিউম 4 কেবি ক্লাস্টার দিয়ে ফর্ম্যাট করা হয়। সুতরাং যদি কোনও ডিফ্রেগ অপারেশন ডেটা স্থানান্তরিত করে যা 16 কেবি ক্লাস্টারের একাধিক নয় (বা "যে দূরত্বটি" সরানো হয়েছে এটি 16 কেবি এর একাধিক নয়), তবে ভিএসএস এটিকে পরিবর্তন হিসাবে ট্র্যাক করবে এবং আপনার সমস্ত সংশোধন করবে স্ন্যাপশট।

এমএসডিএন: ডিফ্রেগমেন্টিং ফাইল :

সম্ভব হলে, ব্লকগুলিতে ডেটা সরিয়ে 16-কিলোবাইট (কেবি) ইনক্রিমেন্টে একে অপরের তুলনায় প্রান্তিক করা হয়। এটি ছায়া অনুলিপি সক্ষম করার সময় অনুলিপি-অন-লিখনের ওভারহেড হ্রাস করে, কারণ ছায়া অনুলিপি স্থানটি বৃদ্ধি করা হয় এবং নিম্নলিখিত শর্তগুলি উপস্থিত হলে কর্মক্ষমতা হ্রাস পায়:

  • সরানোর অনুরোধের ব্লকটির আকার 16 কেবি এর চেয়ে কম বা সমান।
  • সরানো বদ্বীপ 16 কেবি এর ইনক্রিমেন্টে নয়।

ভিস্তার বিল্ট ইন ডিফ্র্যাগ এটি করে না :

ব্যবহারকারীদের কাছে স্পষ্ট নয় এমন একটি পরিবর্তন হ'ল ডিফ্র্যাগমেন্টেশন চলাকালীন আমাদের ছায়া অনুলিপি অপ্টিমাইজেশন। ডিফ্রেগের কাছে ফাইল ব্লকগুলি এমনভাবে সরানোর জন্য বিশেষ তাত্পর্য রয়েছে যা অনুলিপি-অনুলিপি কার্যকলাপ এবং ছায়া অনুলিপি স্টোরেজ এরিয়া খরচ কমিয়ে দেবে। এই অপ্টিমাইজেশন ব্যতীত, ডিফ্র্যাগমেন্টেশন প্রক্রিয়া পুরানো ছায়া অনুলিপি মোছা ত্বরান্বিত করবে।


আমি এই উত্তরের স্ন্যাপশট অংশ সম্পর্কে জানি না, তবে আমি নিশ্চিত নই যে ডিফ্র্যাগ স্থানটি মুক্ত করেছিল। Defrag আপনার রিসাইকেল বিন খালি করতে পারে? একটি ফাইল সিস্টেমে যা ছোট ফাইলগুলিকে একক ক্লাস্টারে একত্রিত করে না, আমি দেখতে পাচ্ছি না যে ডিফ্র্যাগমেন্টিংয়ের ফলে এমন স্থান লাভ কীভাবে ঘটবে। আমি কল্পনা করতে পারি যে এই জাতীয় ছোট ব্লকগুলিতে আপনার 10G স্থান উপলব্ধ ছিল যা উইন্ডোজ এটি গণনা করছে না, তবে আমি এই আচরণের আগে শুনিনি।
স্লেটারিবার্টফাষ্ট

@ স্লাটিবার্টফেষ্ট: অ্যাপটি সঠিকভাবে না লেখা থাকলে সমস্যা। আমি আমার উত্তরটি আরও প্রমাণ সহ আপডেট করব, এখন যে আমি আমার ফোনে নেই। :-)
আফ্রাজির

@ আফ্রাজিয়ার - যদিও আমি মনে করি তুমি আর্টনটডকের আপডেট হওয়া উত্তরটি একটি আরও সাধারণ উত্তর general আমাকে একমত হতে হবে যে ছায়ার অনুলিপিগুলি সম্ভবত ওপি'র পরিস্থিতিতে ভূমিকা রাখছে। আমি এটিও পেয়েছি: "আপনি যদি ছায়ার অনুলিপিগুলিকে সক্ষম করে এমন ভলিউমকে ডিফ্র্যাগমেন্ট করার পরিকল্পনা করেন, তবে আপনি 16 কেবি বা তার বেশি আকারের একটি ক্লাস্টার (বা বরাদ্দ ইউনিট) ব্যবহার করার পরামর্শ দেওয়া হচ্ছে you আপনি যদি তা না করেন তবে পরিবর্তনের সংখ্যাটি ডিফ্র্যাগমেন্টেশন প্রক্রিয়া দ্বারা ছায়ার অনুলিপিগুলি প্রত্যাশার চেয়ে দ্রুত মুছে ফেলাতে পারে। " - এমএস: "একটি ছায়ার
ʜιᴇcʜιᴇ007

@ আফ্রাজিয়ার: নিশ্চিত পূর্ববর্তী সমস্ত সিস্টেমের পুনরুদ্ধার পয়েন্টগুলি চলে গেছে। কনফিগারেশনে, আমার ছায়া অনুলিপিগুলির জন্য অনুমোদিত সর্বোচ্চ স্থান হিসাবে 12% সেট রয়েছে, সুতরাং 10 জিবি অযৌক্তিক নয়। অন্যদিকে, আমি সবেমাত্র একটি 9 গিগাবাইট গেম ইনস্টল করেছি, যা পূর্ববর্তী পুনরুদ্ধার পয়েন্টগুলি কেবল ওভাররোট করতে পারে।
goweon

@ ফায়ারব্যাট: সিস্টেম পুনরুদ্ধার দ্বারা ব্যবহৃত স্থানটি বিদ্যমান (স্ন্যাপশটযুক্ত) ফাইলগুলিতে পরিবর্তনগুলি ট্র্যাক করার জন্য, নতুন নয়। একটি নতুন গেম ইনস্টল করা সিস্টেম পুনরুদ্ধার স্থানকে প্রভাবিত করবে না, তবে একটি বড় প্যাচ পারে।
আফরাজায়

23

প্রতিটি খণ্ড কোথাও ট্র্যাক করতে হবে। এটি স্টোরেজ স্পেস নেয় (ফাইল সিস্টেমের নদীর গভীরতানির্ণয়ের মধ্যে, এমন স্টাফ নয় যা আপনি সরাসরি অ্যাক্সেস করতে চান)।

একটি উদাহরণ: ধরুন আপনার কাছে 1000 টি টুকরা সহ একটি ফাইল রয়েছে। সুতরাং আপনার ফাইলটি এলোমেলো ব্লকের সংগ্রহের মাধ্যমে সংরক্ষণ করা হবে .. একক অবিচ্ছিন্ন ব্লকের চেয়ে। এর অর্থ খণ্ডিত ফাইলটির কেবলমাত্র প্রতিটি খণ্ডের ঠিকানা সংরক্ষণের জন্য যদি ফাইল সিস্টেমের নদীর গভীরতানির্ণয়ের মধ্যে 1000x বেশি স্টোরেজ স্পেস প্রয়োজন। ফাইল সিস্টেম নদীর গভীরতানির্ণয় ফাইলের প্রতিটি খণ্ডের অবস্থানের জন্য খুব সামান্য অভিধান / ডাটাবেস / মানচিত্র / সারণী / তালিকা রাখে। সুতরাং, ফাইল সিস্টেম নদীর গভীরতানির্ণয়ের জন্য, একক টুকরো পয়েন্টারের তালিকা সংরক্ষণের জন্য খুব বেশি জায়গার প্রয়োজন হবে না, তুলনায় 1000 ফ্রেগমেন্ট পয়েন্টারগুলির তালিকা ..

তবে আরে, আমি হয়তো ভুল ...

সম্পাদনা করুন: এখান থেকে সহায়ক তথ্য :

যখন কোনও অনাবাসী ডেটা স্ট্রিম খুব বেশি খণ্ডিত হয়, যাতে এর কার্যকর বরাদ্দ মানচিত্রটি এমএফটি রেকর্ডের মধ্যে পুরোপুরি ফিট করে না, বরাদ্দ মানচিত্রটি একটি অনাবাসী স্ট্রিম হিসাবেও সংরক্ষণ করা যেতে পারে, যেখানে পরোক্ষ বরাদ্দ থাকা কেবল একটি ছোট আবাসিক স্ট্রিম থাকে অনাবাসী ডাটা স্ট্রিমের কার্যকর অনাবাসী বরাদ্দ মানচিত্রের মানচিত্র map

অনুবাদ: আপনার যদি ভারী খণ্ডন থাকে তবে ফাইল সিস্টেম নদীর গভীরতানির্ণয়ের সাধারণ ক্ষেত্রে অনুমানগুলি প্রযোজ্য হবে না। এ হিসাবে, খণ্ডগুলি সামঞ্জস্য করার জন্য এফএসকে অবশ্যই পদক্ষেপ নিতে হবে এবং কেবল খণ্ডগুলি পরিচালনা করতে অতিরিক্ত স্টোরেজ স্পেস ব্যয় করতে হবে। ঠিক প্রথম স্থান থেকে আমার অনুমান।


সম্পাদনা: উপরেরটি দেওয়া, এখনও মনে হচ্ছে 10 জিবি হারিয়ে গেছে কেবল খণ্ডন ফাইল করাতে আমি বাজি দিচ্ছি যে ডিফ্র্যাগ করার সময় আপনার কিছু সাধারণ ফাইল সিস্টেমের দুর্নীতি হয়েছিল যা স্বয়ংক্রিয়ভাবে সংশোধন হয়ে গেছে। আমি ভাবছি যে আপনার কেবল বিশাল বিভাজন ছিল না, তবে স্টোরেজ স্পেস গ্রহণ করে আংশিকভাবে মুছে ফেলা ফাইলগুলিও রয়েছে। ডিফ্রেগ (বা ডিফ্র্যাগের আগে স্ক্যানডিস্কের একটি রান) থেকে কোনও স্ক্যানডিস্ক লগটি দেখে ভাল লাগত


3
পিএস - এটি অবশ্যই কিছু হার্ড টুকরো টুকরো করা হয়েছে।
জেমস টি স্নেল

আমি জানি না ডিফ্র্যাগমেন্টেশন করার পরে স্টোরেজ খরচ বাড়ার এটি কোনও বৈধ কারণ কিনা। তবে আমি এটি বহুবার লক্ষ্য করেছি, আপনার যদি সিস্টেম রিস্টোর পয়েন্ট থাকে যা বেশ পুরানো (সাধারণত আপনি যদি নিয়মিত ডিস্ক ক্লিনআপ ইউটিলিটি চালান তবে তা ঘটে না), এবং সি ড্রাইভে প্রচুর ডেটা সংগ্রহ করার পরে আপনি ডিফ্র্যাগমেন্ট করেন, মেমরির খরচ কোথাও থেকে বেড়ে যায়, তবে আপনি যদি সেই পুনরুদ্ধার পয়েন্টটি মুছে ফেলেন তবে এটি দখলকৃত স্টোরেজটি পরিষ্কার করে দেয়। এটি প্রযুক্তিগতভাবে, এটি কোনও ধারণা রাখে না, তবে আমার সাথে অনেক সময় ঘটেছিল, ওভারটাইমের পরে, পুনরুদ্ধার পয়েন্টগুলি স্মৃতি গ্রহণ করে।
কুশল

ডান্নো, 10 জি অনেকটা মনে হচ্ছে, তবে আইএমই, খুব সম্পূর্ণ ডিস্ক কম খণ্ডিত ডিস্কের চেয়ে অনেক বেশি দ্রুত খণ্ডিত হতে থাকে। যদি তিনি এর আগে 85% ছিলেন (যেহেতু তিনি 85GiB তবে 100 গিগাবাইট ডিস্কটি বোঝায়) এবং সম্ভবত এর মধ্যে পুরোপুরি, তিনি দর্শনীয়ভাবে উচ্চতর খণ্ডন এবং পরিবেশনকারীদের ভয়াবহ অভিনয় করতে পারতেন।
বার্ড হগ

3
যদি না এই ভলিউমের ব্লকসাইজ অশ্লীলভাবে উচ্চ না হয়, আমি ব্যক্তিগতভাবে বিশ্বাস করতে পারি না 10 জিবি স্থান কেবল খণ্ডিত ট্র্যাকিং না করে খালি করা হবে f ৪০৯6 কে ব্লকসাইজ সহ এবং প্রতিটি খণ্ডকে ধরে নিলে কেবল ট্র্যাক করার জন্য একটি সম্পূর্ণ ব্লক প্রয়োজন (যা মিথ্যা), সেই জায়গাটি খালি করার জন্য আগে ২.৫ মিলিয়ন টুকরোগুলি প্রয়োজন তবে আরও কোনও দরকার নেই।
কার্লএফ

1
@ ডক - একটি পয়েন্টার পুরো ব্লক নেবে না। যদি (সম্ভবতঃ) প্রতিটি বরাদ্দ ব্লক একাধিক ক্ষেত্র হয়, আপনার ডেটা ট্র্যাক করার জন্য কম ব্লক রয়েছে বলে আপনার কম পয়েন্টার প্রয়োজন - সুতরাং সমস্ত খণ্ডকে ট্র্যাক করার সর্বাধিক সম্ভাব্য ওভারহেড 3% এরও কম হবে। আমি এনটিএফএসের সঠিক বিবরণ জানি না, তবে (অপেক্ষাকৃত অদক্ষ) FAT ফাইলিং সিস্টেমের সাহায্যে আপনি এখনও ফাইল বরাদ্দ সারণীর জন্য 10% ওভারহেড পেতে পারেনি (সেই খণ্ডগুলি-ট্র্যাকিং পয়েন্টার) যেটির নামকরণ করা হয়েছিল FAT।
স্টিভ 314
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.