সাটা ডিস্কগুলি যে হ্যান্ডেলগুলি লেখার জন্য সঠিকভাবে ক্যাচিং করে?


15

ডাটাবেসের জন্য ব্যবহৃত পৃথক ডিস্কগুলিতে লেখার ক্যাশে অক্ষম করার পরামর্শটি পাওয়া খুব সাধারণ বিষয় কারণ অন্যথায় কিছু ডিস্ক এমন লেখাগুলি স্বীকার করবে যেগুলি এখনও এটি ডিস্ক পৃষ্ঠে তৈরি করে নি।

এর থেকে বোঝা যায় যে কিছু ডিস্কগুলি ডিস্কের পৃষ্ঠে না পৌঁছানো অবধি লেখার স্বীকৃতি দেয় না (আপডেট: বা ক্যাশে ফ্লাশ করতে বললে তারা যথাযথভাবে রিপোর্ট করে such আমি এই জাতীয় ডিস্কগুলি কোথায় খুঁজে পাব, বা কোথায় আমি অনুমোদনমূলক তথ্য সন্ধান করতে পারি) কোথায় এই ধরনের ডিস্ক খুঁজে পেতে?

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


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

উত্তর:


15

সাধারণভাবে বলতে গেলে, আপনার প্রশ্নের প্রত্যক্ষ উত্তরে আমি Sata ড্রাইভের কোনও বড় ব্র্যান্ড সম্পর্কে অবগত নই যে ড্রাইভে নিজেই লেখার ক্যাশে সক্ষম করার সাথে সঠিক ক্রিয়াকলাপের তুলনায় বাগগুলি রয়েছে। এটি, কেবল একটি ড্রাইভের দৃষ্টিকোণ থেকে, ড্রাইভটি ক্যাশেিং দৃষ্টিকোণ থেকে যা করা উচিত তা করে। আমি এটাও লক্ষ্য করেছি যে যে এমনকি যখন লেখার ক্যাশে করা হয় সক্ষম করা থাকে, যে আবর্তিত মিডিয়া শারীরিকভাবে আপডেট করা হচ্ছে সময় SATA কেবলের একটি ডিস্ক লেখার থেকে বিলম্ব এখনও খুব স্বল্প (~ 50 100 মিঃসে সাধারণত করার জন্য) হয়। এটি এমন নয় যে নোংরা ক্যাশে ডেটা কেবল একবারে কয়েক সেকেন্ডের জন্য বসে থাকবে ..... ড্রাইভ ক্রমাগত ক্যাশে থেকে নোংরা ডেটা পাওয়ার চেষ্টা করছেযত তাড়াতাড়ি সম্ভব শারীরিক মিডিয়াতে এটি কেবল ডেটা সুরক্ষার প্রশ্নই নয়, ভবিষ্যতের লেখাগুলি গ্রহণ করতে প্রস্তুত হওয়ার মধ্যে একটির কোনও দেরি না করে (যেমন: পোস্টিং লিখুন)।

ক্যাচিং সক্ষম করার সময় উত্থাপিত সমস্যাটি হ'ল Sata কেবলের মাধ্যমে ড্রাইভে রাইটিং অর্ডার এবং ঘোরানো মিডিয়ায় লেখার আদেশ এক নয়। ক্যাশে সমস্ত বিষয়বস্তু এটিকে ডিস্কে রাখার আগেই আপনার বিদ্যুৎ হ্রাস বা সিস্টেম ক্র্যাশ না হওয়া ছাড়া এটি কখনও সমস্যা সৃষ্টি করতে পারে না। কেন? ->

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

