SATA डिस्क जो हैंडल लिखती है कैशिंग ठीक से?


15

डेटाबेस के लिए उपयोग किए जाने वाले व्यक्तिगत डिस्क पर राइट कैश को अक्षम करने के लिए सलाह देना बहुत आम है क्योंकि अन्यथा कुछ डिस्क ऐसे लेखों को स्वीकार करेंगे जो अभी तक डिस्क की सतह पर नहीं बने हैं।

इसका मतलब यह है कि कुछ डिस्क स्वीकार नहीं करते हैं जब तक कि वे इसे डिस्क की सतह पर नहीं बनाते (अपडेट: या वे कैश को फ्लश करने के लिए कहने पर सही रिपोर्ट करते हैं। मुझे ऐसे डिस्क कहां मिल सकते हैं, या मैं आधिकारिक जानकारी कहां देख सकता हूं। कहाँ पर इस तरह के डिस्क को खोजने के लिए?

मैं कुछ DB सर्वर स्थापित कर रहा हूं जो वास्तव में कैशिंग का उपयोग करने से लाभान्वित होंगे, लेकिन एप्लिकेशन मूल्य संवेदनशील है और मैं कुछ कैशिंग RAID नियंत्रक के लिए अपने डिस्क सबसिस्टम की लागत को दोगुना नहीं करूंगा क्योंकि मुझे पर्याप्त जानकारी नहीं है मुझे पता है कि क्या मैं प्रत्येक ड्राइव में कैश पर भरोसा कर सकता हूं।


linux, hdparam के माध्यम से ड्राइव के आधार पर ड्राइव पर राइट कैश को अक्षम करने की अनुमति देता है। SATA ड्राइव्स के लिए, मेरा मानना ​​है कि इसे हर रीस्टार्ट पर फिर से लागू करना होगा। मैं इस तरह से जा सकता हूं अगर मैं अभी भी एक बैटरी समर्थित RAID नियंत्रक का उपयोग किए बिना हमारी संपूर्ण आवश्यकताओं को मार सकता हूं। मैं सॉफ्टवेयर का उपयोग करना पसंद करता हूं जब संभव हो तो सरल और सस्ता होने के बाद। किसी भी तरह, मैं निश्चित रूप से एक यूपीएस होगा।
ईएएस

जवाबों:


15

सामान्यतया, आपके प्रश्न के सीधे उत्तर में, मुझे SATA ड्राइव के किसी भी प्रमुख ब्रांड के बारे में पता नहीं है कि ड्राइव में स्वयं ही कैशिंग लिखने के साथ उचित संचालन के लिए बग हैं। यही है, केवल ड्राइव के नजरिए से, ड्राइव वह करता है जो उसे कैशिंग के नजरिए से करना चाहिए। मैं यह भी ध्यान रखें होता है कि यहां तक कि जब लिखने कैशिंग है सक्षम, कि घूर्णन मीडिया शारीरिक रूप से अपडेट किया जा रहा करने के लिए SATA केबल पर एक डिस्क लिखने से देरी अभी भी बहुत ही कम (~ 50 100ms आम तौर पर करने के लिए) है। ऐसा नहीं है कि गंदे कैश डेटा एक समय में केवल सेकंड के लिए बैठे रहेंगे ..... ड्राइव लगातार कैश से गंदे डेटा प्राप्त करने की कोशिश कर रहा हैजितनी जल्दी हो सके भौतिक मीडिया पर। यह सिर्फ डेटा सुरक्षा का सवाल नहीं है, बल्कि भविष्य में बिना किसी देरी के राइट्स को स्वीकार करने के लिए तैयार होने का मतलब है (यानी: पोस्ट लिखना)।

कैशिंग सक्षम होने पर जो समस्या उत्पन्न होती है, वह यह है कि SATA केबल पर ड्राइव करने के लिए लिखने का क्रम और घूर्णन मीडिया के लिए लेखन आदेश समान नहीं है। यह कभी भी समस्या का कारण नहीं बन सकता है क्योंकि कैश की सभी सामग्री को डिस्क में करने से पहले आपको बिजली की हानि होती है या सिस्टम क्रैश होता है। क्यों? ->

यहां जो समस्या उत्पन्न हो सकती है, वह फाइल सिस्टम और / या डेटाबेस फाइल कंटेंट की ट्रांजेक्शन मजबूती से संबंधित है, जो खोए हुए राइट्स में से हैं। वास्तव में, जो संभावित रूप से आउट ऑफ ऑर्डर लिखते हैं, वे सैद्धांतिक रूप से लेन-देन के तर्क की अखंडता को भ्रष्ट कर सकते हैं जो अन्यथा मीडिया द्वारा बहुत ही विशिष्ट क्रम में होने वाली डिस्क द्वारा गारंटी दी गई होती हैं।

अब, निश्चित रूप से, फ़ाइल सिस्टम के डिज़ाइनर, डेटाबेस, RAID नियंत्रक आदि कैशिंग लिखने के लिए इस घटना के संबंध में जागरूक (या निश्चित रूप से जागरूक होने चाहिए) हैं। अधिकांश यादृच्छिक अभिगम प्रकार I / O परिदृश्यों में प्रदर्शन के दृष्टिकोण से लेखन कैशिंग अत्यंत वांछनीय है। वास्तव में, लेखन कैशिंग उपलब्ध होना एक अधिक महत्वपूर्ण मूल कमांड कमांडर ( NCQ) के लिए किसी भी वास्तविक लाभ के लिए सक्षम होने का एक महत्वपूर्ण तत्व है।) जो नए SATA और PATA कार्यान्वयन की अंतिम कुछ पीढ़ियों पर समर्थित है। इसलिए, ऐसे कुछ महत्वपूर्ण समय में भौतिक मीडिया को आदेश की गारंटी देने के लिए, फ़ाइल सिस्टम और / या एप्लिकेशन, आदि विशेष रूप से मीडिया के लिए लेखन कैश के एक फ्लश का अनुरोध कर सकते हैं। इस सिंक रिक्वेस्ट के पूरा होने पर - (संभावित) फाइल बफ़र्स, OS डिस्क कैशिंग, फिजिकल डिस्क कैशिंग आदि से लंबित सब कुछ सही क्रिटिकल ऑपरेशंस में ट्रांजैक्शन सिस्टम डिज़ाइन के अनुसार मीडिया पर होता है। यही है, यह सही ढंग से होता है यदि प्रोग्रामर शीर्ष पर सही कॉल (ओं) को बनाते हैं और सॉफ्टवेयर और हार्डवेयर परतों की इस श्रृंखला के प्रत्येक तत्व ने अपना काम सही ढंग से किया। यानी: इस संबंध में ड्राइव, RAID नियंत्रक, डिस्क ड्राइवर, ओएस कैश, फ़ाइल सिस्टम, डेटाबेस इंजन, आदि में कोई कीड़े नहीं हैं। यह बहुत से सॉफ्टवेयर है जो सभी को बिल्कुल सही काम करना है। इसके अतिरिक्त, इस संबंध में सत्यता की पुष्टि करना बहुत मुश्किल है क्योंकि लगभग किसी भी स्थिति में आम तौर पर लिखने का क्रम बिल्कुल भी मायने नहीं रखता है .... और बिजली की विफलता और क्रैश परिदृश्य निर्माण के लिए कठिन परीक्षण हैं। इसलिए, इस शब्द की एक या अधिक परतों और / या अर्थों में "राइट कैशिंग बंद करें" .... कुछ प्रकार के मुद्दों को "ठीक करने" की प्रतिष्ठा है। वास्तव में, RAID नियंत्रक या OS डिस्क कैश, या ड्राइव, आदि के लेखन कैशिंग व्यवहार को बंद करने से सिस्टम में एक या अधिक बग से बचा जा रहा है ..... और ऐसे विद्या के स्रोत। और बिजली की विफलता और क्रैश परिदृश्य निर्माण के लिए कठिन परीक्षण हैं। इसलिए, इस शब्द की एक या अधिक परतों और / या अर्थों में "राइट कैशिंग बंद करें" .... कुछ प्रकार के मुद्दों को "ठीक करने" की प्रतिष्ठा है। वास्तव में, RAID नियंत्रक या OS डिस्क कैश, या ड्राइव, आदि के लेखन कैशिंग व्यवहार को बंद करने से सिस्टम में एक या अधिक बग से बचा जा रहा है ..... और ऐसे विद्या के स्रोत। और बिजली की विफलता और क्रैश परिदृश्य निर्माण के लिए कठिन परीक्षण हैं। इसलिए, इस शब्द की एक या अधिक परतों और / या अर्थों में "राइट कैशिंग बंद करें" .... कुछ प्रकार के मुद्दों को "ठीक करने" की प्रतिष्ठा है। वास्तव में, RAID नियंत्रक या OS डिस्क कैश, या ड्राइव, आदि के लेखन कैशिंग व्यवहार को बंद करने से सिस्टम में एक या अधिक बग से बचा जा रहा है ..... और ऐसे विद्या के स्रोत।

