टिकाऊ डेटा संग्रहण और Linux फ़ाइल APIs

क्लाउड सिस्टम में डेटा स्टोरेज की स्थिरता पर शोध करते समय, मैंने यह सुनिश्चित करने के लिए खुद का परीक्षण करने का निर्णय लिया कि मैं बुनियादी चीजों को समझ गया हूं। मैं एनवीएमई विनिर्देश को पढ़ने से शुरुआत हुई यह समझने के लिए कि टिकाऊ डेटा भंडारण के संबंध में क्या गारंटी है (अर्थात यह गारंटी है कि सिस्टम विफलता के बाद डेटा उपलब्ध होगा) हमें NMVe डिस्क दें। मैंने निम्नलिखित मुख्य निष्कर्ष निकाले: डेटा को उस क्षण से क्षतिग्रस्त माना जाना चाहिए जब डेटा लिखने का आदेश दिया जाता है जब तक कि इसे भंडारण माध्यम पर नहीं लिखा जाता है। हालाँकि, अधिकांश प्रोग्राम डेटा रिकॉर्ड करने के लिए सिस्टम कॉल का काफी ख़ुशी से उपयोग करते हैं।

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

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

राइट() फ़ंक्शन का उपयोग करने की विशेषताएं

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

क्या इसका मतलब यह है कि ऑपरेशन write() क्या यह परमाणु है? तकनीकी दृष्टिकोण से, हाँ। डेटा रीड ऑपरेशंस को जो लिखा गया था उसका या तो पूरा या कुछ भी नहीं लौटाना चाहिए write(). लेकिन ऑपरेशन write()मानक के अनुसार, जरूरी नहीं कि वह सब कुछ लिखकर ही समाप्त हो, जिसे लिखने के लिए कहा गया था। उसे डेटा का केवल एक भाग लिखने की अनुमति है। उदाहरण के लिए, हमारे पास एक ही फ़ाइल डिस्क्रिप्टर द्वारा वर्णित फ़ाइल में 1024 बाइट्स जोड़ने वाले दो थ्रेड हो सकते हैं। मानक के दृष्टिकोण से, एक स्वीकार्य परिणाम तब होगा जब प्रत्येक लेखन ऑपरेशन फ़ाइल में केवल एक बाइट जोड़ सकता है। ये ऑपरेशन परमाणु रहेंगे, लेकिन उनके पूरा होने के बाद, फ़ाइल में लिखा गया डेटा मिश्रित हो जाएगा। यहां स्टैक ओवरफ़्लो पर इस विषय पर बहुत दिलचस्प चर्चा।

fsync() और fdatasync() फ़ंक्शन

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

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

इस तंत्र को अलग-अलग फ़ाइल सिस्टम पर अलग-अलग तरीके से लागू किया जा सकता है। मैंनें इस्तेमाल किया blktrace यह जानने के लिए कि ext4 और XFS फ़ाइल सिस्टम में कौन से डिस्क संचालन का उपयोग किया जाता है। दोनों फ़ाइल सामग्री और फ़ाइल सिस्टम जर्नल दोनों के लिए डिस्क पर नियमित रूप से लिखने के आदेश जारी करते हैं, कैश को फ्लश करते हैं, और FUA (फोर्स यूनिट एक्सेस, डिस्क पर सीधे डेटा लिखना, कैश को बायपास करना) निष्पादित करके जर्नल से बाहर निकलते हैं। वे संभवतः यह पुष्टि करने के लिए ऐसा करते हैं कि लेनदेन हो गया है। उन ड्राइव पर जो FUA का समर्थन नहीं करते हैं, यह दो कैश फ्लश का कारण बनता है। मेरे प्रयोगों से यह पता चला fdatasync() थोड़ा सा तेज़ fsync(). उपयोगिता blktrace दर्शाता है कि fdatasync() आमतौर पर डिस्क पर कम डेटा लिखता है (ext4 में)। fsync() 20 KiB लिखता है, और fdatasync() - 16 KiB). साथ ही, मुझे पता चला कि XFS, ext4 से थोड़ा तेज़ है। और यहाँ मदद से blktrace इसका पता लगाने में कामयाब रहे fdatasync() डिस्क पर कम डेटा फ्लश करता है (XFS में 4 KiB)।

fsync() का उपयोग करते समय उत्पन्न होने वाली अस्पष्ट स्थितियाँ

मैं इसके संबंध में तीन अस्पष्ट स्थितियों के बारे में सोच सकता हूं fsync()जिसका मुझे व्यवहार में सामना करना पड़ा।