এখন, অবশ্যই ফাইল সিস্টেমের ডিজাইনারগণ, ডাটাবেসগুলি, RAID কন্ট্রোলার ইত্যাদি ক্যাশে লেখার তুলনায় এই ঘটনার বিষয়ে সচেতন (বা অবশ্যই সচেতন হওয়া উচিত)। র্যান্ড ক্যাচিং বেশিরভাগ এলোমেলো অ্যাক্সেসের ধরণ I / O দৃশ্যে পারফরম্যান্সের দিক থেকে অত্যন্ত কাম্য। প্রকৃতপক্ষে, রাইটিং ক্যাচিং উপলব্ধ থাকা আরও উন্নত নেটিভ কমান্ড কুইউংয়ের ( এনসিকিউ) কোনও বাস্তব সুবিধা পেতে সক্ষম হওয়ার মূল উপাদান a) যা নতুন এসটিএ এবং প্যাটা বাস্তবায়নের শেষ কয়েকটি প্রজন্মের সমর্থিত। সুতরাং, এইরকম নির্দিষ্ট জটিল সময়ে ফিজিকাল মিডিয়াকে আদেশের গ্যারান্টি দিতে ফাইল সিস্টেম এবং / অথবা অ্যাপ্লিকেশন ইত্যাদির মাধ্যমে মিডিয়াতে রাইট ক্যাশের ফ্লাশটি বিশেষভাবে অনুরোধ করা যেতে পারে। এই সিঙ্ক অনুরোধটি সম্পূর্ণ হওয়ার পরে - ফাইল বাফার, ওএস ডিস্ক ক্যাচিং, ফিজিক্যাল ডিস্ক ক্যাচিং ইত্যাদির পিছনে থাকা সমস্ত কিছুই সঠিক সমালোচনামূলক ক্রিয়াকলাপে লেনদেনের সিস্টেম ডিজাইন অনুযায়ী মিডিয়াতে প্রকাশিত। এটি হ'ল, যদি প্রোগ্রামাররা শীর্ষে ডান কলগুলি তৈরি করে এবং সফ্টওয়্যার এবং হার্ডওয়্যার স্তরগুলির এই চেইনের প্রতিটি উপাদান সঠিকভাবে তাদের কাজ করে তবে এটি সঠিকভাবে ঘটে। উদাহরণস্বরূপ: ড্রাইভে এই বিষয়ে কোনও বাগ নেই, RAID কন্ট্রোলার, ডিস্ক ড্রাইভার, ওএস ক্যাশে, ফাইল সিস্টেম, ডাটাবেস ইঞ্জিন ইত্যাদি in এটি অনেকগুলি সফ্টওয়্যার যা সকলকে ঠিক সঠিকভাবে কাজ করতে হয়। তদ্ব্যতীত, এই ক্ষেত্রে যথার্থতা যাচাই করা খুব কঠিন কারণ প্রায় কোনও পরিস্থিতিতে সাধারণত লেখার আদেশ কিছুতেই আসে না .... এবং শক্তি ব্যর্থতা এবং ক্রাশের পরিস্থিতিগুলি নির্মাণ করা কঠিন পরীক্ষা। সুতরাং, শেষে এই স্তরটির বিভিন্ন স্তর এবং / বা অর্থগুলির এক বা একাধিকতে "লেখার ক্যাচিং বন্ধ করে দেওয়া" নির্দিষ্ট প্রকারের সমস্যাগুলিকে "ফিক্সিং" করার সুনাম অর্জন করে। ফলস্বরূপ, RAID নিয়ামক বা ওএস ডিস্ক ক্যাশে বা ড্রাইভ ইত্যাদির লেখার ক্যাচিং আচরণ বন্ধ করে দেওয়া সিস্টেমে এক বা একাধিক বাগ এড়ানো হচ্ছে ..... এবং এই জাতীয় লোরের উত্স। এবং শক্তি ব্যর্থতা এবং ক্রাশের পরিস্থিতিগুলি নির্মাণ করা কঠিন পরীক্ষা। সুতরাং, শেষে "লেখনী ক্যাচিং বন্ধ করে" এক বা একাধিক বিভিন্ন স্তর এবং / বা এই শব্দটির অর্থগুলির .... কিছু নির্দিষ্ট ধরণের ইস্যুগুলিকে "ফিক্সিং" করার সুনাম রয়েছে। ফলস্বরূপ, RAID নিয়ামক বা ওএস ডিস্ক ক্যাশে বা ড্রাইভ ইত্যাদির লেখার ক্যাচিং আচরণ বন্ধ করে দেওয়া সিস্টেমে এক বা একাধিক বাগ এড়ানো হচ্ছে ..... এবং এই জাতীয় লোরের উত্স। এবং পাওয়ার ব্যর্থতা এবং ক্রাশের পরিস্থিতিগুলি নির্মাণ করা কঠিন পরীক্ষা। সুতরাং, শেষে "লেখনী ক্যাচিং বন্ধ করে" এক বা একাধিক বিভিন্ন স্তর এবং / বা এই শব্দটির অর্থগুলির .... কিছু নির্দিষ্ট ধরণের ইস্যুগুলিকে "ফিক্সিং" করার সুনাম রয়েছে। ফলস্বরূপ, RAID নিয়ামক বা ওএস ডিস্ক ক্যাশে বা ড্রাইভ ইত্যাদির লেখার ক্যাচিং আচরণ বন্ধ করে দেওয়া সিস্টেমে এক বা একাধিক বাগ এড়ানো হচ্ছে ..... এবং এই জাতীয় লোরের উত্স।

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


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

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

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

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