वैसे भी, प्रश्न के मूल में वापस आना: एसएटीए के तहत, सभी डिस्क रीड / राइट कमांड के विशिष्ट हैंडलिंग और फ्लश कैश कमांड SATA विनिर्देशों द्वारा अच्छी तरह से परिभाषित किए जाते हैं । इसके अतिरिक्त, ड्राइव मैन्युफैक्चरर्स के पास प्रत्येक ड्राइव मॉडल या ड्राइव परिवार के लिए विस्तृत दस्तावेज़ीकरण होना चाहिए, जो सीगेट बाराकुडा ड्राइव के लिए इस तरह के नियमों के कार्यान्वयन और अनुपालन का वर्णन करता है। विशेष रूप से, SATA SET फीचर्स का विवरण देखेंकमांड जो ड्राइव ऑपरेशनल मोड को नियंत्रित करता है और विशेष रूप से विकल्प 82h का उपयोग ड्राइव स्तर पर डिस्क कैशिंग को अक्षम करने के लिए किया जा सकता है क्योंकि डिफ़ॉल्ट निश्चित रूप से उन सभी ड्राइवों पर सक्षम कैशिंग लिखना है जिनके बारे में मुझे पता है। यदि आप वास्तव में कैश को अक्षम करना चाहते हैं, तो यह कमांड प्रत्येक ड्राइव रीसेट या पावर अप के प्रारंभ में किया जाना है और आमतौर पर आपके ऑपरेटिंग सिस्टम के लिए डिस्क ड्राइवरों के नियंत्रण में है। आप अपने OS ड्राइवर को IOCTL और / या रजिस्ट्री सेटिंग प्रकार के माध्यम से इस मोड को सेट करने के लिए प्रोत्साहित करने में सक्षम हो सकते हैं, लेकिन यह व्यापक रूप से भिन्न होता है।