ऐसा पहला मामला 2008 में हुआ था. यदि बड़ी संख्या में फ़ाइलें डिस्क पर लिखी गईं तो फ़ायरफ़ॉक्स 3 इंटरफ़ेस फ़्रीज़ हो गया। समस्या यह थी कि इंटरफ़ेस के कार्यान्वयन में इसकी स्थिति के बारे में जानकारी संग्रहीत करने के लिए SQLite डेटाबेस का उपयोग किया गया था। इंटरफ़ेस में होने वाले प्रत्येक परिवर्तन के बाद, फ़ंक्शन को कॉल किया गया fsync(), जिसने स्थिर डेटा भंडारण की अच्छी गारंटी दी। तब उपयोग किए गए ext3 फ़ाइल सिस्टम में, फ़ंक्शन fsync() सिस्टम के सभी "गंदे" पेजों को डिस्क पर डंप कर दिया, न कि केवल उन्हें जो संबंधित फ़ाइल से संबंधित थे। इसका मतलब यह था कि फ़ायरफ़ॉक्स में एक बटन क्लिक करने से मेगाबाइट डेटा चुंबकीय डिस्क पर लिखा जा सकता है, जिसमें कई सेकंड लग सकते हैं। जहाँ तक मैं समझता हूँ, समस्या का समाधान है इस का सामग्री का उद्देश्य डेटाबेस के साथ कार्य को अतुल्यकालिक पृष्ठभूमि कार्यों में स्थानांतरित करना था। इसका मतलब यह है कि फ़ायरफ़ॉक्स ने पहले आवश्यकता से अधिक कठोर भंडारण आवश्यकताओं को लागू किया था, और ext3 फ़ाइल सिस्टम की विशेषताओं ने इस समस्या को और बढ़ा दिया था।

दूसरी समस्या 2009 में हुई. फिर, एक सिस्टम क्रैश के बाद, नए ext4 फ़ाइल सिस्टम के उपयोगकर्ताओं को इस तथ्य का सामना करना पड़ा कि कई नई बनाई गई फ़ाइलों की लंबाई शून्य थी, लेकिन पुराने ext3 फ़ाइल सिस्टम के साथ ऐसा नहीं हुआ। पिछले पैराग्राफ में, मैंने इस बारे में बात की थी कि कैसे ext3 ने डिस्क पर बहुत अधिक डेटा प्रवाहित किया, जिससे चीजें बहुत धीमी हो गईं। fsync(). स्थिति को सुधारने के लिए, ext4 में केवल वे गंदे पृष्ठ जो किसी विशेष फ़ाइल से प्रासंगिक हैं, डिस्क पर फ्लश किए जाते हैं। और अन्य फ़ाइलों का डेटा ext3 की तुलना में अधिक समय तक मेमोरी में रहता है। यह प्रदर्शन को बेहतर बनाने के लिए किया गया था (डिफ़ॉल्ट रूप से, डेटा 30 सेकंड के लिए इस स्थिति में रहता है, आप इसका उपयोग करके कॉन्फ़िगर कर सकते हैं गंदा_समाप्त_सेंटीसेक; यहां आप इसके बारे में अतिरिक्त सामग्री पा सकते हैं)। इसका मतलब यह है कि विफलता के बाद बड़ी मात्रा में डेटा अपरिवर्तनीय रूप से खो सकता है। इस समस्या का समाधान उपयोग करना है fsync() ऐसे अनुप्रयोगों में जिन्हें स्थिर डेटा भंडारण सुनिश्चित करने और विफलताओं के परिणामों से यथासंभव उनकी रक्षा करने की आवश्यकता होती है। समारोह fsync() ext4 का उपयोग करने की तुलना में ext3 का उपयोग करते समय अधिक कुशलता से काम करता है। इस दृष्टिकोण का नुकसान यह है कि इसका उपयोग, पहले की तरह, कुछ कार्यों के निष्पादन को धीमा कर देता है, जैसे प्रोग्राम इंस्टॉल करना। इसके बारे में विवरण देखें यहां и यहां.