3

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

স্বল্প দামের ওপটিনের জন্য, আপনি একটি সস্তা ইউপিএস ব্যবহার করতে পারেন যা আপনার সিস্টেমটিকে একটি সুশৃঙ্খল শাটডাউন করার জন্য সংকেত দিতে পারে।


উপরের আমার মন্তব্যটি এখানে যুক্ত করা উচিত ছিল। আমি এখনও এই সাইট শিখছি।
এএস

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

আমার স্বীকৃত ছোট টেস্টের পরীক্ষাগুলিতে (এলএসআই 9261 রেড কন্ট্রোলাররা, সটা, এনএল এসএএস এবং এসএএস ড্রাইভ), আমি দেখতে পেয়েছি যে ড্রাইভটি যখন ব্যাটার / ক্যাপাসিটি ব্যাকড ক্যাশের সাথে একটি রেড কন্ট্রোলারের সাথে সংযুক্ত থাকে তখন ড্রাইভ লেখার ক্যাশে সক্ষম করে, এতে কোনও পার্থক্য হয় না to উপরোক্ত পারফরম্যান্সে কেবলমাত্র RAID নিয়ামক ক্যাশে রয়েছে। আমি এখনও এটি বলি না যে এটি একটি কঠোর এবং দ্রুত নিয়ম, তবে এটি আমার কাছে স্পষ্টভাবে স্পষ্ট যে RAID নিয়ামকটি ড্রাইভের ক্যাশে অক্ষম করা অগত্যা কোনও সমস্যা নয়।
ড্যানিয়েল লসন

2

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

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


2

ডিস্কটি ক্যাশে ফিরে লিখলে একটি ভ্রান্ত ধারণা হ'ল তারা কেবল বিদ্যুতের ক্ষয়ক্ষতির ডেটা হারাবে। এটি সর্বদা ক্ষেত্রে হয় না, বিশেষত SATA ডিভাইসে। যদি কোনও Sata ডিভাইসে এর মধ্যে ত্রুটি থাকে (যেমন একটি কর্নার কেস এফডাব্লু বাগ বা কন্ট্রোলার বাগ) এবং এটি পুনরায় সেট করা হয় বা বাহ্যিকভাবে পুনরায় সেট করা হয় তবে হ্যাং-এর পরে লিখিত ব্যাক ক্যাশে থাকা ডেটা এখনও পাওয়া যায় এমন কোনও গ্যারান্টি নেই।

এটি এমন পরিস্থিতিতে তৈরি করতে পারে যেখানে কোনও ডিভাইসে ক্ষণস্থায়ী ত্রুটি থাকে, পুনরায় সেট হয়ে যায়, কোনও নোংরা ক্যাশের ক্ষতিতে ডেটা ক্ষতি হয় এবং এটি ড্রাইভারের ব্লক স্তরের উপরে নীরব।