5
मेरे जवाब के लिए एक संपादकीय नोट: हार्डवेयर RAID कंट्रोलर कई प्रकार के मुद्दों के सापेक्ष प्रसिद्ध हैं, जिनमें उनके लेखन कैशिंग के आंतरिक कार्यान्वयन के सापेक्ष मुद्दे शामिल हैं। मुझे पता नहीं क्यों, लेकिन anecdotally बोलने वाले RAID नियंत्रकों को लगता है कि कुछ सबसे अधिक बगिया सॉफ़्टवेयर है जो कभी-कभी ऐसे व्यापक उपयोग के संदर्भ में लिखा जाता है। यह निश्चित रूप से बहुत ही प्रतिष्ठित विक्रेताओं से बहुत मुख्यधारा, अच्छी तरह से स्थापित और व्यापक रूप से तैनात RAID हार्डवेयर का उपयोग करने के लिए भुगतान करता है ..... और फिर भी गैर-तुच्छ मुद्दों के लिए पैच बहुत बार-बार लगते हैं!
टॉल जेफ

धन्यवाद जेफ। मैं इस में बहुत कुछ पढ़ रहा हूं, और मैं बस उलझन में हूं जैसा कि मैं कभी था। मुझे लगता है कि अब मैं जिस समस्या से जूझ रहा हूं, उसे "राइट्स बैरियर" के साथ करना होगा, जो एप्लिकेशन और फाइल सिस्टम को ब्लॉक लेयर को निर्देश देने की अनुमति देता है कि वह उपलब्ध विभिन्न तंत्रों का उपयोग करके राइट राइट ऑर्डर की गारंटी दे। दुर्भाग्य से, बाधाओं के कार्यान्वयन के साथ सभी प्रकार की समस्याएं हैं। LVM, एक बात के लिए, जाहिरा तौर पर उनका समर्थन नहीं करता है, भले ही अंतर्निहित डिवाइस करते हों। इसके अलावा, मुझे लगता है कि sysadmins fsync ड्राइव कैश की एक फ्लश के लिए मजबूर करने का विकल्प होना चाहिए
ईएएस