तीसरी समस्या के संबंध में fsync(), 2018 में उत्पन्न हुआ। फिर, PostgreSQL प्रोजेक्ट के ढांचे के भीतर, यह पाया गया कि यदि फ़ंक्शन fsync() एक त्रुटि आती है, यह "गंदे" पृष्ठों को "साफ" के रूप में चिह्नित करता है। परिणामस्वरूप, निम्नलिखित कॉल fsync() वे ऐसे पेजों के साथ कुछ नहीं करते. इस वजह से, संशोधित पृष्ठ मेमोरी में संग्रहीत होते हैं और कभी भी डिस्क पर नहीं लिखे जाते हैं। यह एक वास्तविक आपदा है, क्योंकि एप्लिकेशन सोचेगा कि कुछ डेटा डिस्क पर लिखा गया है, लेकिन वास्तव में ऐसा नहीं होगा। ऐसी असफलताएँ fsync() दुर्लभ हैं, ऐसी स्थितियों में एप्लिकेशन समस्या से निपटने के लिए लगभग कुछ नहीं कर सकता है। आजकल, जब ऐसा होता है, तो PostgreSQL और अन्य एप्लिकेशन क्रैश हो जाते हैं। यहां, सामग्री "क्या एप्लिकेशन fsync विफलताओं से पुनर्प्राप्त हो सकते हैं?" में, इस समस्या का विस्तार से पता लगाया गया है। वर्तमान में इस समस्या का सबसे अच्छा समाधान ध्वज के साथ डायरेक्ट I/O का उपयोग करना है O_SYNC या झंडे के साथ O_DSYNC. इस दृष्टिकोण के साथ, सिस्टम उन त्रुटियों की रिपोर्ट करेगा जो विशिष्ट लेखन कार्यों के दौरान हो सकती हैं, लेकिन इस दृष्टिकोण के लिए एप्लिकेशन को बफ़र्स को स्वयं प्रबंधित करने की आवश्यकता होती है। इसके बारे में और पढ़ें यहां и यहां.

O_SYNC और O_DSYNC फ़्लैग का उपयोग करके फ़ाइलें खोलना

आइए लिनक्स तंत्र की चर्चा पर वापस लौटें जो स्थिर डेटा भंडारण प्रदान करता है। अर्थात्, हम ध्वज के उपयोग के बारे में बात कर रहे हैं O_SYNC या झंडा O_DSYNC सिस्टम कॉल का उपयोग करके फ़ाइलें खोलते समय खुला हुआ(). इस दृष्टिकोण के साथ, प्रत्येक डेटा लेखन ऑपरेशन प्रत्येक कमांड के बाद किया जाता है write() सिस्टम को तदनुसार आदेश दिए जाते हैं fsync() и fdatasync(). में पॉज़िक्स विनिर्देश इसे "सिंक्रोनाइज़्ड I/O फ़ाइल इंटीग्रिटी कंप्लीशन" और "डेटा इंटीग्रिटी कंप्लीशन" कहा जाता है। इस दृष्टिकोण का मुख्य लाभ यह है कि डेटा अखंडता सुनिश्चित करने के लिए, आपको दो के बजाय केवल एक सिस्टम कॉल करने की आवश्यकता है (उदाहरण के लिए - write() и fdatasync()). इस दृष्टिकोण का मुख्य नुकसान यह है कि संबंधित फ़ाइल डिस्क्रिप्टर का उपयोग करके लिखे गए सभी को सिंक्रनाइज़ किया जाएगा, जो एप्लिकेशन कोड को संरचना करने की क्षमता को सीमित कर सकता है।

O_DIRECT ध्वज के साथ डायरेक्ट I/O का उपयोग करना

सिस्टम कॉल open() झंडे का समर्थन करता है O_DIRECT, जिसे डिस्क के साथ सीधे इंटरैक्ट करके I/O संचालन करने के लिए ऑपरेटिंग सिस्टम कैश को बायपास करने के लिए डिज़ाइन किया गया है। इसका, कई मामलों में, मतलब यह है कि प्रोग्राम द्वारा जारी किए गए राइट कमांड को सीधे डिस्क के साथ काम करने के उद्देश्य से कमांड में अनुवादित किया जाएगा। लेकिन, सामान्य तौर पर, यह तंत्र कार्यों का प्रतिस्थापन नहीं है fsync() या fdatasync(). तथ्य यह है कि डिस्क स्वयं ही ऐसा कर सकती है स्थगित करें या कैश करें संबंधित डेटा लेखन आदेश। और, मामले को बदतर बनाने के लिए, कुछ विशेष मामलों में ध्वज का उपयोग करते समय I/O संचालन किया जाता है O_DIRECT, प्रसारण पारंपरिक बफ़र्ड संचालन में। इस समस्या को हल करने का सबसे आसान तरीका फ़ाइलों को खोलने के लिए ध्वज का उपयोग करना है O_DSYNC, जिसका अर्थ यह होगा कि प्रत्येक लेखन ऑपरेशन के बाद एक कॉल आएगी fdatasync().

