আমি লক্ষ্য করেছি যে এক্সএফএস সিস্টেম বুট-এ কোনও fsck প্রয়োগ করে না এবং জার্নালিং ফাইল-সিস্টেমগুলির একটি কারণ যে ফাইল-সিস্টেমটি একটি অশুভ শাটডাউন করার পরে ফাইল-সিস্টেমের সুসংগত অবস্থায় রয়েছে তা নিশ্চিত করতে সহায়তা করে; পরবর্তী মাউন্টে (যেমন পুনরায় বুট করার পরে) জার্নালটি পুনরায় খেলানো হয়।
অশুচি বন্ধের পরেও কি এখনও একটি fsck প্রয়োজন এবং কেন?
উত্তর:
"জার্নালড ফাইল সিস্টেমস" এর সাধারণ প্রসঙ্গে আমি এর উত্তর দিচ্ছি।
আমি মনে করি আপনি যদি খুব শীঘ্রই বা পরে বেশ কয়েকটি "অপরিষ্কার শাটডাউন" করেন ( পাওয়ার কর্ড বা কোনও কিছু টেনে ) করে থাকেন তবে আপনি এমন একটি ফাইল সিস্টেমের fsckস্থানে পৌঁছাতে চাইবেন যা fsck এর নৈতিক সমতুল্য হবে xfs_repair। ext4অধিকাংশ অংশ জন্য আমার ল্যাপটপে fileystsm শুধু যে রিবুট উপর জার্নাল রিপ্লেতে, পরিষ্কার হরতালের অন্তর্ভুক্ত, কিন্তু যে একটি সময় একবার, এটি একটি সম্পূর্ণ অন করে fsck।
তবে নিজেকে জিজ্ঞাসা করুন "জার্নালটি রিপ্লে করা" কী সম্পাদন করে। একটি জার্নাল পুনরায় প্লে করা কেবল নিশ্চিত করে যে বাকী ফাইল সিস্টেমের ডিস্কব্লকগুলি জার্নালের প্রবেশের ক্রমের সাথে মিল রয়েছে। একটি জার্নাল পুনরায় প্লে করা একটি ছোট fsckবা সম্পূর্ণ অংশের সমান fsck।
আমি মনে করি হাতে কিছু মৌখিক ঘুম চলছে: একটি জার্নাল পুনরায় খেলানো traditionalতিহ্যগত কাজগুলির অংশ fsckকরে এবং xfs_repairঠিক একই ধরণের প্রোগ্রাম যা e2fs.fsck(বা অন্য কোনও ফাইল সিস্টেমের fsck) তা is এক্সএফএসের লোকেরা কেবল বিশ্বাস করেছে বা তাদের অভিজ্ঞতা তাদেরকে xfs_repairপ্রতিটি বুটে চালিত না করে কেবল জার্নালটি পুনরায় খেলতে পরিচালিত করে।
fsck'পেডেন্টিক' নয়। আমি একটি ext3 LVMপার্টিশনকে রূপান্তরিত করেছি ext4এবং 'ext4_mb_generate_buddy' ত্রুটিগুলি কারণ, যেমন আমি বুঝতে পেরেছি, কোডটিতে থাকা একটি বাগে ext4অন ডিস্কে বিভ্রান্তির কারণ হয়ে গেছে এবং রূপান্তরিত 'LVM' পার্টিশনে বিটম্যাপের মেমরি অনুলিপি তৈরি করতে শুরু করেছে। আমি যতদূর বলতে পারি fsck, কোনও দুর্নীতি হয়নি। সমাধানটি হ'ল UNINIT_BGবিকল্পটি বন্ধ করা বা ডেটা স্থানান্তর এবং পার্টিশনটিকে পুনরায় নতুনকরণ হিসাবে ext4; আমি উত্তরোত্তর কোর্স গ্রহণ। তবে আমি এখনও মনে করি যে কয়েক মিনিটের জন্য অপেক্ষা করা fsckডেটা হারানো উপযুক্ত নয়!
অপরিষ্কার শাটডাউন করার পরে ফাইল-সিস্টেমটি সুসংগত অবস্থায় রয়েছে তা নিশ্চিত করতে সহায়তা করুন
নোটের প্রথম বিষয়টি হ'ল এক্সএফএস, রিসার এবং সর্বাধিক কনফিগারেশনগুলি কেবল মেটা-ডেটা জার্নাল্লিং বাস্তবায়ন করে, যা fsck এড়ানো সম্পর্কে। জার্নালটি সর্বদা শুরুতে পুনরায় প্লে করা হয় না - এটি অসম্পূর্ণ থাকলে তা বাতিল করা যেতে পারে।
এমন সিস্টেম রয়েছে যা সম্পূর্ণ ডেটা জার্নালিংকে সমর্থন করে - তবে বাস্তবে বিশ্বস্ত দৃশ্যের ক্ষেত্রে মেটা-ডেটা জার্নালিংয়ের মাধ্যমে এগুলি আশ্বাসের মাত্রা দেয় practice
সুতরাং একটি 'বেমানান রাষ্ট্র' এবং fsck দ্বারা সংশোধন করা সমস্যাগুলি হ'ল মেটা-ডেটা এবং ফাইলগুলির মধ্যে মেলে না। এটি এড়াতে ওএস জার্নালে প্রস্তাবিত মেটা ডেটা পরিবর্তনের কথা লিখে দেয়, তারপরে আসল ডেটাটি ডিস্কে লিখে, তারপরে মেটা ডেটা পরিবর্তনগুলি প্রয়োগ করে যা জার্নালে ডিস্কে প্রতিলিপি করা হয়। এটির সাথে একমাত্র ধরা হ'ল ডিস্ক নিয়ামকটি অনুরোধগুলিকে বাফার এবং সম্ভাব্য পুনঃক্রম করতে হবে। এটি এড়াতে, বেশিরভাগ জার্নালিং ফাইল সিস্টেমগুলি বাধা প্রয়োগ করে: তারা প্রতিটি অপারেশন পৃথক করে এবং ডিস্কটি অপারেশনটি সম্পন্ন করেছে তা স্বীকার করার জন্য অপেক্ষা করে। কিন্তু অনেক আধুনিক ডিস্কগুলি ডেটা প্রতিশ্রুতি দেওয়ার আগেই লেখার সমাপ্তি স্বীকার করে। সুতরাং, জিনিসগুলি অগোছালো হতে পারে।
একটি fsck এখনও অপরিষ্কার বন্ধ এবং কেন পরে প্রয়োজন
বেশিরভাগ ফাইল সিস্টেমগুলি একটি মাউন্ট গণনা বজায় রাখে - একবার এই গণনাটি শেষ হয়ে গেলে, একটি সম্পূর্ণ fsck ডিস্কে মাউন্ট করার পরবর্তী প্রয়াসে ট্রিগার করা হবে। ডিস্ক ডেটা হওয়ার কারণটি এমনকি সফ্টওয়্যারটিতে বাগ ছাড়াও স্পষ্টভাবে লিখিত না হয়েও দূষিত হতে পারে। উপরের সিউসির মন্তব্যটি ভুল।
hdparm -W) সক্ষম না করেন , তবে ডিস্কটি মাঝারি না হওয়া পর্যন্ত লেখার অনুরোধগুলি সম্পূর্ণ করে না। কেন আপনি মনে করেন যে বিকল্পটি বিদ্যমান? বাধা একাধিক অনুরোধ জারি করা হলে পুনরায় অর্ডার করতে বাধা দেয়। কোনও বাধা ছাড়াই, পূর্ববর্তীগুলি সম্পূর্ণ না হওয়া অবধি fs কেবল আরও অনুরোধ দেয় না, এইভাবে বাধা ছাড়াই ক্রম বজায় রাখা হয় ... তবে শর্ত থাকে যে ডিস্ক লেখার ক্যাশে সক্ষম না থাকে। বাধাগুলির উদ্দেশ্য হ'ল লেখাগুলি ক্যাশে সক্ষম করার অনুমতি দেওয়া, কোনও ক্র্যাশে Fs ক্ষতিগ্রস্থ না করে।
sync। ক্সদস্ন. বাধা ছাড়াই ডিস্কে লেখার প্রক্রিয়াটি হ'ল জার্নালে লিখতে হবে sync, এভাবে কোনও লেখার ক্যাশে ফ্লাশ করে, তারপরে আসল ডেটা লিখুন। এটি নিশ্চিত করে যে জার্নালটি সর্বদা ক্রাশের পরে এফএস পুনরুদ্ধার করতে ব্যবহৃত হতে পারে তবে সিঙ্কিং জিনিসকে ধীর করে দেয় এবং অর্ধেকটি লেখার ক্যাশের উদ্দেশ্যকে পরাস্ত করে। সুতরাং বাধাগুলি আরও ভাল প্রতিস্থাপন হিসাবে যুক্ত করা হয়েছিল syncএবং সঠিক ডিস্ক সমর্থন সহ, তারা নিরাপদে সিঙ্কিংটি গ্রহণ করে এমন অনেক কার্য সম্পাদন করতে পারে।
কেবল একটি অশুচি শাটডাউন করার কারণে জার্নালিং ফাইল সিস্টেমকে এফএসকে করার দরকার নেই।
সমগ্র মেটাডেটা জার্নালিং এর রানটাইম কর্মক্ষমতা শাস্তি স্থায়ী কারণ তা নিশ্চিত করার জন্য ফাইল সিস্টেম স্বয়ংক্রিয়ভাবে পরবর্তী উপর মেটাডেটা লগ replaying মাউন্ট, যদি ফাইলসিস্টেম পরিচ্ছন্নভাবে আনমাউন্ট ছিল না আবার 100% সামঞ্জস্যপূর্ণ তৈরি করা যেতে পারে।
fsck এর একমাত্র ভূমিকা মেটাডেটা ধারাবাহিকতা নিশ্চিত করা, সুতরাং ফাইলসিস্টেমটি সঠিকভাবে আনমাউন্ট না হওয়ার কারণে fsck চালানো বাড়াবাড়ি।
একটি জার্নালিং ফাইল সিস্টেম অন্যান্য কারণে দূষিত হতে পারে, যদিও - হার্ডওয়্যার ব্যর্থতা, ড্রাইভার বাগ, অ্যাডমিন ত্রুটি ইত্যাদি, তাই fsck সরঞ্জাম অবশ্যই প্রয়োজনীয়। কেবলমাত্র একটি অশুচি শাটডাউনের কারণে তাদের ডাকে যাওয়ার কোনও কারণ নেই।