@eas - "लिखने में बाधाएं" शब्द जो आप कहते हैं, मैं मानता हूं कि एक ही मूल तंत्र है जिसे मैंने ऊपर दिए गए मेरे उत्तर में कैश का "सिंक" या "फ्लश" कहा है। आपकी बात के लिए, यह फ़ाइल एक्सेस "स्टैक" में विभिन्न परतों पर शुरू किया जा सकता है। एक वास्तविक लेखन अवरोध का निर्माण करने के लिए, इसे उन सभी परतों के माध्यम से प्रभावित करना पड़ता है जिनमें लंबित लेखन डेटा होता है (यानी: गंदा कैश या राइट-बैक बफ़र्स) भौतिक मीडिया के माध्यम से वास्तव में इच्छित कार्य करने के लिए। उस श्रृंखला में कोई डिस्कनेक्ट लिंक वह है जो संभावित समस्याओं का परिचय देता है जब लिखता है फिर से लिखना।
लंबा जेफ़

डिस्क कई सेकंड्स के लिए मीडिया को लिखने में देरी कर सकती है, अगर कोई और आगे लिखता है कि डिस्क कैश ओवरफ्लो कर देगा तो यह मीडिया को लिखने पर मजबूर कर देगा। NCQ को लिखने के लिए कैश की सख्त आवश्यकता नहीं है, इसमें अभी भी कई राइट्स लंबित हो सकते हैं और उन्हें पढ़ सकते हैं और उन्हें जारी कर सकते हैं, जिसमें डिस्क सोचता है कि उसे सबसे अच्छा प्रदर्शन मिलेगा, NCQ के साथ भी लिखने के आदेश का कोई अर्थ नहीं है जो बनाता है filesystems और डेटाबेस IO बाधाओं का उपयोग करने की आवश्यकता है।
बरूच यहां तक ​​कि

3

यह मेरा अनुभव रहा है कि एक बैटरी-समर्थित कैशिंग डिस्क नियंत्रक ऑन-ड्राइव कैश को अक्षम कर देगा। मुझे अन्यथा डिस्क पर कैश को अक्षम करने के तरीके के बारे में पता नहीं है। यहां तक ​​कि अगर आप ऑन-डिस्क कैश को अक्षम कर सकते हैं, तो प्रदर्शन काफी महत्वपूर्ण होगा।

कम लागत वाले ऑप्टोइन के लिए, आप एक सस्ती यूपीएस का उपयोग कर सकते हैं जो आपके सिस्टम को एक अर्दली बंद करने के लिए संकेत दे सकता है।


ऊपर मेरी टिप्पणी को यहाँ जोड़ा जाना चाहिए था। मैं अभी भी इस साइट को सीख रहा हूं।
ईएएस

कुछ RAID नियंत्रक हर समय ऑन-डिस्क कैश को अक्षम करते हैं, कुछ में सेटिंग नहीं होती है। यह व्यवहार मौलिक रूप से इस बात पर निर्भर करता है कि RAID नियंत्रक की कैशिंग रणनीति क्या है। कुछ कार्यान्वयन में, वे वास्तव में डिस्क पर लिखने के आदेश को नियंत्रित करना चाहते हैं .... और अन्य में यह कम मायने रखता है। मैं अपने जवाब में यहां के कुछ मुद्दों पर चर्चा करता हूं।
टॉल जेफ