यह पता चला कि XFS फ़ाइल सिस्टम ने हाल ही में एक "तेज़ पथ" जोड़ा था O_DIRECT|O_DSYNC-डेटा रिकॉर्डिंग. यदि किसी ब्लॉक का उपयोग करके दोबारा लिखा जाता है O_DIRECT|O_DSYNC, तो XFS, कैश को फ्लश करने के बजाय, FUA राइट कमांड निष्पादित करेगा यदि डिवाइस इसका समर्थन करता है। मैंने उपयोगिता का उपयोग करके इसे सत्यापित किया blktrace Linux 5.4/Ubuntu 20.04 सिस्टम पर। यह दृष्टिकोण अधिक कुशल होना चाहिए, क्योंकि जब इसका उपयोग किया जाता है, तो डिस्क पर न्यूनतम मात्रा में डेटा लिखा जाता है और दो (कैश लिखना और फ्लश करना) के बजाय एक ऑपरेशन का उपयोग किया जाता है। मुझे इसका एक लिंक मिला पैच 2018 कर्नेल, जो इस तंत्र को लागू करता है। इस अनुकूलन को अन्य फाइल सिस्टम पर लागू करने के बारे में कुछ चर्चा है, लेकिन जहां तक ​​मुझे पता है, एक्सएफएस एकमात्र फाइल सिस्टम है जो अब तक इसका समर्थन करता है।

sync_file_range() फ़ंक्शन

Linux में एक सिस्टम कॉल है सिंक_फ़ाइल_रेंज(), जो आपको पूरी फ़ाइल के बजाय फ़ाइल के केवल एक हिस्से को डिस्क पर फ्लश करने की अनुमति देता है। यह कॉल एक एसिंक्रोनस डेटा फ्लश आरंभ करता है और इसके पूरा होने की प्रतीक्षा नहीं करता है। लेकिन सर्टिफिकेट में sync_file_range() टीम को "बहुत खतरनाक" कहा जाता है। इसका उपयोग करने की अनुशंसा नहीं की जाती है. विशेषताएं और खतरे sync_file_range() में बहुत अच्छे से वर्णन किया गया है यह सामग्री। विशेष रूप से, यह कॉल यह नियंत्रित करने के लिए RocksDB का उपयोग करती प्रतीत होती है कि कर्नेल गंदे डेटा को डिस्क पर कब फ्लश करता है। लेकिन साथ ही, स्थिर डेटा स्टोरेज सुनिश्चित करने के लिए भी इसका उपयोग किया जाता है fdatasync(). में कोड इस विषय पर RocksDB की कुछ दिलचस्प टिप्पणियाँ हैं। उदाहरण के लिए, ऐसा प्रतीत होता है कि कॉल sync_file_range() ZFS का उपयोग करते समय, यह डेटा को डिस्क पर फ्लश नहीं करता है। अनुभव मुझे बताता है कि जो कोड शायद ही कभी उपयोग किया जाता है उसमें बग होने की संभावना होती है। इसलिए, जब तक अत्यंत आवश्यक न हो, मैं इस सिस्टम कॉल का उपयोग न करने की सलाह दूंगा।

सिस्टम कॉल जो डेटा दृढ़ता सुनिश्चित करने में मदद करती हैं

मैं इस निष्कर्ष पर पहुंचा हूं कि तीन दृष्टिकोण हैं जिनका उपयोग I/O संचालन करने के लिए किया जा सकता है जो डेटा दृढ़ता सुनिश्चित करते हैं। उन सभी को एक फ़ंक्शन कॉल की आवश्यकता होती है fsync() उस निर्देशिका के लिए जिसमें फ़ाइल बनाई गई थी। ये दृष्टिकोण हैं:

1. किसी फ़ंक्शन को कॉल करना fdatasync() या fsync() समारोह के बाद write() (इसका उपयोग करना बेहतर है fdatasync()).
2. एक ध्वज के साथ खोले गए फ़ाइल डिस्क्रिप्टर के साथ कार्य करना O_DSYNC या O_SYNC (बेहतर - एक झंडे के साथ O_DSYNC).
3. कमांड का उपयोग करना pwritev2() एक झंडे के साथ RWF_DSYNC या RWF_SYNC (अधिमानतः एक झंडे के साथ RWF_DSYNC).

प्रदर्शन नोट्स

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

