लिनक्स एपीआई कर्नेल फ़ाइल I / O बफरिंग प्रबंधित करना

हाय, हब्रोज़ितेली! हमने माइकल केरिस्क की पुस्तक "लिनक्स एपीआई" के बारे में पहले ही लिखा था । व्यापक गाइड । ” अब हमने "कर्नल में प्रबंधित फ़ाइल I / O बफरिंग प्रबंधित" पुस्तक का एक अंश प्रकाशित करने का निर्णय लिया है।

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

कर्नेल बफरिंग को नियंत्रित करने के लिए उपयोग किए जाने वाले सिस्टम कॉल पर विचार करने से पहले, SUSv3 से संबंधित कई परिभाषाओं पर विचार करना सार्थक होगा।

सिंक्रनाइज़ I / O डेटा और फ़ाइल अखंडता के साथ

SUSv3 में, सिंक्रनाइज़ I / O पूर्ण होने की अवधारणा का अर्थ है "I / O ऑपरेशन जो या तो डेटा के एक सफल हस्तांतरण [डिस्क पर] या असफल के रूप में निदान किया गया था।"

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

SUSv3 में पहले प्रकार की सिंक्रनाइज़ I / O पूर्णता डेटा अखंडता पूर्ण है। फ़ाइल डेटा को अपडेट करते समय, इस डेटा को आगे काम करने की अनुमति देने के लिए पर्याप्त जानकारी का हस्तांतरण सुनिश्चित किया जाना चाहिए।

- एक रीड ऑपरेशन के लिए, इसका मतलब है कि अनुरोधित फ़ाइल डेटा को (डिस्क से) प्रक्रिया में स्थानांतरित कर दिया गया है। यदि लंबित लेखन कार्य हैं जो अनुरोधित डेटा को प्रभावित कर सकते हैं, तो डेटा को पढ़ने से पहले डिस्क पर स्थानांतरित किया जाएगा।

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

SUSv3 में परिभाषित दूसरे प्रकार के सिंक्रनाइज़ I / O पूर्णता फ़ाइल अखंडता पूर्णता है। यह डेटा अखंडता के साथ सिंक्रनाइज़ I / O को पूरा करने के लिए एक उन्नत विकल्प है। इस मोड के बीच अंतर यह है कि फ़ाइल के अद्यतन के दौरान इसकी सभी मेटाडेटा डिस्क में स्थानांतरित हो जाती है, भले ही यह फ़ाइल डेटा के बाद के निष्कर्षण के लिए आवश्यक न हो।

फ़ाइल I / O के दौरान कर्नेल बफरिंग को नियंत्रित करने के लिए सिस्टम कॉल

Fsync () सिस्टम कॉल सभी बफ़र किए गए डेटा और सभी मेटाडेटा को रीसेट करता है जो एक खुली फ़ाइल के साथ जुड़े होते हैं जिसमें fd डिस्क्रिप्टर होता है। सिंक्रोनस I / O के पूरा होने के बाद fsync () कॉलिंग फ़ाइल को अखंडता की स्थिति में रखती है (फ़ाइल)।

डिस्क डिवाइस (या कम से कम इसके कैश) में डेटा के हस्तांतरण के बाद ही fsync () कॉल रिटर्न नियंत्रण पूरा हो जाता है।

#include <unistd.h> int fsync(int fd); 

सफलता पर 0 या -1 त्रुटि पर देता है

Fdatasync () सिस्टम कॉल बिल्कुल fsync () की तरह काम करता है, लेकिन सिंक्रोनस I / O के पूरा होने के बाद फ़ाइल को अखंडता (डेटा) की स्थिति में रखता है।

 #include <unistd.h> int fdatasync(int fd); 

सफलता पर 0 या -1 त्रुटि पर देता है

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

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

लिनक्स 2.2 और इससे पहले, fdatasync () को fsync () के लिए कॉल के रूप में लागू किया जाता है, इसलिए यह किसी भी प्रदर्शन को बढ़ावा नहीं देता है।

कर्नेल संस्करण 2.6.17 से शुरू, लिनक्स एक गैर-मानक प्रणाली कॉल सिंक_फाइल_रेन्ज () प्रदान करता है। यह आपको fdatasync () की तुलना में डिस्क में फ़ाइल डेटा फ्लशिंग करने की प्रक्रिया को अधिक सटीक रूप से नियंत्रित करने की अनुमति देता है। कॉल करते समय, आप फ़ाइल में गिराए जाने वाले क्षेत्र को निर्दिष्ट कर सकते हैं और झंडे सेट कर सकते हैं जो इस कॉल को अवरुद्ध करने की शर्तों को निर्धारित करते हैं। अधिक विवरण के लिए Sync_file_range (2) मैनुअल पेज देखें।

