বাধা সহ এসএটিএ ড্রাইভে ক্যাশে লেখার সুরক্ষা


13

আমি স্যাটা ড্রাইভ সম্পর্কিত ক্যাচিং, এনসিকিউ, ফার্মওয়্যার বাগ, বাধা ইত্যাদি ইত্যাদির বিষয়ে ইদানীং পড়ছি এবং আমি নিশ্চিত নই যে কোন শক্তি সেটিংসের ক্ষেত্রে আমার ডেটা সুরক্ষিত করবে সেরা সেটিংস।

যা আমি বুঝতে পেরেছি, এনসিকিউ ড্রাইভকে লেখাগুলি পুনরায় অর্ডার করতে পারফরম্যান্স অনুকূল করতে, কার্নেলটি জানিয়ে রাখে যে কোন অনুরোধগুলি শারীরিকভাবে লিখিত হয়েছে।

ক্যাশে লেখার ফলে ড্রাইভটি একটি অনুরোধটি আরও দ্রুত সরবরাহ করে, কারণ এটি দৈহিক ডিস্কে ডেটা লেখার জন্য অপেক্ষা করে না।

আমি নিশ্চিত না কীভাবে এখানে এনসিকিউ এবং লিখিত ক্যাশে মিশ্রিত হয় ...

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

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

তারপরে ফার্মওয়্যার বাগ সহ ড্রাইভ রয়েছে বা ডেটা শারীরিকভাবে কখন লিখিত হয়েছে তা ইচ্ছাকৃতভাবে মিথ্যা বলে।

এটি বলার পরে .. ড্রাইভ / ফাইল সিস্টেম সেটআপ করার বিভিন্ন উপায় রয়েছে: ক) এনসিকিউ এবং লিখিত ক্যাশে অক্ষম খ) জাস্ট এনসিকিউ সক্ষম সি) কেবল লিখুন ক্যাশে সক্ষম ডি) এনসিকিউ এবং লিখিত ক্যাশে উভয়ই সক্ষম

আমি মনে করি যে বাধাগুলি সক্ষম হয়েছে .. বিটিডাব্লু, কীভাবে তারা কীভাবে সক্ষম হয় তা পরীক্ষা করতে হবে?

বিদ্যুৎ হ্রাসের ক্ষেত্রে, সক্রিয়ভাবে ডিস্কে লেখার সময়, আমার অনুমান যে বিকল্প বি (এনসিকিউ, কোনও ক্যাশে নেই) নিরাপদ, ফাইল সিস্টেম জার্নাল এবং ডেটা উভয়ের জন্যই। পারফরম্যান্স পেনাল্টি হতে পারে।

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

আমার প্রশ্নটি অবশ্য দাঁড়িয়ে আছে ... আমি কি কিছু মিস করছি? আমলে নেওয়ার জন্য অন্য কোনও পরিবর্তনীয় আছে কি? এমন কোনও সরঞ্জাম রয়েছে যা এটি নিশ্চিত করতে পারে এবং আমার ড্রাইভগুলি তাদের মতো আচরণ করা উচিত?


আপনার পরিস্থিতিতে আবেদন কি? আপনি সেটআপে কোনও RAID নিয়ামক এবং এর ক্যাশের প্রভাব বা প্রভাব উপেক্ষা করছেন। আপনি কোন অপারেটিং সিস্টেমকেও ফোকাস করছেন? আপনি কোন ফাইল সিস্টেম বিবেচনা করছেন?
ew white

নির্দিষ্ট কোন অ্যাপ্লিকেশন নেই। আমি বছরের পর বছর ধরে সফ্টওয়্যার রাইড 1 ব্যবহার করে আসছি, তবে ক্যাশে লেখার সমস্যাটি কখনই উপস্থাপন করবেন না। এছাড়াও, বিটিআরএফএসে সন্ধান করা, যার জন্য এখনও কোনও নির্ভরযোগ্য fsck নেই, আমাকে প্রশ্ন তোলে যে আমি দুর্নীতি রোধ করতে কী করতে পারি, যদি আমি এটি ব্যবহার করি তবে।
জুলিয়ানজম

1
পরিবর্তে লিনাক্সে জেডএফএস এবং উদ্দেশ্য-নির্মিত ZIL ডিভাইস সহ দম্পতি ব্যবহার করুন। আমি ব্যবহার DDRDrive ZFS সিস্টেমের জন্য :)
ewwhite

আপনি কি ফুয়েসের সাথে জেডএফএস ব্যবহার করছেন?
জুলিয়ানজম

2
ইউপিএস পেতে ভুলবেন না।
মাইকেল হ্যাম্পটন

উত্তর:


11