परीक्षण (LSI 9261 RAID नियंत्रकों, एसएटीए, एनएल एसएएस और एसएएस ड्राइव) के मेरे छोटे से छोटे सेट में, मैंने पाया कि ड्राइव को कैश लिखने में सक्षम करता है जब ड्राइव बैटर / क्षमता समर्थित कैश के साथ RAID नियंत्रक से जुड़ा था, जिससे कोई फर्क नहीं पड़ा। RAID नियंत्रक कैश के ऊपर और ऊपर प्रदर्शन। मैं अभी तक नहीं कहूंगा कि यह एक कठिन और तेज़ नियम है, लेकिन यह मेरे लिए निश्चित रूप से स्पष्ट है कि ड्राइव कैश को अक्षम करने वाले RAID नियंत्रक एक समस्या नहीं है।
डेनियल लॉसन

2

मैं कैश को बनाए रखने के लिए बैटरी के बजाय सुपरकैपेसिटर के साथ एक RAID प्रणाली का उपयोग करता हूं । बैटरियों को पहनना, उन पर नजर रखना चाहिए, उन्हें बदलना चाहिए और उन मामलों में विफलता के संभावित बिंदु का प्रतिनिधित्व करना चाहिए। स्टार्टअप पर एक संधारित्र शुल्क, कैश को फ्लश करता है जब यूपीएस से बिजली विफल हो जाती है, लगभग हमेशा के लिए रहती है, निगरानी की आवश्यकता नहीं होती है, आदि। हालांकि, जब तक आप गरीबी रेखा पर एक व्यापार नहीं चला रहे हैं (इन दिनों असामान्य नहीं) आपके पास एक यूपीएस होना चाहिए। और सॉफ़्टवेयर जो विफलता पर सिस्टम को साफ-सुथरा कर देता है - मैं आमतौर पर इसे बंद करने से पहले 5-15 मिनट (यूपीएस लोड के आधार पर और इसलिए बैटरी उपलब्ध है) देता हूं।

एक गरज के दौरान आप (या हो सकता है - बिजली सिस्टम बेहतर हो रहे हैं) रोशनी को टिमटिमाते हुए देखें, कभी-कभी बाहर जाने से पहले। यह एक डिवाइस है जिसे रिकॉल करने वाला कहा जाता है। यह एक सर्किट ब्रेकर है कि जब ओवरलोड क्षणिक होने की स्थिति में खोला स्विच को बंद करने की कोशिश करता है, जो कि अधिकांश होते हैं। यदि यह बंद होने के बाद रहने में विफल रहता है, तो तीन कोशिशें कहें, यह खुला रहता है। कुछ गरीब आदमी को बारिश में बाहर जाना पड़ता है और उससे निपटना पड़ता है। उसके लिए बहुत खेद महसूस न करें, जबकि केवल दो बार आप और मैं क्या करते हैं और दो बार कि अगर यह ओवरटाइम है, तो यह खतरनाक काम है।


2

यदि डिस्क बैक कैश लिखता है तो गलत धारणाओं में से एक यह है कि वे केवल बिजली हानि पर डेटा खो देते हैं। यह हमेशा मामला नहीं होता है, खासकर sATA उपकरणों पर। यदि किसी sATA डिवाइस पर कोई त्रुटि है (जैसे कि कॉर्नर केस FW बग या कंट्रोलर बग) और यह रीसेट हो जाता है या बाहरी रूप से रीसेट हो जाता है, तो इस बात की कोई गारंटी नहीं है कि हैंग-बैक कैश में डेटा हैंग होने के बाद भी उपलब्ध है।

यह उन परिदृश्यों को जन्म दे सकता है जहां किसी डिवाइस में क्षणिक त्रुटि होती है, रीसेट हो जाता है, किसी भी गंदे कैश के नुकसान में डेटा हानि होती है, और यह ड्राइवरों के ब्लॉक स्तर से ऊपर चुप है।