सिंक () सिस्टम कॉल के कारण सभी कर्नेल बफ़र्स को अद्यतन फ़ाइल जानकारी (यानी डेटा ब्लॉक, पॉइंटर ब्लॉक, मेटाडेटा, आदि) डिस्क में फ्लश करने के लिए प्रेरित करती है।

 #include <unistd.h> void sync(void); 

लिनक्स कार्यान्वयन में, सभी डेटा डिस्क डिवाइस (या कम से कम उसके कैश) में स्थानांतरित होने के बाद ही सिंक () फ़ंक्शन रिटर्न कंट्रोल होता है। लेकिन SUSv3 में, यह अनुमति दी गई है कि सिंक () केवल I / O ऑपरेशन के लिए डेटा ट्रांसफर को योजना में लौटाए और ट्रांसफर पूरा होने तक नियंत्रण लौटाए।

यदि वे 30 सेकंड के लिए स्पष्ट रूप से सिंक्रनाइज़ नहीं किए गए थे, तो डिस्क के लिए एक निरंतर निष्पादित कर्नेल थ्रेड फ्लश संशोधित कर्नेल बफ़र करता है। यह डेटा बफ़र्स को लंबे समय तक संगत डिस्क फ़ाइल के साथ सिंक से बाहर रहने से रोकने के लिए किया जाता है (और सिस्टम विफलता की स्थिति में नुकसान के जोखिम के लिए उन्हें उजागर नहीं करने के लिए)। Linux 2.6 पर, यह कार्य pdflush कर्नेल थ्रेड द्वारा किया जाता है। (लिनक्स 2.4 पर, इसे कुप्ड कर्नेल थ्रेड द्वारा निष्पादित किया गया था।)

वह अवधि (सेकंड के सौवें भाग में) जिसके बाद परिवर्तित बफर को pdflush स्ट्रीम कोड द्वारा डिस्क में फ्लश किया जाना चाहिए जिसे फ़ाइल / proc / sys / vm / dirty_expire_centisecs में परिभाषित किया गया है। एक ही निर्देशिका में अतिरिक्त फाइलें pdflush स्ट्रीम द्वारा निष्पादित ऑपरेशन की अन्य विशेषताओं को नियंत्रित करती हैं।

सभी रिकॉर्ड के लिए सिंक मोड चालू करें: O_SYNC

ओ_एसवाईएनसी ध्वज को निर्दिष्ट करते समय खुला () कॉलिंग के बाद सभी आउटपुट आउटपुट को सिंक्रोनस मोड में किया जाता है:

 fd = open(pathname, O_WRONLY | O_SYNC); 

इस कॉल को खोलने के लिए () के बाद, प्रत्येक फ़ाइल पर किए गए प्रत्येक लेखन () ऑपरेशन स्वचालित रूप से डेटा और फ़ाइल मेटाडेटा को डिस्क में फ्लश कर देता है (अर्थात, लिखों को फ़ाइल अखंडता के साथ सिंक्रनाइज़ राइट ऑपरेशन के रूप में प्रदर्शन किया जाता है)।

बीएसडी सिस्टम के पुराने संस्करणों में, O_FSYNC ध्वज का उपयोग O_SYNC ध्वज के साथ शामिल कार्यक्षमता प्रदान करने के लिए किया गया था। Glibc में, O_FSYNC ध्वज O_SYNC के पर्याय के रूप में परिभाषित किया गया है।

O_SYNC ध्वज का प्रदर्शन प्रभाव

O_SYNC ध्वज (या लगातार कॉल को fsync (), fdatasync (), या सिंक ()) का उपयोग करने से प्रदर्शन प्रभावित हो सकता है। तालिका में। चित्र 13.3 O_SYNC ध्वज सेट और अनियंत्रित के साथ विभिन्न बफर आकारों के लिए बनाई गई फ़ाइल में 1 मिलियन बाइट्स लिखने के लिए आवश्यक समय दिखाता है (ext2 फ़ाइल सिस्टम में)। परिणाम "वेनिला" कर्नेल संस्करण 2.6.30 और 402 बाइट्स के ब्लॉक आकार के साथ ext2 फ़ाइल सिस्टम का उपयोग करके फ़ाइल (पुस्तक के लिए स्रोत कोड में प्रदान किए गए filebuff / write_bytes.c प्रोग्राम का उपयोग करके) प्राप्त किए गए थे। प्रत्येक पंक्ति में दिए गए बफर आकार के लिए 20 शुरू होने के बाद प्राप्त औसत मूल्य होता है।