স্ট্রেইট আপ এন্টারপ্রাইজ সিস্টেমগুলির জন্য, স্টোরেজ অ্যাডাপ্টারের আকারে (প্রায় সবসময় একটি RAID কার্ড) আকারে একটি অতিরিক্ত স্তর থাকে যার উপরে ক্যাশের আরও একটি স্তর বিদ্যমান। সেখানে সংগ্রহস্থলে বিমূর্ততা অনেকটা এই দিন গাদা, এবং আমি একটি ব্লগ সিরিজ আমি করেনি এই গভীর বিস্তারিত ঢুকে জানেন তাঁরা আপনার ইনপুট / আউটপুট

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

নির্দিষ্ট এন্টারপ্রাইজ এসএসডিগুলিতে পুরোপুরি বিদ্যুতটি নেমে যাওয়ার আগে চালকচালিত ক্যাশে প্রতিশ্রুতি দেওয়ার জন্য পর্যাপ্ত ওম্প সহ একটি বোর্ডের ক্যাপাসিটার অন্তর্ভুক্ত থাকে।

আপনি যদি মাদারবোর্ডের সাথে সরাসরি সংযুক্ত ডিস্ক সহ এমন একটি সিস্টেমের সাথে কাজ করছেন তবে আশ্বাস কম রয়েছে। ডিস্কগুলি নিজেরাই লেখার ক্যাশে প্রতিশ্রুতিবদ্ধ না করার ক্ষমতা রাখে তবে একটি শক্তি ব্যর্থতা প্রকৃতই ক্ষতির কারণ হতে পারে। এটা শুধু এই ব্যর্থতা মোড বেঁচে থাকার জন্য অক্ষমতা কারণে অবিশ্বস্ততা জন্য একটি খ্যাতি অর্জন ফাইলসিস্টেম; এটি ইঞ্জিনিয়ারড স্টোরেজ টিকে থাকার সাথে পূর্ণ আপ এন্টারপ্রাইজ সিস্টেমগুলিতে চালনার জন্য ডিজাইন করা হয়েছিল।

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

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

আপনি এন্টারপ্রাইজ-গ্রেড ড্রাইভগুলি ব্যবহার করে যা আরও বেশি বৈধতা পায় (এবং আপনার অনুমিত ওয়ার্কলোডের নিদর্শনগুলির তুলনায় পরীক্ষা করা হয়) ব্যবহার করে এবং আপনার স্টোরেজ সিস্টেমটি ডিজাইন করে যাতে এ ধরনের অসত্যগুলি থেকে বাঁচতে পারে আপনি ফার্মওয়্যার ঝুঁকি নিয়ে আশ্রয় নিতে পারেন।


আমি বুঝতে পেরেছি যে হার্ডওয়্যার র‌্যাডের অধীনে ক্যাচিং করা আশা করা উচিত (আশা করি ব্যাটারি ব্যাকড) এবং আসল ডিস্ক ক্যাশে অক্ষম করা বাঞ্ছনীয়। আমার ক্ষেত্রে (এটি উল্লেখ করা হয়নি) আমি সফ্টওয়্যার রাইড ব্যবহার করছি। দেখে মনে হচ্ছে লিখিত ক্যাশে প্রস্তাবিত নয় কারণ এটি ডেটা ক্ষতিগ্রস্থ করবে। হতে পারে বিপর্যয়কর (ফাইল সিস্টেমের দুর্নীতি) নয়, তবে তথ্যের ক্ষতি হয় loss আমি আপাতত আমার সফটরেড 1 + এক্সট 4 থেকে বিটিআরএস + রেড 1 এ স্থানান্তরিত করা থেকে বিরত থাকব। :)
জুলিয়ানজম

RAID এটির সাহায্য করে না, যেহেতু ডেটা উভয় ড্রাইভে সহজেই একটি ড্রাইভ হিসাবে ক্যাশে লিখতে পারে।
psusi

@psusi এটি একটি 100% প্রশমন নয়, তবে এটি অতিরিক্ত সুরক্ষা সরবরাহ করে। এটি একটি সময় সমস্যা। স্বতন্ত্র RAID প্রয়োগগুলি পৃথক হয়।
sysadmin1138

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

3

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


আমি মনে করি বাধাগুলি আপনাকে জার্নাল দুর্নীতির হাত থেকে রক্ষা করে (যদি ফাইল সিস্টেমটি অনুরোধ করে) তবে আমি ফাইলগুলির প্রকৃত ডেটা সম্পর্কে নিশ্চিত নই ... প্রতিটি লেখার পরে একটি ক্যাশে ফ্লাশ প্রদান করলে লেখার ক্যাশে অকেজো হয়ে যায়, তাই না? ?
জুলিয়ানজম

@ জুলিয়ানজম, অবশ্যই ... এনসিকিউ বা ড্রাইভ রাইট ক্যাশে ছাড়াই বা ছাড়াই ক্যাশেড ফাইল ডেটা সর্বদা ক্রাশ হওয়ার ঘটনায় হারিয়ে যায়।
psusi
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.