সবচেয়ে খারাপ বিষয়, ওএস সরঞ্জামগুলির মাধ্যমে ড্রাইভ ক্যাশে অক্ষম করা ডিভাইস পুনরায় সেট করাগুলিতেও হারিয়ে যাবে, সুতরাং ডিভাইসটি পুনরায় সেট করা থাকলে, ডিভাইসটি পুনরায় সেট করা থাকলে, এটি লিখন-ব্যাক ক্যাচিংটিকে পুনরায় সক্ষম করবে। অন্য রিসেটে, ডিভাইসটি তখন ডেটা হারাবে।

এসসিএসআই / এসএএস ড্রাইভ এবং কিছু স্যাটায় ড্রাইভে রাইট-ব্যাক প্রোফাইলের অবস্থা সংরক্ষণ করার ক্ষমতা রয়েছে যাতে নিশ্চিত হয়ে যায় যে পুনরায় সেটগুলি সম্পত্তি হারাচ্ছে না - তবে বাস্তবে এটি খুব কমই ব্যবহৃত হয়।

RAID কন্ট্রোলারগুলি যা ব্লক স্তরটিকে উপরের স্তরের সাথে একীভূত করে তারা ড্রাইভের পুনরায় সেটগুলি লক্ষ্য করতে পারে এবং আবার রাইট-ব্যাক ক্যাশে অক্ষম করতে পারে - তবে মানক SATA এবং SAS নিয়ামকরা এটি করবে না।

এই সীমাবদ্ধতা অন্যান্য সেট বৈশিষ্ট্য এবং অনুরূপ পরামিতিগুলির জন্যও যায় যা কার্য সম্পাদন এবং নির্ভরযোগ্যতার জন্য কনফিগার করা হয়।


1

আপনি যেমনটি বলেছেন, একটি যথাযথ ব্যাটারি ব্যাকড রেড কন্ট্রোলার ব্যয়বহুল হবে তবে আপনি ইবেতে ডেল পার্ক 5 / আই কন্ট্রোলারগুলি 100 ডলার (150 ডলার) এবং বিশেষত রেড 5 এর সাহায্যে পার্ক 5 / i এর মতো একটি নিয়ামকের গতি আপনাকে বিস্মিত করতে পারবেন। আমার পার্ক 5 / ইজ এবং ছয় ডিস্ক RAID5 অ্যারে সহ বেশ কয়েকটি সার্ভার রয়েছে এবং সেগুলি আমার দেখা দ্রুততম ডিস্কগুলির মধ্যে একটি। বিশেষত ডাটাবেস অ্যাপ্লিকেশনগুলির জন্য দ্রুত ডিস্কগুলি কার্যকারিতা উন্নত করে।

আমি বুলেট কামড়াতাম এবং একটি RAID নিয়ামক কিনতাম।

জেআর


1

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

এটি লক্ষ্য করা উচিত, যদি ড্রাইভগুলি রাইটব্যাক ক্যাশে ভরে যায় তবে ড্রাইভে ক্যাশে লেখা না হওয়া পর্যন্ত লেখাগুলি ব্লক হয়ে যাবে। এর অর্থ এই যে ক্যাশে সাধারণত টেকসই লেখার ক্ষেত্রে কার্যকর হয় না।

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


আমি এখন যা পরীক্ষা করছি তা হ'ল আমাদের অ্যাপ্লিকেশনটির পারফরম্যান্স খামটি নির্ধারণ করা যাতে আমরা কীভাবে সেরা স্কেল আপ এবং আউট করতে পারি তা নির্ধারণ করতে পারি। ড্রাইভের ক্যাশে তুলনামূলকভাবে ছোট হতে পারে তবে এতে লেখার ক্যাশে দেওয়ার সাথে ড্রাইভটি রাইটসকে পুনরায় অর্ডার করার ক্ষমতা দেয় (যখন উপযুক্ত হয়), যা দেখে মনে হয় এটি টেকসই রাইটিং থ্রুপুট দ্বিগুণ করতে পারে।
এএস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.