একটি মুলতুবি অপঠনযোগ্য খাত হ'ল এটি যা একটি পঠন ত্রুটি ফিরিয়ে দিয়েছে এবং যা ড্রাইভ প্রথম সম্ভাব্য সুযোগে রিম্যাপিংয়ের জন্য চিহ্নিত করেছে। যাইহোক, দুটি জিনিসের একটির সংঘটিত না হওয়া পর্যন্ত এটি রিম্যাপিং করতে পারে না:
- সেক্টরটি সাফল্যের সাথে পুনরায় পড়া হবে
- সেক্টরটি নতুন করে লেখা হয়েছে
ততক্ষণে এই সেক্টরটি বিচারাধীন রয়েছে। সুতরাং এটির সাথে মোকাবিলা করার জন্য আপনার দুটি অনুরূপ উপায় রয়েছে:
- আপনি সফল না হওয়া পর্যন্ত এই সেক্টরটি পুনরায় পড়ার চেষ্টা চালিয়ে যান
- নতুন ডেটা সহ সেই সেক্টরটি মুছে ফেলুন
স্পষ্টতই, (1) অ-ধ্বংসাত্মক, সুতরাং আপনার সম্ভবত প্রথমে চেষ্টা করা উচিত, যদিও মনে রাখবেন যে যদি ড্রাইভটি কোনও গুরুতর উপায়ে ব্যর্থ হতে শুরু করে তবে কোনও খারাপ অঞ্চল থেকে নিয়মিত পড়া চালিয়ে যাওয়ার ফলে এটি আরও দ্রুত ব্যর্থ হয়ে যেতে পারে । আপনার যদি প্রচুর মুলতুবি খাত এবং অন্যান্য ত্রুটিগুলি থাকে এবং আপনি ড্রাইভের ডেটা সম্পর্কে যত্নশীল হন তবে আমি এটিকে পরিষেবা থেকে সরিয়ে নেওয়ার এবং যথাসম্ভব ডেটা পুনরুদ্ধারের জন্য দুর্দান্ত সরঞ্জাম ডিড্রেসিকিউ ব্যবহার করার পরামর্শ দিচ্ছি । তারপরে ড্রাইভটি ফেলে দিন।
যদি প্রশ্নে এই সেক্টরে এমন ডেটা রয়েছে যা আপনার পক্ষে যত্নশীল নয় বা ব্যাকআপ থেকে পুনরুদ্ধার করতে পারে তবে এটি ওভাররাইট করা সম্ভবত সম্ভবত দ্রুত এবং সহজ সমাধান। তারপরে সেক্টরটি যত্ন নেওয়া হয়েছে তা নিশ্চিত করার জন্য আপনি ড্রাইভের জন্য পুনঃনির্ধারিত এবং মুলতুবি সংখ্যাগুলি দেখতে পারেন can
ফাইল সিস্টেমে সেক্টরটির সাথে কী মিল রয়েছে তা আপনি কীভাবে আবিষ্কার করবেন? আমি এখানে স্মার্টমনটোস ওয়েব সাইটে একটি দুর্দান্ত নিবন্ধ পেয়েছি , যদিও এটি মোটামুটি প্রযুক্তিগত এবং এটি এক্সট 2/3/4 এবং রিসার ফাইল সিস্টেমের সাথে নির্দিষ্ট।
একটি সহজ পদ্ধতির, যা আমি নিজের একটি (ম্যাক) ড্রাইভে ব্যবহার করেছি, তা হ'ল find / -xdev -type f -print0 | xargs -0 ...সিস্টেমে প্রতিটি ফাইল পড়ার জন্য। এটি চালানোর আগে মুলতুবি থাকা গণনাটির একটি নোট তৈরি করুন। ক্ষেত্রটি যদি কোনও ফাইলের অভ্যন্তরে থাকে তবে আপনি যে সরঞ্জামটি ফাইলগুলি পড়ার জন্য ব্যবহার করেছিলেন সেখান থেকে একটি ত্রুটি বার্তা পাবেন (যেমন md5sum) আপনাকে এর পথ দেখায় path তারপরে আপনি আপনার মনোযোগগুলি কেবলমাত্র এই ফাইলটি সফলভাবে না পড়া পর্যন্ত পুনরায় পড়ার উপর ফোকাস করতে পারেন। প্রায়শই এটি সমস্যার সমাধান করবে, যদি এটি একটি অবিস্মরণীয়ভাবে ব্যবহৃত ফাইল হয় যা কেবলমাত্র কয়েকবার পুনরায় পড়তে হবে। যদি ত্রুটিটি চলে যায়, বা আপনি সমস্ত ফাইল পড়তে কোনও ত্রুটির মুখোমুখি না হন, এটি কমেছে কিনা তা পরীক্ষা করতে মুলতুবি পরীক্ষা করে দেখুন। যদি এটি থাকে তবে সমস্যাটি পড়ার মাধ্যমে সমাধান করা হয়েছিল।
একাধিক চেষ্টা করার পরে যদি ফাইলটি সফলভাবে পড়া যায় না (যেমন 20) তবে ড্রাইভটি সেক্টরটি পুনরায় তালিকাভুক্ত করার অনুমতি দেওয়ার জন্য আপনার ফাইলটি বা ফাইলের মধ্যে থাকা ব্লকটি ওভাররাইট করা দরকার। অস্থায়ী ফাইলের অনুলিপি করে এবং তারপরে আবার অনুলিপি করে আপনি কেবলমাত্র একটি সেক্টরকে ওভাররাইট করতে ফাইলটিতে (পার্টিশনের চেয়ে) ড্রেসস্কু ব্যবহার করতে পারেন। মনে রাখবেন যে এই মুহুর্তে কেবল ফাইলটি অপসারণ করা একটি খারাপ ধারণা, কারণ খারাপ ক্ষেত্রটি ফ্রি তালিকায় যাবে যেখানে এটি সন্ধান করা আরও কঠিন। সম্পূর্ণরূপে ওভাররাইট করা এটি খুব খারাপ, কারণ আবার সেক্টরগুলি ফ্রি তালিকায় যাবে। আপনার বিদ্যমান ব্লকগুলি আবার লিখতে হবে। notruncবিকল্প ddওয়ান ওয়ে এটা করতে হয়।
যদি আপনার কোনও ত্রুটির মুখোমুখি না হয় এবং মুলতুবি থাকা গণনাটি হ্রাস পায় না, তবে সেক্টরটি অবশ্যই ফ্রিলিস্টে বা ফাইল সিস্টেমের অবকাঠামোর অংশে থাকা উচিত (যেমন একটি ইনোড সারণী)। আপনি সমস্ত খালি জায়গা পূরণ করার চেষ্টা করতে পারেন cat /dev/zero >tempfile, এবং তারপরে মুলতুবি থাকা গণনাটি পরীক্ষা করতে পারেন। যদি এটি কমে যায় তবে সমস্যাটি ফ্রি তালিকায় ছিল এবং এখন দূরে চলে গেছে।
যদি সেক্টরটি অবকাঠামোতে থাকে তবে আপনার আরও একটি গুরুতর সমস্যা রয়েছে এবং আপনি সম্ভবত ডিরেক্টরি ট্রিটিতে হাঁটতে ত্রুটির মুখোমুখি হতে পারেন। এই পরিস্থিতিতে, আমি মনে করি একমাত্র বুদ্ধিমান সমাধান হ'ল ড্রাইভটির পুনরায় ফর্ম্যাট করা প্রয়োজন, প্রয়োজনে ডেটা পুনরুদ্ধারের জন্য optionচ্ছিকভাবে ddrescue ব্যবহার করা।
ড্রাইভে খুব গভীর নজর রাখুন। কয়লা খনিতে সেক্টর রিলোকেশন একটি খুব ভাল ক্যানারি , সম্ভাব্যভাবে আপনাকে ব্যর্থ হওয়া ড্রাইভের প্রাথমিক সতর্কতা দেয় giving প্রাথমিক পদক্ষেপ গ্রহণের পরে আপনি পরবর্তী বিপর্যয়কর এবং অত্যন্ত বেদনাদায়ক ভূমি রোধ করতে পারবেন। আমি প্রস্তাব দিচ্ছি না যে কয়েকটি সেক্টর পুনঃনির্ধারণগুলি আপনার ইচ্ছামত ড্রাইভটি বাতিল করা উচিত। সমস্ত আধুনিক ড্রাইভগুলি কিছুটা পুনর্বিবেচনা করতে হবে। তবে, যদি ড্রাইভটি খুব পুরানো না হয় (<1 বছর) বা আপনি ঘন ঘন নতুন পুনর্বিবেচনাগুলি (> 1 / মাস) পাচ্ছেন তবে আমি আপনাকে এটিকে যথাযথভাবে প্রতিস্থাপন করার পরামর্শ দিচ্ছি।
আমি গবেষণামূলক প্রমাণ এটা প্রমান করতে হবে না, কিন্তু আমার অভিজ্ঞতা বলে যে ডিস্ক সমস্যার একটি সময় একবার পুরো ডিস্ক পড়ার মাধ্যমে কমে যাবে, হয় একটি দ্বারা ddকাঁচা ডিস্কের বা ব্যবহার প্রতিটি ফাইল পড়ার মাধ্যমে find। গত বেশ কয়েকটি বছর আমি প্রায় সমস্ত ডিস্ক সমস্যার মুখোমুখি হয়েছি বিরল-ব্যবহৃত ফাইলগুলিতে, বা খুব বেশি ব্যবহৃত হয় না এমন মেশিনে ped এটি হিউরিস্টিকভাবেও বোঝা যায় যে কোনও সেক্টরটি ঘন ঘন পুনর্বার করা হয় যখন সেক্টরটি সম্পূর্ণ অপঠনযোগ্য না হওয়া পর্যন্ত অপেক্ষা না করে প্রথমে sector সেক্টরটির সাথে একটি ছোটখাটো সমস্যা সনাক্ত করে তখন ড্রাইভটি এটি পুনর্বিবেচনার সুযোগ পায়। ড্রাইভটি কোনও খাত নিয়ে কিছু করার ক্ষমতাশালী না যদি না হোস্ট এটি পড়া বা লিখে বা স্মার্ট পরীক্ষার মাধ্যমে একটির মাধ্যমে এটি কোনওভাবে অ্যাক্সেস না করে।
আমি একটি রাত্রে বা সাপ্তাহিক ক্রোন জব যা পুরো ডিস্কটি পড়ে তার ধারণা নিয়ে পরীক্ষা করতে চাই। বর্তমানে আমি একটি "দরিদ্র লোকের RAID" ব্যবহার করছি যার মধ্যে মেশিনে আমার একটি দ্বিতীয় হার্ড ড্রাইভ রয়েছে এবং আমি প্রতি রাতে মূল ডিস্কটিতে ব্যাকআপ রাখি। কিছু উপায়ে, এটি আসলে RAID মিররিংয়ের চেয়ে ভাল, কারণ যদি আমি ভুল করে কোনও ফাইল বোধ করি এবং মুছে ফেলি তবে আমি তত্ক্ষণাত ব্যাকআপ ডিস্ক থেকে গতকালের সংস্করণটি পেতে পারি। অন্যদিকে, আমি বিশ্বাস করি যে একটি হার্ডওয়্যার রেড কন্ট্রোলার ডিস্কের সমস্যাগুলি প্রকাশের সাথে সাথে পর্যবেক্ষণ, প্রতিবেদন এবং সমাধানের জন্য পটভূমিতে অনেক ভাল কাজ করে। আমার বর্তমান ব্যাকআপ স্ক্রিপ্টটি rsyncপরিবর্তিত হয়নি এমন ডেটা অনুলিপি করা এড়ানোর জন্য ব্যবহার করে, তবে সমস্ত সেক্টরটি পুনরায় পড়ার প্রয়োজনের প্রেক্ষিতে সম্ভবত সমস্ত কিছু অনুলিপি করা ভাল, বা একটি পৃথক স্ক্রিপ্ট রয়েছে যা প্রতি সপ্তাহে পুরো কাঁচা ডিস্ক পড়ে।