1. किसी फ़ाइल में डेटा जोड़ने की तुलना में फ़ाइल डेटा को ओवरराइट करना तेज़ है (प्रदर्शन लाभ 2-100% हो सकता है)। किसी फ़ाइल में डेटा जोड़ने के लिए सिस्टम कॉल के बाद भी फ़ाइल के मेटाडेटा में अतिरिक्त बदलाव की आवश्यकता होती है fallocate(), लेकिन इस प्रभाव की भयावहता भिन्न हो सकती है। सर्वोत्तम प्रदर्शन के लिए, मैं कॉल करने की अनुशंसा करता हूँ fallocate() आवश्यक स्थान को पूर्व-आवंटित करने के लिए। फिर इस स्थान को स्पष्ट रूप से शून्य से भरा जाना चाहिए और कॉल किया जाना चाहिए fsync(). यह सुनिश्चित करेगा कि फ़ाइल सिस्टम में संबंधित ब्लॉक को "अनआवंटित" के बजाय "आवंटित" के रूप में चिह्नित किया गया है। इससे प्रदर्शन में थोड़ा (लगभग 2%) सुधार होता है। इसके अतिरिक्त, कुछ डिस्क में किसी ब्लॉक तक पहली पहुंच दूसरों की तुलना में धीमी हो सकती है। इसका मतलब यह है कि रिक्त स्थान को शून्य से भरने से प्रदर्शन में महत्वपूर्ण (लगभग 100%) सुधार हो सकता है। विशेष रूप से, डिस्क के साथ ऐसा हो सकता है एडब्ल्यूएस ईबीएस (यह अनौपचारिक डेटा है, मैं इसकी पुष्टि नहीं कर सका)। भंडारण के लिए भी यही बात लागू होती है जीसीपी परसिस्टेंट डिस्क (और यह पहले से ही आधिकारिक जानकारी है, परीक्षणों द्वारा पुष्टि की गई है)। अन्य विशेषज्ञों ने भी ऐसा ही किया है टिप्पणियों, विभिन्न डिस्क से संबंधित।
2. जितनी कम सिस्टम कॉलें होंगी, प्रदर्शन उतना ही अधिक होगा (लाभ लगभग 5% हो सकता है)। एक चुनौती की तरह लग रहा है open() एक झंडे के साथ O_DSYNC अथवा फोन करें pwritev2() एक झंडे के साथ RWF_SYNC एक कॉल से भी तेज़ fdatasync(). मुझे संदेह है कि यहां मुद्दा यह है कि यह दृष्टिकोण इस तथ्य में भूमिका निभाता है कि एक ही समस्या को हल करने के लिए कम सिस्टम कॉल करना पड़ता है (दो के बजाय एक कॉल)। लेकिन प्रदर्शन में अंतर बहुत छोटा है, इसलिए आप इसे पूरी तरह से अनदेखा कर सकते हैं और एप्लिकेशन में कुछ ऐसा उपयोग कर सकते हैं जो इसके तर्क को जटिल नहीं करेगा।

यदि आप टिकाऊ डेटा भंडारण के विषय में रुचि रखते हैं, तो यहां कुछ उपयोगी सामग्रियां दी गई हैं:

• I/O पहुँच विधियाँ - इनपुट/आउटपुट तंत्र की बुनियादी बातों का अवलोकन।
• यह सुनिश्चित करना कि डेटा डिस्क तक पहुंचे - एप्लिकेशन से डिस्क तक के रास्ते में डेटा का क्या होता है, इसके बारे में एक कहानी।
• आपको युक्त निर्देशिका को कब fsync करना चाहिए - कब उपयोग करें के प्रश्न का उत्तर fsync() निर्देशिकाओं के लिए. इसे संक्षेप में कहें तो, यह पता चलता है कि नई फ़ाइल बनाते समय आपको ऐसा करने की आवश्यकता होती है, और इस अनुशंसा का कारण यह है कि लिनक्स में एक ही फ़ाइल के कई संदर्भ हो सकते हैं।
• लिनक्स पर एसक्यूएल सर्वर: एफयूए इंटरनल्स - यहां इस बात का विवरण दिया गया है कि लिनक्स प्लेटफॉर्म पर SQL सर्वर में लगातार डेटा स्टोरेज कैसे कार्यान्वित किया जाता है। यहां विंडोज़ और लिनक्स सिस्टम कॉल के बीच कुछ दिलचस्प तुलनाएं हैं। मुझे पूरा यकीन है कि इस सामग्री की बदौलत ही मैंने एक्सएफएस के एफयूए अनुकूलन के बारे में सीखा।

क्या आपने वह डेटा खो दिया है जिसके बारे में आपको लगता था कि वह डिस्क पर सुरक्षित रूप से संग्रहीत है?

स्रोत: www.habr.com