तालिका 13.3। 1 मिलियन बाइट्स की लेखन गति पर O_SYNC ध्वज का प्रभाव


जैसा कि आप देख सकते हैं, O_SYNC ध्वज को निर्दिष्ट करते समय 1000 बाइट का 1 बाइट का उपयोग करते हुए बिताए गए समय में राक्षसी वृद्धि होती है। कृपया उस बड़े अंतर पर भी ध्यान दें, जो बीते समय और CPU उपयोग समय के बीच O_SYNC ध्वज के साथ रिकॉर्ड निष्पादित करते समय होता है। यह प्रोग्राम के निष्पादन को अवरुद्ध करने का एक परिणाम है जब प्रत्येक बफर की वास्तविक सामग्री को डिस्क में प्रवाहित किया जाता है।

तालिका में दिखाए गए परिणामों में। 13.3, O_SYNC का उपयोग करते समय प्रदर्शन को प्रभावित करने वाले एक अन्य कारक पर ध्यान नहीं दिया जाता है। आधुनिक डिस्क ड्राइव में एक बड़ा आंतरिक कैश होता है, और डिफ़ॉल्ट रूप से O_SYNC ध्वज सेट करने से बस इस कैश में डेटा स्थानांतरित हो जाता है। यदि आप डिस्क कैशिंग (hdparm –w0 कमांड का उपयोग करके) को अक्षम करते हैं, तो O_SYNC का प्रदर्शन प्रभाव और भी महत्वपूर्ण हो जाएगा। 1 बाइट के बफर आकार के साथ, बीता हुआ समय 1030 सेकंड से बढ़कर लगभग 16,000 सेकंड हो जाएगा। 4096 बाइट्स के बफर आकार के साथ, बीता हुआ समय 0.34 सेकंड से 4 सेकंड तक बढ़ जाएगा। नतीजतन, अगर आपको कर्नेल बफ़र्स को डिस्क पर फ़्लश करने के लिए मजबूर करने की आवश्यकता है, तो आपको यह विचार करना चाहिए कि क्या लिखने () के लिए बड़े बफ़र्स का उपयोग करके एप्लिकेशन को डिज़ाइन करना संभव है या O_SYNC ध्वज के बजाय fsync () या fdatasync () या आवधिक कॉल का उपयोग करने पर विचार करें।

झंडे O_DSYNC और O_RSYNC

SUSv3 सिंक्रनाइज़ I / O: O_DSYNC और O_RSYNC से संबंधित दो अतिरिक्त ओपन-फाइल स्टेटस फ्लैग को परिभाषित करता है।

O_DSYNC ध्वज परिणाम बाद में सिंक्रनाइज़ किए गए लेखन कार्यों में डेटा की अखंडता के साथ समाप्त हो गया I / O (fdatasync () का उपयोग करने के समान)। इसके संचालन का प्रभाव O_SYNC ध्वज के कारण होने वाले प्रभाव से अलग है, जिसके उपयोग से फ़ाइल अखंडता (जैसे fsync ()) के साथ बाद में सिंक्रनाइज़ किए गए लेखन कार्यों की ओर जाता है।

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

कर्नेल संस्करण 2.6.33 जारी होने से पहले, O_DSYNC और O_RSYNC झंडे लिनक्स पर लागू नहीं किए गए थे, और इन स्थिरांक को O_SYNC ध्वज सेट करने के रूप में glibc हेडर फ़ाइलों में परिभाषित किया गया था। (O_RSYNC के मामले में, यह सही नहीं था, क्योंकि O_SYNC रीड ऑपरेशन के किसी भी कार्यात्मक को प्रभावित नहीं करता है।)

कर्नेल संस्करण 2.6.33 के साथ शुरू, लिनक्स O_DSYNC ध्वज को लागू करता है, और O_RSYNC ध्वज के कार्यान्वयन को भविष्य के कर्नेल रिलीज़ में जोड़े जाने की संभावना है।

