टिकाऊ डाटा भण्डारण र लिनक्स फाइल API हरू

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

यस पोष्टमा, म लिनक्स फाइल API हरू द्वारा प्रदान गरिएको निरन्तर भण्डारण संयन्त्रहरू अन्वेषण गर्दछु। यस्तो देखिन्छ कि यहाँ सबै कुरा सरल हुनुपर्छ: कार्यक्रमले आदेशलाई कल गर्दछ 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 इन्टरफेस फ्रिज भयो यदि फाइलहरूको ठूलो संख्या डिस्कमा लेखिएको थियो। समस्या यो थियो कि इन्टरफेसको कार्यान्वयनले यसको राज्यको बारेमा जानकारी भण्डारण गर्न SQLite डाटाबेस प्रयोग गर्‍यो। इन्टरफेसमा भएको प्रत्येक परिवर्तन पछि, प्रकार्य भनिन्छ fsync(), जसले स्थिर डाटा भण्डारणको राम्रो ग्यारेन्टी दियो। ext3 फाइल प्रणालीमा त्यसपछि प्रयोग गरिएको, प्रकार्य fsync() प्रणालीका सबै "फोहोर" पृष्ठहरूलाई डिस्कमा फ्याँकियो, र सम्बन्धित फाइलसँग सम्बन्धित मात्र होइन। यसको मतलब फायरफक्समा बटन क्लिक गर्दा मेगाबाइट डाटा चुम्बकीय डिस्कमा लेख्न ट्रिगर गर्न सक्छ, जसले धेरै सेकेन्ड लिन सक्छ। मैले बुझेसम्म समस्याको समाधान यसलाई सामग्री डाटाबेसको साथ कामलाई एसिन्क्रोनस पृष्ठभूमि कार्यहरूमा स्थानान्तरण गर्न थियो। यसको मतलब यो हो कि फायरफक्सले पहिले वास्तवमै आवश्यक भन्दा बढी कडा भण्डारण आवश्यकताहरू लागू गरेको थियो, र ext3 फाइल प्रणालीका सुविधाहरूले मात्र यो समस्यालाई बढायो।

दोस्रो समस्या 2009 मा भयो। त्यसपछि, प्रणाली क्र्यास पछि, नयाँ ext4 फाइल प्रणालीका प्रयोगकर्ताहरूले धेरै नयाँ सिर्जना गरिएका फाइलहरूको लम्बाइ शून्य भएको तथ्यको सामना गर्नुपरेको थियो, तर पुरानो ext3 फाइल प्रणालीमा यस्तो भएन। अघिल्लो अनुच्छेदमा, मैले कसरी ext3 ले डिस्कमा धेरै डाटा फ्लश गरेको कुरा गरेको थिएँ, जसले चीजहरूलाई धेरै ढिलो बनायो। fsync()। स्थिति सुधार गर्न, ext4 मा केवल ती फोहोर पृष्ठहरू जुन एक विशेष फाइलसँग सम्बन्धित छन् डिस्कमा फ्लस गरिन्छ। र अन्य फाइलहरूबाट डाटा ext3 को तुलनामा धेरै लामो समयको लागि मेमोरीमा रहन्छ। यो कार्यसम्पादन सुधार गर्नको लागि गरिएको थियो (पूर्वनिर्धारित रूपमा, डाटा 30 सेकेन्डको लागि यो अवस्थामा रहन्छ, तपाइँ यसलाई प्रयोग गरेर कन्फिगर गर्न सक्नुहुन्छ। dirty_expire_centisecs; यहाँ तपाईं यस बारे थप सामग्री फेला पार्न सक्नुहुन्छ)। यसको मतलब यो हो कि एक विफलता पछि डेटा को एक ठूलो मात्रा अपूरणीय रूपमा हराउन सकिन्छ। यो समस्या को समाधान को उपयोग गर्न को लागी छ 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()। को POSIX विशिष्टताहरू यसलाई "सिंक्रोनाइज्ड 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 लिनक्स 5.4/Ubuntu 20.04 प्रणालीमा। यो दृष्टिकोण बढी प्रभावकारी हुनुपर्छ, किनकि प्रयोग गर्दा, डिस्कमा न्यूनतम मात्रामा डाटा लेखिएको हुन्छ र दुईवटा (क्यास लेख्ने र फ्लस गर्ने) भन्दा एउटा अपरेशन प्रयोग गरिन्छ। मैले एउटा लिङ्क फेला पारे प्याच 2018 कर्नेल, जसले यो संयन्त्र लागू गर्दछ। त्यहाँ अन्य फाइल प्रणालीहरूमा यो अप्टिमाइजेसन लागू गर्ने बारे केही छलफल छ, तर जहाँसम्म मलाई थाहा छ, XFS एक मात्र फाइल प्रणाली हो जसले यसलाई अहिलेसम्म समर्थन गर्दछ।

sync_file_range() प्रकार्य

लिनक्ससँग प्रणाली कल छ sync_file_range(), जसले तपाईंलाई सम्पूर्ण फाइलको सट्टा डिस्कमा फाइलको अंश मात्र फ्लश गर्न अनुमति दिन्छ। यो कलले एसिन्क्रोनस डाटा फ्लश सुरु गर्छ र यसलाई पूरा हुनको लागि पर्खदैन। तर प्रमाणपत्रमा 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%) प्रदर्शन सुधार दिन्छ। थप रूपमा, केही डिस्कहरूमा अरूहरू भन्दा ब्लकमा ढिलो पहिलो पहुँच हुन सक्छ। यसको अर्थ शून्यसँग खाली ठाउँ भर्दा कार्यसम्पादनमा महत्त्वपूर्ण (लगभग १००%) सुधार हुन सक्छ। विशेष गरी, यो डिस्क संग हुन सक्छ AWS EBS (यो अनौपचारिक डाटा हो, मैले यसलाई पुष्टि गर्न सकेन)। भण्डारणको लागि पनि उस्तै जान्छ GCP पर्सिस्टेन्ट डिस्क (र यो पहिले नै आधिकारिक जानकारी हो, परीक्षण द्वारा पुष्टि)। अन्य विज्ञहरूले पनि त्यस्तै गरेका छन् अवलोकन, विभिन्न डिस्क सम्बन्धित।
2. कम प्रणाली कलहरू, उच्च प्रदर्शन (लाभ लगभग 5% हुन सक्छ)। चुनौती जस्तो देखिन्छ open() झण्डा संग O_DSYNC वा कल गर्नुहोस् pwritev2() झण्डा संग RWF_SYNC कल भन्दा छिटो fdatasync()। मलाई शंका छ कि यहाँ बिन्दु यो हो कि यो दृष्टिकोणले एउटै समस्या (दुईको सट्टा एक कल) समाधान गर्न कम प्रणाली कलहरू प्रदर्शन गर्नु पर्ने तथ्यमा भूमिका खेल्छ। तर प्रदर्शनमा भिन्नता धेरै सानो छ, त्यसैले तपाइँ यसलाई पूर्ण रूपमा बेवास्ता गर्न सक्नुहुन्छ र अनुप्रयोगमा केहि प्रयोग गर्न सक्नुहुन्छ जसले यसको तर्कलाई जटिल बनाउँदैन।

यदि तपाइँ दिगो डाटा भण्डारणको विषयमा रुचि राख्नुहुन्छ भने, यहाँ केहि उपयोगी सामग्रीहरू छन्:

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

के तपाईंले डाटा हराउनुभएको छ जुन तपाईंले सोच्नुभएको थियो कि डिस्कमा सुरक्षित रूपमा भण्डारण गरिएको थियो?

स्रोत: www.habr.com