इससे भी बदतर, ओएस उपकरणों के माध्यम से ड्राइव कैश को अक्षम करने से डिवाइस रीसेट पर भी खो जाएगा, इसलिए यदि डिवाइस का कैश स्टार्ट-ऑफ-डे पर अक्षम है, तो डिवाइस रीसेट होने पर, यह राइट-बैक कैशिंग को फिर से सक्षम करेगा। एक अन्य रीसेट पर, डिवाइस फिर डेटा खो देगा।

एससीएसआई / एसएएस ड्राइव और कुछ एसएटीए ड्राइव में राइट-बैक प्रोफाइल की स्थिति को बचाने की क्षमता है ताकि यह सुनिश्चित किया जा सके कि संपत्ति रीसेट नहीं हुई है - लेकिन व्यवहार में इसका उपयोग शायद ही कभी किया जाता है।

RAID नियंत्रक जो ऊपरी परतों में ब्लॉक परत को एकीकृत करते हैं, ड्राइव रीसेट को नोटिस कर सकते हैं और राइट-बैक कैश को फिर से अक्षम कर सकते हैं - लेकिन मानक sATA और SAS नियंत्रक ऐसा नहीं करेंगे।

यह सीमा अन्य सेट फ़ीचर और समान मापदंडों के लिए भी जाती है जो प्रदर्शन और विश्वसनीयता के लिए कॉन्फ़िगर किए गए हैं।


1

जैसा कि आप कहते हैं, एक उचित बैटरी समर्थित RAID नियंत्रक महंगा होगा, लेकिन आप £ 100 ($ 150) के लिए eBay पर डेल Perc5 / i नियंत्रक पा सकते हैं और विशेष रूप से RAID5 के साथ Perc5 / i जैसे नियंत्रक की गति आपको विस्मित कर देगी। मेरे पास Perc5 / है और छह डिस्क RAID5 सरणियों के साथ कई सर्वर हैं, और वे सबसे तेज डिस्क में से हैं जिन्हें मैंने कभी देखा है। विशेष रूप से डेटाबेस अनुप्रयोगों के लिए तेजी से डिस्क वास्तव में प्रदर्शन में सुधार करेंगे।

मैं बुलेट को काटता हूं और एक RAID नियंत्रक खरीदता हूं।

जे आर


1

जहाँ तक मैं समझता हूँ, fsync () फ़ेकिंग बैटरी समर्थित RAID नियंत्रकों की एक संपत्ति है, ड्राइव नहीं। RAID नियंत्रक में एक बैटरी शामिल होती है जो ड्राइव को बहाल करने तक अपना कैश लिख सकती है और डिस्क पर सुरक्षित रूप से लिखा जा सकता है। यह नियंत्रक को तुरंत ओएस पर लौटने की अनुमति देता है, क्योंकि यह कुछ स्तर की गारंटी देता है कि डिस्क को लिखा जाएगा।

यह ध्यान दिया जाना चाहिए, यदि ड्राइव राइटबैक कैश भरता है, तो कैश ब्लॉक ड्राइव पर लिखे जाने तक लिखता है। इसका मतलब यह है कि कैश आम तौर पर निरंतर लेखन के तहत प्रभावी नहीं है।

आपको कितने आईओपीएस की आवश्यकता है? क्या आप सुनिश्चित हैं कि आप ड्राइव को कैश से सीमित कर रहे हैं, या ड्राइव पर एक छोटा (आपके सर्वर की मेमोरी की तुलना में) लाभ होगा?


अब मैं जो परीक्षण कर रहा हूं, वह हमारे आवेदन के प्रदर्शन लिफाफे को निर्धारित करने के लिए है ताकि हम यह पता लगा सकें कि कैसे सबसे अच्छे तरीके से तैयार किया जाए। ड्राइव कैश अपेक्षाकृत छोटा हो सकता है, लेकिन इस पर लिखित कैशिंग के साथ ड्राइव ड्राइव को फिर से लिखने (जब उचित हो) की क्षमता देता है, जो दिखता है कि यह निरंतर निरंतर थ्रूपुट लिख सकता है।
१।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.