टिकाऊ डेटा स्टोरेज आणि लिनक्स फाइल API

मी, क्लाउड सिस्टीममधील डेटा स्टोरेजच्या स्थिरतेवर संशोधन करत असताना, मला मूलभूत गोष्टी समजल्या आहेत याची खात्री करण्यासाठी माझी चाचणी घेण्याचे ठरविले. आय NVMe स्पेक वाचून सुरुवात केली डेटा टिकून राहण्याची हमी काय आहे हे समजून घेण्यासाठी (म्हणजे, सिस्टम अयशस्वी झाल्यानंतर डेटा उपलब्ध होईल याची हमी) आम्हाला NMVe डिस्क द्या. मी खालील मुख्य निष्कर्ष काढले: डेटा लिहिण्याची आज्ञा दिल्याच्या क्षणापासून आणि ते स्टोरेज माध्यमात लिहिल्या जाईपर्यंत तुम्हाला नुकसान झालेल्या डेटाचा विचार करणे आवश्यक आहे. तथापि, बर्‍याच प्रोग्राममध्ये, डेटा लिहिण्यासाठी सिस्टम कॉल सुरक्षितपणे वापरले जातात.

या लेखात, मी लिनक्स फाइल API द्वारे प्रदान केलेल्या सक्तीची यंत्रणा एक्सप्लोर करतो. असे दिसते की येथे सर्वकाही सोपे असावे: प्रोग्राम कमांडला कॉल करतो write(), आणि या कमांडचे ऑपरेशन पूर्ण झाल्यानंतर, डेटा डिस्कवर सुरक्षितपणे संग्रहित केला जाईल. परंतु write() फक्त RAM मध्ये असलेल्या कर्नल कॅशेमध्ये ऍप्लिकेशन डेटा कॉपी करते. सिस्टमला डिस्कवर डेटा लिहिण्यास भाग पाडण्यासाठी, काही अतिरिक्त यंत्रणा वापरणे आवश्यक आहे.

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

write() फंक्शन वापरण्याची वैशिष्ट्ये

सिस्टम कॉल 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 सेकंदांसाठी या स्थितीत राहतो, तुम्ही हे वापरून कॉन्फिगर करू शकता 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 Linux 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%) कार्यप्रदर्शन सुधारणा देते. तसेच, काही डिस्क्समध्ये इतरांपेक्षा कमी फर्स्ट ब्लॉक ऍक्सेस ऑपरेशन असू शकते. याचा अर्थ असा की शून्यांसह जागा भरल्याने लक्षणीय (सुमारे 100%) कार्यप्रदर्शन सुधारणा होऊ शकते. विशेषतः, हे डिस्कसह होऊ शकते. AWS EBS (हा अनधिकृत डेटा आहे, मी त्यांची पुष्टी करू शकलो नाही). स्टोरेजसाठीही तेच आहे. GCP पर्सिस्टंट डिस्क (आणि ही आधीच अधिकृत माहिती आहे, चाचण्यांद्वारे पुष्टी केलेली). इतर तज्ञांनीही असेच केले आहे निरीक्षणवेगवेगळ्या डिस्कशी संबंधित.
2. जितके कमी सिस्टम कॉल, तितके जास्त कार्यप्रदर्शन (नफा सुमारे 5% असू शकतो). हे कॉलसारखे दिसते open() ध्वजासह O_DSYNC किंवा कॉल करा pwritev2() ध्वजासह RWF_SYNC जलद कॉल fdatasync(). मला शंका आहे की येथे मुद्दा असा आहे की या दृष्टिकोनासह, समान कार्य (दोन ऐवजी एक कॉल) सोडवण्यासाठी कमी सिस्टम कॉल करणे आवश्यक आहे. परंतु कार्यप्रदर्शनातील फरक फारच लहान आहे, म्हणून आपण सहजपणे त्याकडे दुर्लक्ष करू शकता आणि अनुप्रयोगात काहीतरी वापरू शकता ज्यामुळे त्याच्या तर्काची गुंतागुंत होत नाही.

तुम्हाला टिकाऊ डेटा स्टोरेज विषयात स्वारस्य असल्यास, येथे काही उपयुक्त साहित्य आहेत:

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

आपण कधीही डिस्कवर सुरक्षितपणे संग्रहित केलेला डेटा गमावला आहे का?

स्त्रोत: www.habr.com