लिनक्स पर 2.6.33 कर्नेल जारी होने से पहले, O_SYNC शब्दार्थ का पूर्ण कार्यान्वयन नहीं था। इसके बजाय, O_SYNC ध्वज O_DSYNC के रूप में लागू किया गया था। लिनक्स कर्नल के लिए जीएनयू सी लाइब्रेरी के पुराने संस्करणों से जुड़े अनुप्रयोगों में, लिनक्स संस्करणों पर 2.6.33 और बाद में, O_SYNC ध्वज अभी भी O_DSYNC की तरह व्यवहार करता है। यह ऐसे कार्यक्रमों के परिचित व्यवहार को बनाए रखने के लिए किया जाता है। (कर्नेल 2.6.33 में पिछड़े द्विआधारी संगतता को संरक्षित करने के लिए, O_DSYNC ध्वज को पुराना O_SYNC ध्वज सौंपा गया था, और नए O_SYNC ध्वज में O_DSYNC ध्वज (क्रमशः 04010000 और 0,0000 मशीनों में से एक) शामिल है। यह नए शीर्ष लेख फ़ाइलों के साथ संकलित अनुप्रयोगों की अनुमति देता है। संस्करण 2.6.33 से पहले जारी गुठली में कम से कम O_DSYNC शब्दार्थ प्राप्त करें।

13.4। मैं / हे बफरिंग अवलोकन

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

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

13.5। कर्नेल I / O अधिसूचना

Posix_fadvise () सिस्टम कॉल प्रक्रिया को फ़ाइल डेटा तक पहुँचने के अपने पसंदीदा तरीके के कर्नेल को सूचित करने की अनुमति देता है।

कर्नेल कर सकते हैं (लेकिन नहीं है) बफर कैश के अपने उपयोग का अनुकूलन करने के लिए posix_fadvise () सिस्टम कॉल द्वारा प्रदान की गई जानकारी का उपयोग करें, जिससे प्रक्रिया के लिए और पूरे सिस्टम के लिए I / O प्रदर्शन बढ़ रहा है। Posix_fadvise () कॉल करने से कार्यक्रम के शब्दार्थ प्रभावित नहीं होते हैं।

 #define _XOPEN_SOURCE 600 #include <fcntl.h> int posix_fadvise(int fd, off_t offset, off_t len, int advice); 

सफलता 0 या सकारात्मक त्रुटि संख्या होने पर वापस आती है

Fd तर्क एक फ़ाइल डिस्क्रिप्टर है जो उस फ़ाइल की पहचान करता है जिसके लिए कर्नेल से संपर्क करने की आवश्यकता होती है। तर्क ऑफसेट और लेन फाइल से संबंधित उस क्षेत्र की पहचान करते हैं जिसमें अधिसूचना संबंधित है: ऑफसेट क्षेत्र के प्रारंभिक ऑफसेट को इंगित करता है, और लेन बाइट्स में इसके आकार को इंगित करता है। लेन को 0 पर सेट करने का मतलब है कि सभी बाइट्स का मतलब है, ऑफसेट के साथ शुरू करना और फ़ाइल के अंत के साथ समाप्त होना। (२.६.६ से पहले कर्नेल संस्करणों में, लेन के लिए ० मान का शाब्दिक अर्थ ० बाइट्स था।)

सलाह तर्क फ़ाइल की प्रक्रिया के उपयोग की इच्छित प्रकृति को दर्शाता है। इसे निम्नलिखित मानों में से एक के साथ परिभाषित किया गया है।

POSIX_FADV_NORMAL - इस प्रक्रिया में उपचार पैटर्न के बारे में एक विशेष अधिसूचना नहीं है। यह डिफ़ॉल्ट व्यवहार है यदि फ़ाइल के लिए कोई सूचना नहीं दी गई है। लिनक्स पर, यह ऑपरेशन विंडो को एक फ़ाइल से उसके मूल आकार (128 KB) तक डेटा को पढ़ने के लिए सेट करता है।

POSIX_FADV_SEQUENTIAL - इस प्रक्रिया में क्रमिक रूप से छोटे ऑफसेट से बड़े लोगों के डेटा को पढ़ना शामिल है। लिनक्स पर, यह ऑपरेशन विंडो को उसके मूल मान को दोगुना करने के लिए एक फ़ाइल से डेटा को पढ़ने के लिए सेट करता है।

POSIX_FADV_RANDOM - प्रक्रिया में यादृच्छिक क्रम में डेटा तक पहुँच शामिल है। लिनक्स पर, यह विकल्प एक फ़ाइल से डेटा के सक्रिय पढ़ने को अक्षम करता है।

POSIX_FADV_WILLNEED - प्रक्रिया में निकट भविष्य में फ़ाइल के निर्दिष्ट क्षेत्र तक पहुंच शामिल है। कर्नेल पूर्वगामी रूप से ऑफसेट और लेन तर्कों द्वारा निर्दिष्ट सीमा में फ़ाइल डेटा के साथ बफर कैश को भरने के लिए डेटा पढ़ता है। बाद में पढ़ी गई () फ़ाइल में कॉल डिस्क I / O को ब्लॉक नहीं करती है, लेकिन बस बफर कैश से डेटा पुनर्प्राप्त करती है। कर्नेल बफर कैश में फ़ाइल से पुनर्प्राप्त डेटा की लंबाई के अनुसार कोई गारंटी नहीं देता है। यदि किसी अन्य प्रक्रिया या कर्नेल के संचालन के दौरान मेमोरी की विशेष आवश्यकता होती है, तो पेज को अंततः पुन: उपयोग किया जाएगा। दूसरे शब्दों में, यदि मेमोरी उच्च मांग में है, तो हमें कॉल करने के लिए पॉज़िक्स_फैडवीस () और बाद में कॉल (या कॉल) को पढ़ने के लिए () के बीच एक छोटे समय के अंतराल की गारंटी देने की आवश्यकता है। (POSIX_FADV_WILLNEED ऑपरेशन के बराबर कार्यक्षमता लिनक्स-विशिष्ट रीडहेड () सिस्टम कॉल द्वारा प्रदान की जाती है।)

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

POSIX_FADV_NOREUSE - इस प्रक्रिया में फ़ाइल के निर्दिष्ट क्षेत्र में डेटा का एक बार उपयोग करना शामिल है, बिना इसका उपयोग किए। इस प्रकार, कर्नेल को सूचित किया जाता है कि यह उन तक एकल पहुंच के बाद पृष्ठों को मुक्त कर सकता है। लिनक्स पर, वर्तमान में इस ऑपरेशन को अनदेखा किया जा रहा है।

Posix_fadvise () विनिर्देश केवल SUSv3 में दिखाई दिया, और यह इंटरफ़ेस सभी UNIX कार्यान्वयनों द्वारा समर्थित नहीं है। लिनक्स पर, कर्नेल संस्करण 2.6 के बाद से posix_fadvise () कॉल प्रदान किया गया है।

13.6। बफर कैश बाईपास: डायरेक्ट I / O

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

यहां दी गई जानकारी केवल लिनक्स के लिए है और SUSv3 में मानकीकृत नहीं है। हालांकि, उपकरणों या फ़ाइलों के लिए कुछ प्रत्यक्ष I / O एक्सेस विकल्प अधिकांश UNIX कार्यान्वयन द्वारा प्रदान किए जाते हैं।

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

प्रत्यक्ष इनपुट-आउटपुट एकल फ़ाइल के संबंध में, या ब्लॉक डिवाइस (उदाहरण के लिए, डिस्क) के संबंध में किया जा सकता है। ऐसा करने के लिए, ओपन () कॉल का उपयोग करके किसी फ़ाइल या डिवाइस को खोलते समय, O_DIRECT ध्वज निर्दिष्ट किया जाता है।

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

यदि एक प्रक्रिया ने O_DIRECT ध्वज के साथ फ़ाइल को खोला, और दूसरा सामान्य तरीके से (जो कि बफर कैश का उपयोग करके) है, तो बफर कैश की सामग्री और प्रत्यक्ष I / O के माध्यम से पढ़े या लिखे गए डेटा के बीच कोई निरंतरता नहीं है। इस तरह के विकास से बचना चाहिए।

डिस्क डिवाइस पर कच्ची पहुंच प्राप्त करने की पुरानी (अब अनुशंसित नहीं) विधि के बारे में जानकारी कच्चे (8) मैनुअल पेज पर मिल सकती है।

प्रत्यक्ष I / O के लिए संरेखण प्रतिबंध

चूंकि प्रत्यक्ष I / O (डिस्क उपकरणों पर और फ़ाइलों के संबंध में) में डिस्क तक सीधी पहुंच शामिल है, I / O प्रदर्शन करते समय कुछ सीमाएं अवश्य देखी जानी चाहिए।

- पोर्टेबल डेटा बफर को मेमोरी बॉर्डर, ब्लॉक आकार के कई पर संरेखित किया जाना चाहिए।

- फाइल या डिवाइस में ऑफसेट जिसमें से स्थानांतरित डेटा शुरू होता है, में कई ब्लॉक आकार होने चाहिए।

- हस्तांतरित डेटा की लंबाई ब्लॉक आकार के एक से अधिक होनी चाहिए।

इन प्रतिबंधों में से किसी का भी पालन करने में विफलता के परिणामस्वरूप EINVAL त्रुटि होगी। ऊपर की सूची में, ब्लॉक आकार डिवाइस के भौतिक ब्लॉक के आकार (आमतौर पर 512 बाइट्स) को संदर्भित करता है।

लिनक्स 2.4 में प्रत्यक्ष I / O का प्रदर्शन करते समय, लिनक्स 2.6 की तुलना में अधिक प्रतिबंध लगाए गए हैं: संरेखण, लंबाई और ऑफसेट का उपयोग किए गए फ़ाइल सिस्टम के तार्किक ब्लॉक के आकार का एक से अधिक होना चाहिए। (आमतौर पर, एक फ़ाइल सिस्टम में तार्किक ब्लॉकों का आकार 1024, 2048 या 4096 बाइट्स हैं।)

कार्यक्रम का उदाहरण

पढ़ने के लिए एक फ़ाइल खोलने पर O_DIRECT का उपयोग करने का एक सरल उदाहरण 13.1 सूचीबद्ध करता है। यह प्रोग्राम चार कमांड-लाइन तर्कों को इंगित करता है (अनुक्रम में) जिस फ़ाइल से डेटा पढ़ा जाएगा, फ़ाइल से बाइट्स की संख्या पढ़ी जाती है, जिस ऑफ़सेट को फ़ाइल से डेटा पढ़ने से पहले प्रोग्राम जाना चाहिए, और डेटा बफर के संरेखण, पढ़ा हुआ ()। अंतिम दो तर्क वैकल्पिक हैं और क्रमशः शून्य ऑफसेट और 4096 बाइट्स के लिए चूक हैं।

कार्यक्रम शुरू होने पर क्या दिखाया जाएगा, इसके उदाहरणों पर विचार करें:

 $ ./direct_read /test/x 512  512    0 Read 512 bytes  $ ./direct_read /test/x 256 ERROR [EINVAL Invalid argument] read    512 $ ./direct_read /test/x 512 1 ERROR [EINVAL Invalid argument] read    512 $ ./direct_read /test/x 4096 8192 512 Read 4096 bytes  $ ./direct_read /test/x 4096 512 256 ERROR [EINVAL Invalid argument] read    512 

लिस्टिंग 13.1 में कार्यक्रम स्मृति के एक ब्लॉक को आवंटित करता है जो कि इसके पहले तर्क के कई में संरेखित होता है, और ऐसा करने के लिए संस्मरण () फ़ंक्शन का उपयोग करता है। उपखंड 7.1.4 में संस्मरण () फ़ंक्शन पर चर्चा की गई थी।

 #define _GNU_SOURCE /*   O_DIRECT  <fcntl.h> */ #include <fcntl.h> #include <malloc.h> #include "tlpi_hdr.h" int main(int argc, char *argv[]) { int fd; ssize_t numRead; size_t length, alignment; off_t offset; void *buf; if (argc < 3 || strcmp(argv[1], "–help") == 0) usageErr("%s file length [offset [alignment]]\n", argv[0]); length = getLong(argv[2], GN_ANY_BASE, "length"); offset = (argc > 3) ? getLong(argv[3], GN_ANY_BASE, "offset") : 0; alignment = (argc > 4) ? getLong(argv[4], GN_ANY_BASE, "alignment") : 4096; fd = open(argv[1], O_RDONLY | O_DIRECT); if (fd == -1) errExit("open"); /*  memalign()   ,   ,    .     'buf'  ,  'alignment',     .    ,   ,  ,    ,  256 ,     ,     512- .    '(char *)'        (     'void *',   memalign(). */ buf = (char *) memalign(alignment * 2, length + alignment) + alignment; if (buf == NULL) errExit("memalign"); if (lseek(fd, offset, SEEK_SET) == -1) errExit("lseek"); numRead = read(fd, buf, length); if (numRead == -1) errExit("read"); printf("Read %ld bytes\n", (long) numRead); exit(EXIT_SUCCESS); } _______________________________________________________________filebuff/direct_read.c 

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

लिनक्स - लिनक्स के लिए कूपन पर 20% की छूट