जर्नलिंग फ़ाइल सिस्टम: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|File system for tracking pending changes}} {{For|the IBM Journaled File System|JFS (file system)}} {{Use mdy dates|date=October 2019}} जर्नलि...")
 
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Short description|File system for tracking pending changes}}
{{Short description|File system for tracking pending changes}}
{{For|the IBM Journaled File System|JFS (file system)}}
{{For|आईबीएम जर्नल्ड फ़ाइल सिस्टम|जेएफएस (फ़ाइल सिस्टम)}}
{{Use mdy dates|date=October 2019}}


जर्नलिंग [[फाइल सिस्टम]] एक फ़ाइल सिस्टम है जो [[जर्नल (कंप्यूटिंग)]] नामक डेटा संरचना में ऐसे परिवर्तनों के लक्ष्य को रिकॉर्ड करके फ़ाइल सिस्टम के मुख्य भाग में अभी तक प्रतिबद्ध नहीं किए गए परिवर्तनों का ट्रैक रखता है, जो आमतौर पर एक [[गोलाकार लॉग]] होता है। सिस्टम क्रैश या बिजली विफलता की स्थिति में, ऐसे फ़ाइल सिस्टम को डेटा भ्रष्टाचार होने की कम संभावना के साथ अधिक तेज़ी से ऑनलाइन वापस लाया जा सकता है।<ref name="developerworks-1">{{citation|title = Anatomy of Linux journaling file systems|url = http://www.ibm.com/developerworks/library/l-journaling-filesystems/index.html|publisher = [[IBM DeveloperWorks]]|date = June 4, 2008|access-date = April 13, 2009|first = M Tim|last = Jones|archive-url = https://web.archive.org/web/20090221103211/http://www.ibm.com/developerworks/library/l-journaling-filesystems/index.html|archive-date = February 21, 2009|url-status = live}}</ref><ref name="ostep-1">{{citation|title = Crash Consistency: FSCK and Journaling|url = http://pages.cs.wisc.edu/~remzi/OSTEP/file-journaling.pdf|publisher = Arpaci-Dusseau Books|date = January 21, 2014|first1 = Remzi H.|last1 = Arpaci-Dusseau|first2 = Andrea C.|last2 = Arpaci-Dusseau|access-date = January 22, 2014|archive-url = https://web.archive.org/web/20140124115718/http://pages.cs.wisc.edu/~remzi/OSTEP/file-journaling.pdf|archive-date = January 24, 2014|url-status = live}}</ref>
 
वास्तविक कार्यान्वयन के आधार पर, एक जर्नलिंग फ़ाइल सिस्टम केवल संग्रहीत [[ मेटा डेटा ]] का ट्रैक रख सकता है, जिसके परिणामस्वरूप डेटा भ्रष्टाचार की बढ़ती संभावना की कीमत पर प्रदर्शन में सुधार होता है। वैकल्पिक रूप से, एक जर्नलिंग फ़ाइल सिस्टम संग्रहीत डेटा और संबंधित मेटाडेटा दोनों को ट्रैक कर सकता है, जबकि कुछ कार्यान्वयन इस संबंध में चयन योग्य व्यवहार की अनुमति देते हैं।<ref>{{Cite web
 
'''जर्नलिंग [[फाइल सिस्टम]]''' ऐसा फ़ाइल सिस्टम है जो [[जर्नल (कंप्यूटिंग)]] नामक डेटा स्ट्रक्चर में ऐसे चेंजेज़ के गोल को रिकॉर्ड करके फ़ाइल सिस्टम के मुख्य भाग में प्रतिबद्ध नहीं किए गए चेंजेज़ का ट्रैक रखता है, जो सामान्तयः [[गोलाकार लॉग|सर्कुलर लॉग]] होता है। सिस्टम क्रैश या पावर फेल्यर की स्थिति में, ऐसे फ़ाइल सिस्टम को डेटा कर्रप्ट होने की कम संभावना के साथ अधिक तीव्रता से पुनः ऑनलाइन लाया जा सकता है।<ref name="developerworks-1">{{citation|title = Anatomy of Linux journaling file systems|url = http://www.ibm.com/developerworks/library/l-journaling-filesystems/index.html|publisher = [[IBM DeveloperWorks]]|date = June 4, 2008|access-date = April 13, 2009|first = M Tim|last = Jones|archive-url = https://web.archive.org/web/20090221103211/http://www.ibm.com/developerworks/library/l-journaling-filesystems/index.html|archive-date = February 21, 2009|url-status = live}}</ref><ref name="ostep-1">{{citation|title = Crash Consistency: FSCK and Journaling|url = http://pages.cs.wisc.edu/~remzi/OSTEP/file-journaling.pdf|publisher = Arpaci-Dusseau Books|date = January 21, 2014|first1 = Remzi H.|last1 = Arpaci-Dusseau|first2 = Andrea C.|last2 = Arpaci-Dusseau|access-date = January 22, 2014|archive-url = https://web.archive.org/web/20140124115718/http://pages.cs.wisc.edu/~remzi/OSTEP/file-journaling.pdf|archive-date = January 24, 2014|url-status = live}}</ref>
 
वास्तविक इम्प्लीमेंटेशन के आधार पर, जर्नलिंग फ़ाइल सिस्टम केवल स्टोर्ड [[ मेटा डेटा |मेटा डेटा]] का ट्रैक रख सकता है, जिसके परिणामस्वरूप डेटा कर्रप्शन की संभावना में वृद्धि के व्यय पर परफॉरमेंस में उन्नति होती है। वैकल्पिक रूप से, जर्नलिंग फ़ाइल सिस्टम स्टोर्ड डेटा और संबंधित मेटाडेटा दोनों को ट्रैक कर सकता है, जबकि कुछ इम्प्लीमेंटेशन इस संबंध में सेलेक्टेबल बिहेवियर की अनुमति देते हैं।<ref>{{Cite web
  | url = http://linux.die.net/man/8/tune2fs
  | url = http://linux.die.net/man/8/tune2fs
  | title = tune2fs(8) – Linux man page
  | title = tune2fs(8) – Linux man page
Line 13: Line 15:
  | url-status = live
  | url-status = live
  }}</ref>
  }}</ref>
== इतिहास ==
== इतिहास ==
1990 में IBM ने [[AIX]] 3.1 में JFS (फ़ाइल सिस्टम) को पहले UNIX वाणिज्यिक फ़ाइल सिस्टम में से एक के रूप में पेश किया, जिसने जर्नलिंग लागू की।<ref>{{citation|title=Evolution of storage facilities in AIX Version 3 for RISC System/6000 processors | first1 = A. | last1 = Chang | first2 = M.F. | last2 = Mergen | first3 = R.K. | last3 = Rader | first4 = J.A. | last4 = Roberts | first5 = S.L. | last5 = Porter | journal = IBM Journal of Research and Development |volume = 34:1 |date = January 1990| pages = 105–109| doi = 10.1147/rd.341.0105 |url=https://pdf.zlibcdn.com/dtoken/243353b0d047d2ef2a07fbf41a5fbd40/rd.341.0105.pdf}}</ref> अगले वर्ष इस विचार को लॉग-संरचित फ़ाइल सिस्टम पर व्यापक रूप से उद्धृत पेपर में लोकप्रिय बनाया गया।<ref>{{cite conference|url=https://people.eecs.berkeley.edu/~brewer/cs262/LFS.pdf|title=लॉग-स्ट्रक्चर फ़ाइल सिस्टम का डिज़ाइन और कार्यान्वयन|first1=Mendel|last1=Rosembaum|first2=John|last2=Ousterhout|publisher=ACM 13th Annual Symposium on Operating Systems Principles.|date=February 1991}}</ref>
1990 में आईबीएम ने [[AIX|एआईएक्स]] 3.1 में जेएफएस (फ़ाइल सिस्टम) को प्रथम यूनिक्स कमर्शियल फ़ाइल सिस्टम में से एक के रूप में प्रस्तुत किया, जिसने जर्नलिंग को भी इम्प्लीमेंट किया था।<ref>{{citation|title=Evolution of storage facilities in AIX Version 3 for RISC System/6000 processors | first1 = A. | last1 = Chang | first2 = M.F. | last2 = Mergen | first3 = R.K. | last3 = Rader | first4 = J.A. | last4 = Roberts | first5 = S.L. | last5 = Porter | journal = IBM Journal of Research and Development |volume = 34:1 |date = January 1990| pages = 105–109| doi = 10.1147/rd.341.0105 |url=https://pdf.zlibcdn.com/dtoken/243353b0d047d2ef2a07fbf41a5fbd40/rd.341.0105.pdf}}</ref> इसके पश्चात् आगामी वर्ष इस विचार को लॉग-स्ट्रक्चर्ड फ़ाइल सिस्टम पर व्यापक रूप से साइटेड पेपर में लोकप्रिय बनाया गया था।<ref>{{cite conference|url=https://people.eecs.berkeley.edu/~brewer/cs262/LFS.pdf|title=लॉग-स्ट्रक्चर फ़ाइल सिस्टम का डिज़ाइन और कार्यान्वयन|first1=Mendel|last1=Rosembaum|first2=John|last2=Ousterhout|publisher=ACM 13th Annual Symposium on Operating Systems Principles.|date=February 1991}}</ref>
इसके बाद इसे 1993 में माइक्रोसॉफ्ट के [[ विंडोज़ एनटी ]] के [[एनटीएफएस]] फाइल सिस्टम में, 1998 में एप्पल के [[एचएफएस प्लस]] फाइल सिस्टम में और 2001 में [[लिनक्स]] के [[ext3]] फाइल सिस्टम में लागू किया गया।<ref>{{cite web|url=http://marc.info/?l=linux-kernel&m=100650331813822&w=2|title='2.4.15-final' - MARC|website=marc.info|access-date=March 24, 2018}}</ref>
 
 
==तर्कसंगत ==
फ़ाइलों और निर्देशिकाओं में परिवर्तनों को प्रतिबिंबित करने के लिए फ़ाइल सिस्टम को अपडेट करने के लिए आमतौर पर कई अलग-अलग लेखन कार्यों की आवश्यकता होती है। यह डेटा संरचनाओं को अमान्य मध्यवर्ती स्थिति में छोड़ने के लिए लिखने के बीच रुकावट (जैसे बिजली विफलता या सिस्टम [[क्रैश (कंप्यूटिंग)]]) को संभव बनाता है।<ref name="developerworks-1" />


उदाहरण के लिए, यूनिक्स फ़ाइल सिस्टम पर किसी फ़ाइल को हटाने में तीन चरण शामिल होते हैं:<ref>File Systems from Tanenbaum, A.S. (2008). Modern operating systems (3rd ed., pp. 287). Upper Saddle River, NJ: Prentice Hall.</ref>
तत्पश्चात इसे 1993 में माइक्रोसॉफ्ट के [[ विंडोज़ एनटी |विंडोज़ एनटी]] के [[एनटीएफएस]] फाइल सिस्टम में, 1998 में एप्पल के [[एचएफएस प्लस]] फाइल सिस्टम में और 2001 में [[लिनक्स]] के [[ext3]] फाइल सिस्टम में इम्प्लीमेंट किया गया था।<ref>{{cite web|url=http://marc.info/?l=linux-kernel&m=100650331813822&w=2|title='2.4.15-final' - MARC|website=marc.info|access-date=March 24, 2018}}</ref>
# इसकी निर्देशिका प्रविष्टि को हटाया जा रहा है.
==रैशनल ==
# मुक्त [[इनोड]] के पूल में इनोड जारी करना।
फ़ाइलों और डायरेक्ट्रियों में चेंजेज़ को रिफ्लेक्ट करने के लिए तथा फ़ाइल सिस्टम को अपडेट करने के लिए सामान्तयः कई भिन्न-भिन्न राइट ऑपरेशनों की आवश्यकता होती है। इससे राइटिंग के मध्य इंट्रप्शन (जैसे पावर फेल्यर या सिस्टम [[क्रैश (कंप्यूटिंग)]]) के कारण डेटा स्ट्रक्चर्स को इनवैलिड इंटरमीडिएट स्टेट में रखना संभव हो जाता है।<ref name="developerworks-1" />
# सभी डिस्क ब्लॉक को मुक्त डिस्क ब्लॉक के पूल में लौटाना।


यदि चरण 1 के बाद और चरण 2 से पहले कोई दुर्घटना होती है, तो एक अनाथ इनोड होगा और इसलिए [[भंडारण रिसाव]] होगा; यदि चरण 2 और 3 के बीच कोई क्रैश होता है, तो फ़ाइल द्वारा पहले उपयोग किए गए ब्लॉक का उपयोग नई फ़ाइलों के लिए नहीं किया जा सकता है, जिससे फ़ाइल सिस्टम की भंडारण क्षमता प्रभावी रूप से कम हो जाती है। चरणों को पुनः व्यवस्थित करने से भी मदद नहीं मिलती है। यदि चरण 3 चरण 1 से पहले होता है, तो उनके बीच एक दुर्घटना फ़ाइल के ब्लॉक को एक नई फ़ाइल के लिए पुन: उपयोग करने की अनुमति दे सकती है, जिसका अर्थ है कि आंशिक रूप से हटाई गई फ़ाइल में किसी अन्य फ़ाइल की सामग्री का हिस्सा होगा, और किसी भी फ़ाइल में संशोधन दोनों में दिखाई देगा। दूसरी ओर, यदि चरण 2, चरण 1 से पहले होता है, तो उनके बीच एक दुर्घटना के कारण फ़ाइल अस्तित्व में प्रतीत होने के बावजूद अप्राप्य हो जाएगी।
उदाहरण के लिए, यूनिक्स फ़ाइल सिस्टम पर किसी फ़ाइल को डिलीट करने में तीन स्टेप सम्मिलित होते हैं:<ref>File Systems from Tanenbaum, A.S. (2008). Modern operating systems (3rd ed., pp. 287). Upper Saddle River, NJ: Prentice Hall.</ref>
# इसकी डायरेक्टरी एंट्री को रिमूव करना।
# फ्री [[इनोड]] के पूल में इनोड रिलीज़ करना।
# सभी डिस्क ब्लॉक को फ्री डिस्क ब्लॉक के पूल में रिटर्न करना।


ऐसी विसंगतियों का पता लगाने और उनसे उबरने के लिए आम तौर पर ग्राफ सिद्धांत की शर्तों की पूरी शब्दावली की आवश्यकता होती है#इसके डेटा संरचनाओं का चलना, उदाहरण के लिए [[fsck]] (फ़ाइल सिस्टम चेकर) जैसे उपकरण द्वारा।<ref name="ostep-1" />  यह आम तौर पर पढ़ने-लिखने की पहुंच के लिए फ़ाइल सिस्टम को अगली बार माउंट करने से पहले किया जाना चाहिए। यदि फ़ाइल सिस्टम बड़ा है और यदि अपेक्षाकृत कम I/O बैंडविड्थ है, तो इसमें लंबा समय लग सकता है और इसके परिणामस्वरूप लंबे समय तक डाउनटाइम हो सकता है यदि यह शेष सिस्टम को ऑनलाइन वापस आने से रोकता है।
यदि स्टेप 1 के पश्चात् और स्टेप 2 से पूर्व कोई क्रैश होता है, तो ओर्फेंड इनोड होगा और इस कारण से [[भंडारण रिसाव|स्टोरेज लीक]] हो सकती है; यदि स्टेप 2 और 3 के मध्य कोई क्रैश होता है, तो फ़ाइल द्वारा पूर्व उपयोग किए गए ब्लॉक का उपयोग नई फ़ाइलों के लिए नहीं किया जा सकता है, जिससे फ़ाइल सिस्टम की स्टोरेज क्षमता प्रभावी रूप से कम हो जाती है। जिससे स्टेपों को पुनः व्यवस्थित करने से भी सहायता प्राप्त नहीं होती है। यदि स्टेप 3 स्टेप 1 से पूर्व होता है, तो उनके मध्य क्रैश फ़ाइल के ब्लॉक को नई फ़ाइल के लिए पुन: उपयोग करने की अनुमति दे सकता है, जिसका अर्थ है कि पार्शियली डिलीट की गई फ़ाइल में किसी अन्य फ़ाइल के कंटेंट का भाग होगा, और किसी भी फ़ाइल में किया गया संशोधन दोनों में दिखाई देगा। इस प्रकार दूसरी ओर, यदि स्टेप 2, स्टेप 1 से पूर्व होता है, तो उनके मध्य क्रैश के कारण फ़ाइल एक्सिस्ट में प्रतीत होने के पश्चात् भी इनएक्सेसिबल हो जाएगी।


इसे रोकने के लिए, एक जर्नल फ़ाइल सिस्टम एक विशेष क्षेत्र - जर्नल - आवंटित करता है जिसमें वह समय से पहले किए जाने वाले परिवर्तनों को रिकॉर्ड करता है। किसी दुर्घटना के बाद, पुनर्प्राप्ति में फ़ाइल सिस्टम से जर्नल को पढ़ना और इस जर्नल से परिवर्तनों को तब तक दोहराना शामिल होता है जब तक कि फ़ाइल सिस्टम फिर से सुसंगत न हो जाए। इस प्रकार परिवर्तनों को [[परमाणुता (डेटाबेस सिस्टम)]] (विभाज्य नहीं) कहा जाता है, जिसमें वे या तो सफल होते हैं (मूल रूप से सफल होते हैं या पुनर्प्राप्ति के दौरान पूरी तरह से दोहराए जाते हैं), या बिल्कुल भी दोबारा नहीं दोहराए जाते हैं (छोड़ दिए जाते हैं क्योंकि वे अभी तक पूरी तरह से लिखे नहीं गए थे) दुर्घटना घटित होने से पहले का जर्नल)।
इस प्रकार की इनकंसिस्टेंसी को ज्ञात करने और उसे रिकवर करने के लिए सामान्तयः इसके डेटा स्ट्रक्चर को पूर्ण परीक्षण की आवश्यकता होती है, उदाहरण के लिए [[fsck]] (फ़ाइल सिस्टम चेकर) टूल द्वारा इसका परीक्षण किया जा सकता है।<ref name="ostep-1" /> इसे सामान्तयः रीड-राइट एक्सेस के लिए फ़ाइल सिस्टम को पुनः माउंट करने से पूर्व किया जाना चाहिए। यदि फ़ाइल सिस्टम बड़ा है और यदि अपेक्षाकृत कम इनपुट/आउटपुट बैंडविड्थ है, तो इसमें अधिक समय लग सकता है और इसके परिणामस्वरूप अधिक समय तक डाउनटाइम हो सकता है यदि यह रेस्ट सिस्टम को ऑनलाइन पुनः आने से ब्लॉक करता है।


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


जब जर्नल स्वयं लिखा जा रहा हो तो जर्नल के आंतरिक प्रारूप को क्रैश होने से बचाना चाहिए। कई जर्नल कार्यान्वयन (जैसे कि [[ext4]] में JBD2 परत) एक चेकसम के साथ लॉग किए गए प्रत्येक परिवर्तन को इस समझ के साथ ब्रैकेट करते हैं कि एक क्रैश एक लापता (या बेमेल) चेकसम के साथ आंशिक रूप से लिखित परिवर्तन छोड़ देगा जिसे जर्नल को दोबारा चलाने पर आसानी से अनदेखा किया जा सकता है। अगला रिमाउंट.
== टेक्निक ==
कुछ फ़ाइल सिस्टम जर्नल को रेगुलर फ़ाइल के रूप में ग्रो करने, श्रिंक करने और रिएलोकेट करने की अनुमति देते हैं, जबकि अन्य जर्नल को कोंटिज्युअस एरिया अथवा हिडन फ़ाइल में रखते हैं जो गारंटी देता है कि फ़ाइल सिस्टम माउंट होने पर वह न तो मूव होगा न ही उसके आकर में परिवर्तन आएगा। इस प्रकार कुछ फ़ाइल सिस्टम एक्सटर्नल जर्नल को भिन्न डिवाइस पर भी अनुमति दे सकते हैं, जिसमें [[ ठोस राज्य ड्राइव |सॉलिड-स्टेट ड्राइव]] या बैटरी-बैक्ड नॉन-वोलेटाइल रैम सम्मिलित हैं। जर्नल में चेंजेज़ को एडिशनल रेडंडेन्सी के लिए स्वयं जर्नल किया जा सकता है, या डिवाइस फेलियर से बचाने के लिए जर्नल को कई फिजिकल वॉल्यूम्स में डिस्ट्रीब्यूट किया जा सकता है।


=== भौतिक पत्रिकाएँ ===
जब जर्नल स्वयं लिखा जा रहा हो तो जर्नल के इंटरनल फॉर्मेट को क्रैश होने से बचाना चाहिए। कई जर्नल इम्प्लीमेंटेशन (जैसे कि [[ext4]] में जेबीडी2 लेयर) चेकसम के साथ लॉग किए गए प्रत्येक परिवर्तन को इस समझ के साथ ब्रैकेट करते हैं कि क्रैश मिसिंग (या मिसमैच) चेकसम के साथ पार्शियली रिटेन चेंज त्याग देगा जिसे नेक्स्ट रीमाउंट पर जर्नल को रीप्ले करने पर सरलता से अनदेखा किया जा सकता है।
एक भौतिक जर्नल प्रत्येक ब्लॉक की एक अग्रिम प्रतिलिपि लॉग करता है जिसे बाद में मुख्य फ़ाइल सिस्टम में लिखा जाएगा। यदि मुख्य फ़ाइल सिस्टम को लिखते समय कोई दुर्घटना होती है, तो फ़ाइल सिस्टम को अगली बार माउंट करने पर लेखन को पूरा करने के लिए फिर से चलाया जा सकता है। यदि जर्नल में लेखन लॉग करते समय कोई दुर्घटना होती है, तो आंशिक लेखन में एक लापता या बेमेल चेकसम होगा और अगले माउंट पर इसे अनदेखा किया जा सकता है।


भौतिक पत्रिकाएँ एक महत्वपूर्ण प्रदर्शन जुर्माना लगाती हैं क्योंकि प्रत्येक परिवर्तित ब्लॉक को दो बार भंडारण के लिए प्रतिबद्ध किया जाना चाहिए, लेकिन पूर्ण दोष संरक्षण की आवश्यकता होने पर स्वीकार्य हो सकता है।<ref name="tweedie-1">{{citation|title = Ext3, journaling filesystem|last = Tweedie|first = Stephen|journal = Proceedings of the Ottawa Linux Symposium|pages = 24–29|year = 2000}}</ref>
=== फिजिकल जर्नल्स ===
फिजिकल जर्नल प्रत्येक ब्लॉक की एडवांस कॉपी लॉग करता है जिसे मेन फ़ाइल सिस्टम में राइट किया जाता है। यदि मेन फ़ाइल सिस्टम को राइट करते समय कोई क्रैश होता है, तो फ़ाइल सिस्टम को पुनः माउंट करने पर राइटिंग को पूर्ण करने के लिए फिर से रीप्ले किया जाता है। यदि जर्नल में राइटिंग लॉग करते समय कोई क्रैश होता है, तो पार्शियल राइट में मिसिंग या मिसमैच चेकसम होगा और नेक्स्ट माउंट पर इसे अनदेखा किया जा सकता है।


फिजिकल जर्नल्स महत्वपूर्ण परफॉरमेंस पेनल्टी लगाते हैं क्योंकि प्रत्येक चेंज्ड ब्लॉक को ट्वाइस स्टोरेज के लिए प्रतिबद्ध किया जाना चाहिए, किन्तु एब्सोल्यूट फाल्ट प्रोटेक्शन की आवश्यकता होने पर यह स्वीकार्य हो सकता है।<ref name="tweedie-1">{{citation|title = Ext3, journaling filesystem|last = Tweedie|first = Stephen|journal = Proceedings of the Ottawa Linux Symposium|pages = 24–29|year = 2000}}</ref>
=== लॉजिकल जर्नल ===
लॉजिकल जर्नल, जर्नल में फ़ाइल मेटाडेटा में केवल चेंजेज़ को स्टोर्ड करता है, और बेटर राइट परफॉरमेंस के लिए फाल्ट टॉलरेंस का व्यापार करता है।<ref>{{citation|title = Analysis and Evolution of Journaling File Systems|first1 = Vijayan|last1 = Prabhakaran|first2 = Andrea C|last2 = Arpaci-Dusseau|first3 = Remzi H|last3 = Arpaci-Dusseau|url = https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf|journal = 2005 USENIX Annual Technical Conference|publisher = USENIX Association|access-date = July 27, 2007|archive-url = https://web.archive.org/web/20070926161625/https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf|archive-date = September 26, 2007|url-status = live}}.</ref> लॉजिकल जर्नल वाला फ़ाइल सिस्टम क्रैश होने के पश्चात् भी रिकवर हो जाता है, किन्तु अनजर्नल फ़ाइल डेटा और जर्नल मेटाडेटा को एक-दूसरे के साथ सिंक होने की अनुमति दे सकता है, जिससे डेटा करप्शन हो सकता है।


=== तार्किक जर्नल ===
उदाहरण के लिए, किसी फ़ाइल में ऍपेन्डिंग पर तीन भिन्न-भिन्न राइट्स सम्मिलित हो सकते हैं:
एक तार्किक जर्नल जर्नल में फ़ाइल मेटाडेटा में केवल परिवर्तनों को संग्रहीत करता है, और काफी बेहतर लेखन प्रदर्शन के लिए दोष सहनशीलता का व्यापार करता है।<ref>{{citation|title = Analysis and Evolution of Journaling File Systems|first1 = Vijayan|last1 = Prabhakaran|first2 = Andrea C|last2 = Arpaci-Dusseau|first3 = Remzi H|last3 = Arpaci-Dusseau|url = https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf|journal = 2005 USENIX Annual Technical Conference|publisher = USENIX Association|access-date = July 27, 2007|archive-url = https://web.archive.org/web/20070926161625/https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf|archive-date = September 26, 2007|url-status = live}}.</ref> लॉजिकल जर्नल वाला फ़ाइल सिस्टम क्रैश होने के बाद भी जल्दी ठीक हो जाता है, लेकिन अनजर्नल फ़ाइल डेटा और जर्नल मेटाडेटा को एक-दूसरे के साथ समन्वयित होने की अनुमति दे सकता है, जिससे डेटा भ्रष्टाचार हो सकता है।
# फ़ाइल का इनोड, फ़ाइल के मेटाडेटा में नोट करने के लिए कि इसके आकार में वृद्धि हो गयी है।
 
#ऍपेन्डेड डेटा के लिए स्पेस के एलोकेशन को मार्क करने के लिए फ्री स्पेस मैप होता है।
उदाहरण के लिए, किसी फ़ाइल में जोड़ने पर तीन अलग-अलग लेखन शामिल हो सकते हैं:
#ऍपेन्डेड डेटा लिखने के लिए नया एलोकेट स्पेस होता है।
# फ़ाइल का इनोड, फ़ाइल के मेटाडेटा में नोट करने के लिए कि इसका आकार बढ़ गया है।
केवल-मेटाडेटा जर्नल में, स्टेप 3 लॉग नहीं किया जाएगा। यदि स्टेप 3 पूर्ण नहीं किया गया था, किन्तु रिकवरी के समय स्टेप 1 और 2 को रीप्ले किया जाता है, तो फ़ाइल को गार्बेज के साथ अपेण्ड कर दिया जाएगा।
# मुक्त स्थान मानचित्र, जोड़े जाने वाले डेटा के लिए स्थान के आवंटन को चिह्नित करने के लिए।
# नया आवंटित स्थान, वास्तव में संलग्न डेटा लिखने के लिए।
केवल-मेटाडेटा जर्नल में, चरण 3 लॉग नहीं किया जाएगा। यदि चरण 3 पूरा नहीं किया गया था, लेकिन पुनर्प्राप्ति के दौरान चरण 1 और 2 को दोबारा चलाया जाता है, तो फ़ाइल को कचरे के साथ जोड़ दिया जाएगा।
 
===खतरे लिखें ===
अधिकांश ऑपरेटिंग सिस्टम में राइट कैश थ्रूपुट को अधिकतम करने के लिए अपने राइट्स को सॉर्ट करता है ([[एलिवेटर एल्गोरिदम]] या कुछ समान योजना का उपयोग करके)। मेटाडेटा-केवल जर्नल के साथ आउट-ऑफ़-ऑर्डर लेखन के खतरे से बचने के लिए, फ़ाइल डेटा के लिए लेखन को क्रमबद्ध किया जाना चाहिए ताकि वे अपने संबंधित मेटाडेटा से पहले भंडारण के लिए प्रतिबद्ध हों। इसे लागू करना मुश्किल हो सकता है क्योंकि इसमें फ़ाइल सिस्टम ड्राइवर और राइट कैश के बीच ऑपरेटिंग सिस्टम कर्नेल के भीतर समन्वय की आवश्यकता होती है। आउट-ऑफ़-ऑर्डर लिखने का ख़तरा तब भी उत्पन्न हो सकता है जब कोई डिवाइस अपने अंतर्निहित स्टोरेज में तुरंत ब्लॉक नहीं लिख सकता है, यानी, विलंबित लेखन सक्षम होने के कारण यह अपने राइट-कैश को डिस्क पर फ्लश नहीं कर सकता है।
 
मामले को जटिल बनाने के लिए, कई बड़े भंडारण उपकरणों के पास अपने स्वयं के लेखन कैश होते हैं, जिसमें वे बेहतर प्रदर्शन के लिए आक्रामक रूप से लेखन को पुन: व्यवस्थित कर सकते हैं। (यह विशेष रूप से चुंबकीय हार्ड ड्राइव पर आम है, जिसमें बड़ी खोज विलंबता होती है जिसे एलेवेटर सॉर्टिंग के साथ कम किया जा सकता है।) कुछ जर्नलिंग फ़ाइल सिस्टम रूढ़िवादी रूप से मानते हैं कि ऐसी राइट-रीऑर्डरिंग हमेशा होती है, और डिवाइस को फ्लश करने के लिए मजबूर करके शुद्धता के लिए प्रदर्शन का त्याग करते हैं। जर्नल में कुछ बिंदुओं पर कैश (ext3 और ext4 में बाधाएं कहा जाता है)।<ref>{{citation|title = Barriers and journaling filesystems|url = https://lwn.net/Articles/283161/|first = Jonathan|last = Corbet|date = May 21, 2008|access-date = March 6, 2010|archive-url = https://web.archive.org/web/20100314050156/http://lwn.net/Articles/283161/|archive-date = March 14, 2010|url-status = live}}</ref>


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


स्थिति को विषम बनाने के लिए, कई बड़े स्टोरेज डिवाइसेस के निकट स्वयं के राइट कैश होते हैं, जिसमें वे परफॉरमेंस के लिए आक्रामक रूप से राइट्स को रिआर्डर कर सकते हैं। (यह विशेष रूप से मैग्नेटिक हार्ड ड्राइव पर सामान्य है, जिसमें बड़ी सीक लेटेंसी होती है जिसे एलेवेटर सॉर्टिंग के साथ कम किया जा सकता है।) कुछ जर्नलिंग फ़ाइल सिस्टम रूढ़िवादी रूप से मानते हैं कि ऐसी राइट-रीऑर्डरिंग सदैव होती है, और डिवाइस को जर्नल में कुछ बिंदुओं पर अपने कैश को फ्लश करने के लिए विवश करके करेक्टनेस के लिए परफॉरमेंस को सैक्रिफाइस करते हैं (जिसे ext3 और ext4 में बैरियर कहा जाता है)।<ref>{{citation|title = Barriers and journaling filesystems|url = https://lwn.net/Articles/283161/|first = Jonathan|last = Corbet|date = May 21, 2008|access-date = March 6, 2010|archive-url = https://web.archive.org/web/20100314050156/http://lwn.net/Articles/283161/|archive-date = March 14, 2010|url-status = live}}</ref>
== विकल्प ==
== विकल्प ==


=== [[नरम अद्यतन]] ===
=== [[नरम अद्यतन|सॉफ्ट अपडेट्स]] ===
कुछ [[ यूनिक्स फ़ाइल सिस्टम ]] कार्यान्वयन जर्नलिंग से बचते हैं और इसके बजाय सॉफ्ट अपडेट लागू करते हैं: वे अपने राइट्स को इस तरह से ऑर्डर करते हैं कि ऑन-डिस्क फाइल सिस्टम कभी भी असंगत नहीं होता है, या क्रैश की स्थिति में बनाई जा सकने वाली एकमात्र असंगतता स्टोरेज है रिसना। इन लीक से उबरने के लिए, मुक्त स्थान मानचित्र को अगले माउंट पर फ़ाइल सिस्टम के पूर्ण चलने के विरुद्ध समेटा जाता है। यह [[कचरा संग्रहण (कंप्यूटर विज्ञान)]] आमतौर पर पृष्ठभूमि में किया जाता है।<ref>{{citation|title = Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems|url = http://www.usenix.org/event/usenix2000/general/full_papers/seltzer/seltzer_html|journal = 2000 USENIX Annual Technical Conference|first1 = Margo I|last1 = Seltzer|first2 = Gregory R|last2 = Ganger|first3 = M Kirk|last3 = McKusick|publisher = USENIX Association|access-date = July 27, 2007|archive-url = https://web.archive.org/web/20071026004711/http://www.usenix.org/event/usenix2000/general/full_papers/seltzer/seltzer_html/|archive-date = October 26, 2007|url-status = live}}.</ref>
कुछ [[ यूनिक्स फ़ाइल सिस्टम |यूनिक्स फ़ाइल सिस्टम]] इम्प्लीमेंटेशन जर्नलिंग से बचते हैं और इसके अतिरिक्त सॉफ्ट अपडेट इम्प्लीमेंट करते हैं: वे स्वयं के राइट्स को इस प्रकार से ऑर्डर करते हैं कि ऑन-डिस्क फाइल सिस्टम कभी भी इनकंसिस्टेंट नहीं होता है, या क्रैश की स्थिति में उत्पन्न होने वाली इनकंसिस्टेंसी स्टोरेज लीक होती है। इन लीक से रिकवर करने के लिए, फ्री स्पेस मैप को नेक्स्ट माउंट पर फ़ाइल सिस्टम के फुल वाक के विरुद्ध स्वीकार किया जाता है। यह [[कचरा संग्रहण (कंप्यूटर विज्ञान)|गार्बेज कलेक्शन (कंप्यूटर विज्ञान)]] सामान्तयः बैकग्राउंड में किया जाता है।<ref>{{citation|title = Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems|url = http://www.usenix.org/event/usenix2000/general/full_papers/seltzer/seltzer_html|journal = 2000 USENIX Annual Technical Conference|first1 = Margo I|last1 = Seltzer|first2 = Gregory R|last2 = Ganger|first3 = M Kirk|last3 = McKusick|publisher = USENIX Association|access-date = July 27, 2007|archive-url = https://web.archive.org/web/20071026004711/http://www.usenix.org/event/usenix2000/general/full_papers/seltzer/seltzer_html/|archive-date = October 26, 2007|url-status = live}}.</ref>
 
=== [[लॉग-संरचित फ़ाइल सिस्टम|लॉग-स्ट्रक्चर्ड फ़ाइल सिस्टम]] ===
लॉग-स्ट्रक्चर्ड फ़ाइल सिस्टम में, राइट-ट्वाइस पेनल्टी प्रारम्भ नहीं होती है क्योंकि जर्नल स्वयं फ़ाइल सिस्टम है: यह संपूर्ण स्टोरेज डिवाइस पर अधिकार कर लेता है और इसे स्ट्रक्चर्ड किया जाता है जिससे इसे सामान्य फ़ाइल सिस्टम की भाँति ही ट्रैवर्स किया जा सकता है।


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


== यह भी देखें ==
== यह भी देखें ==
*[[एसिड]]
*[[एसिड]]
* [[फ़ाइल सिस्टम की तुलना]]
* [[फ़ाइल सिस्टम की तुलना|फ़ाइल सिस्टम की उपमा]]
* [[डेटाबेस]]
* [[डेटाबेस]]
* [[आशय लॉग]]
* [[आशय लॉग|इंटेंट लॉग]]
* जेएफएस (फाइल सिस्टम)|जर्नल फाइल सिस्टम (जेएफएस){{snd}} आईबीएम द्वारा बनाया गया एक फाइल सिस्टम
* जेएफएस (फाइल सिस्टम){{snd}}आईबीएम द्वारा बनाया गया फाइल सिस्टम
* [[लेनदेन प्रक्रिया]]
* [[लेनदेन प्रक्रिया|ट्रांसेक्शन प्रोसेसिंग]]
* फ़ाइल सिस्टम का संस्करणीकरण
* वर्ज़निंग फाइल सिस्टम


== संदर्भ ==
== संदर्भ ==
{{Reflist|30em}}
{{Reflist|30em}}


{{File systems}}
[[Category:Articles with hatnote templates targeting a nonexistent page]]
{{Operating system}}
[[Category:Collapse templates]]
[[Category: कंप्यूटर फ़ाइल सिस्टम]]  
 
 
 
[[Category: Machine Translated Page]]
[[Category:Created On 15/08/2023]]
[[Category:Created On 15/08/2023]]
[[Category:Machine Translated Page]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Sidebars with styles needing conversion]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Vigyan Ready]]

Latest revision as of 09:55, 1 December 2023

For आईबीएम जर्नल्ड फ़ाइल सिस्टम, see जेएफएस (फ़ाइल सिस्टम).


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

वास्तविक इम्प्लीमेंटेशन के आधार पर, जर्नलिंग फ़ाइल सिस्टम केवल स्टोर्ड मेटा डेटा का ट्रैक रख सकता है, जिसके परिणामस्वरूप डेटा कर्रप्शन की संभावना में वृद्धि के व्यय पर परफॉरमेंस में उन्नति होती है। वैकल्पिक रूप से, जर्नलिंग फ़ाइल सिस्टम स्टोर्ड डेटा और संबंधित मेटाडेटा दोनों को ट्रैक कर सकता है, जबकि कुछ इम्प्लीमेंटेशन इस संबंध में सेलेक्टेबल बिहेवियर की अनुमति देते हैं।[3]

इतिहास

1990 में आईबीएम ने एआईएक्स 3.1 में जेएफएस (फ़ाइल सिस्टम) को प्रथम यूनिक्स कमर्शियल फ़ाइल सिस्टम में से एक के रूप में प्रस्तुत किया, जिसने जर्नलिंग को भी इम्प्लीमेंट किया था।[4] इसके पश्चात् आगामी वर्ष इस विचार को लॉग-स्ट्रक्चर्ड फ़ाइल सिस्टम पर व्यापक रूप से साइटेड पेपर में लोकप्रिय बनाया गया था।[5]

तत्पश्चात इसे 1993 में माइक्रोसॉफ्ट के विंडोज़ एनटी के एनटीएफएस फाइल सिस्टम में, 1998 में एप्पल के एचएफएस प्लस फाइल सिस्टम में और 2001 में लिनक्स के ext3 फाइल सिस्टम में इम्प्लीमेंट किया गया था।[6]

रैशनल

फ़ाइलों और डायरेक्ट्रियों में चेंजेज़ को रिफ्लेक्ट करने के लिए तथा फ़ाइल सिस्टम को अपडेट करने के लिए सामान्तयः कई भिन्न-भिन्न राइट ऑपरेशनों की आवश्यकता होती है। इससे राइटिंग के मध्य इंट्रप्शन (जैसे पावर फेल्यर या सिस्टम क्रैश (कंप्यूटिंग)) के कारण डेटा स्ट्रक्चर्स को इनवैलिड इंटरमीडिएट स्टेट में रखना संभव हो जाता है।[1]

उदाहरण के लिए, यूनिक्स फ़ाइल सिस्टम पर किसी फ़ाइल को डिलीट करने में तीन स्टेप सम्मिलित होते हैं:[7]

  1. इसकी डायरेक्टरी एंट्री को रिमूव करना।
  2. फ्री इनोड के पूल में इनोड रिलीज़ करना।
  3. सभी डिस्क ब्लॉक को फ्री डिस्क ब्लॉक के पूल में रिटर्न करना।

यदि स्टेप 1 के पश्चात् और स्टेप 2 से पूर्व कोई क्रैश होता है, तो ओर्फेंड इनोड होगा और इस कारण से स्टोरेज लीक हो सकती है; यदि स्टेप 2 और 3 के मध्य कोई क्रैश होता है, तो फ़ाइल द्वारा पूर्व उपयोग किए गए ब्लॉक का उपयोग नई फ़ाइलों के लिए नहीं किया जा सकता है, जिससे फ़ाइल सिस्टम की स्टोरेज क्षमता प्रभावी रूप से कम हो जाती है। जिससे स्टेपों को पुनः व्यवस्थित करने से भी सहायता प्राप्त नहीं होती है। यदि स्टेप 3 स्टेप 1 से पूर्व होता है, तो उनके मध्य क्रैश फ़ाइल के ब्लॉक को नई फ़ाइल के लिए पुन: उपयोग करने की अनुमति दे सकता है, जिसका अर्थ है कि पार्शियली डिलीट की गई फ़ाइल में किसी अन्य फ़ाइल के कंटेंट का भाग होगा, और किसी भी फ़ाइल में किया गया संशोधन दोनों में दिखाई देगा। इस प्रकार दूसरी ओर, यदि स्टेप 2, स्टेप 1 से पूर्व होता है, तो उनके मध्य क्रैश के कारण फ़ाइल एक्सिस्ट में प्रतीत होने के पश्चात् भी इनएक्सेसिबल हो जाएगी।

इस प्रकार की इनकंसिस्टेंसी को ज्ञात करने और उसे रिकवर करने के लिए सामान्तयः इसके डेटा स्ट्रक्चर को पूर्ण परीक्षण की आवश्यकता होती है, उदाहरण के लिए fsck (फ़ाइल सिस्टम चेकर) टूल द्वारा इसका परीक्षण किया जा सकता है।[2] इसे सामान्तयः रीड-राइट एक्सेस के लिए फ़ाइल सिस्टम को पुनः माउंट करने से पूर्व किया जाना चाहिए। यदि फ़ाइल सिस्टम बड़ा है और यदि अपेक्षाकृत कम इनपुट/आउटपुट बैंडविड्थ है, तो इसमें अधिक समय लग सकता है और इसके परिणामस्वरूप अधिक समय तक डाउनटाइम हो सकता है यदि यह रेस्ट सिस्टम को ऑनलाइन पुनः आने से ब्लॉक करता है।

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

टेक्निक

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

जब जर्नल स्वयं लिखा जा रहा हो तो जर्नल के इंटरनल फॉर्मेट को क्रैश होने से बचाना चाहिए। कई जर्नल इम्प्लीमेंटेशन (जैसे कि ext4 में जेबीडी2 लेयर) चेकसम के साथ लॉग किए गए प्रत्येक परिवर्तन को इस समझ के साथ ब्रैकेट करते हैं कि क्रैश मिसिंग (या मिसमैच) चेकसम के साथ पार्शियली रिटेन चेंज त्याग देगा जिसे नेक्स्ट रीमाउंट पर जर्नल को रीप्ले करने पर सरलता से अनदेखा किया जा सकता है।

फिजिकल जर्नल्स

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

फिजिकल जर्नल्स महत्वपूर्ण परफॉरमेंस पेनल्टी लगाते हैं क्योंकि प्रत्येक चेंज्ड ब्लॉक को ट्वाइस स्टोरेज के लिए प्रतिबद्ध किया जाना चाहिए, किन्तु एब्सोल्यूट फाल्ट प्रोटेक्शन की आवश्यकता होने पर यह स्वीकार्य हो सकता है।[8]

लॉजिकल जर्नल

लॉजिकल जर्नल, जर्नल में फ़ाइल मेटाडेटा में केवल चेंजेज़ को स्टोर्ड करता है, और बेटर राइट परफॉरमेंस के लिए फाल्ट टॉलरेंस का व्यापार करता है।[9] लॉजिकल जर्नल वाला फ़ाइल सिस्टम क्रैश होने के पश्चात् भी रिकवर हो जाता है, किन्तु अनजर्नल फ़ाइल डेटा और जर्नल मेटाडेटा को एक-दूसरे के साथ सिंक होने की अनुमति दे सकता है, जिससे डेटा करप्शन हो सकता है।

उदाहरण के लिए, किसी फ़ाइल में ऍपेन्डिंग पर तीन भिन्न-भिन्न राइट्स सम्मिलित हो सकते हैं:

  1. फ़ाइल का इनोड, फ़ाइल के मेटाडेटा में नोट करने के लिए कि इसके आकार में वृद्धि हो गयी है।
  2. ऍपेन्डेड डेटा के लिए स्पेस के एलोकेशन को मार्क करने के लिए फ्री स्पेस मैप होता है।
  3. ऍपेन्डेड डेटा लिखने के लिए नया एलोकेट स्पेस होता है।

केवल-मेटाडेटा जर्नल में, स्टेप 3 लॉग नहीं किया जाएगा। यदि स्टेप 3 पूर्ण नहीं किया गया था, किन्तु रिकवरी के समय स्टेप 1 और 2 को रीप्ले किया जाता है, तो फ़ाइल को गार्बेज के साथ अपेण्ड कर दिया जाएगा।

राइट हैज़ार्डस

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

स्थिति को विषम बनाने के लिए, कई बड़े स्टोरेज डिवाइसेस के निकट स्वयं के राइट कैश होते हैं, जिसमें वे परफॉरमेंस के लिए आक्रामक रूप से राइट्स को रिआर्डर कर सकते हैं। (यह विशेष रूप से मैग्नेटिक हार्ड ड्राइव पर सामान्य है, जिसमें बड़ी सीक लेटेंसी होती है जिसे एलेवेटर सॉर्टिंग के साथ कम किया जा सकता है।) कुछ जर्नलिंग फ़ाइल सिस्टम रूढ़िवादी रूप से मानते हैं कि ऐसी राइट-रीऑर्डरिंग सदैव होती है, और डिवाइस को जर्नल में कुछ बिंदुओं पर अपने कैश को फ्लश करने के लिए विवश करके करेक्टनेस के लिए परफॉरमेंस को सैक्रिफाइस करते हैं (जिसे ext3 और ext4 में बैरियर कहा जाता है)।[10]

विकल्प

सॉफ्ट अपडेट्स

कुछ यूनिक्स फ़ाइल सिस्टम इम्प्लीमेंटेशन जर्नलिंग से बचते हैं और इसके अतिरिक्त सॉफ्ट अपडेट इम्प्लीमेंट करते हैं: वे स्वयं के राइट्स को इस प्रकार से ऑर्डर करते हैं कि ऑन-डिस्क फाइल सिस्टम कभी भी इनकंसिस्टेंट नहीं होता है, या क्रैश की स्थिति में उत्पन्न होने वाली इनकंसिस्टेंसी स्टोरेज लीक होती है। इन लीक से रिकवर करने के लिए, फ्री स्पेस मैप को नेक्स्ट माउंट पर फ़ाइल सिस्टम के फुल वाक के विरुद्ध स्वीकार किया जाता है। यह गार्बेज कलेक्शन (कंप्यूटर विज्ञान) सामान्तयः बैकग्राउंड में किया जाता है।[11]

लॉग-स्ट्रक्चर्ड फ़ाइल सिस्टम

लॉग-स्ट्रक्चर्ड फ़ाइल सिस्टम में, राइट-ट्वाइस पेनल्टी प्रारम्भ नहीं होती है क्योंकि जर्नल स्वयं फ़ाइल सिस्टम है: यह संपूर्ण स्टोरेज डिवाइस पर अधिकार कर लेता है और इसे स्ट्रक्चर्ड किया जाता है जिससे इसे सामान्य फ़ाइल सिस्टम की भाँति ही ट्रैवर्स किया जा सकता है।

कॉपी-ऑन-राइट फ़ाइल सिस्टम

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

यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 Jones, M Tim (June 4, 2008), Anatomy of Linux journaling file systems, IBM DeveloperWorks, archived from the original on February 21, 2009, retrieved April 13, 2009
  2. ↑ 2.0 2.1 Arpaci-Dusseau, Remzi H.; Arpaci-Dusseau, Andrea C. (January 21, 2014), Crash Consistency: FSCK and Journaling (PDF), Arpaci-Dusseau Books, archived (PDF) from the original on January 24, 2014, retrieved January 22, 2014
  3. ↑ "tune2fs(8) – Linux man page". linux.die.net. Archived from the original on February 25, 2015. Retrieved February 20, 2015.
  4. ↑ Chang, A.; Mergen, M.F.; Rader, R.K.; Roberts, J.A.; Porter, S.L. (January 1990), "Evolution of storage facilities in AIX Version 3 for RISC System/6000 processors" (PDF), IBM Journal of Research and Development, 34:1: 105–109, doi:10.1147/rd.341.0105
  5. ↑ Rosembaum, Mendel; Ousterhout, John (February 1991). लॉग-स्ट्रक्चर फ़ाइल सिस्टम का डिज़ाइन और कार्यान्वयन (PDF). ACM 13th Annual Symposium on Operating Systems Principles.
  6. ↑ "'2.4.15-final' - MARC". marc.info. Retrieved March 24, 2018.
  7. ↑ File Systems from Tanenbaum, A.S. (2008). Modern operating systems (3rd ed., pp. 287). Upper Saddle River, NJ: Prentice Hall.
  8. ↑ Tweedie, Stephen (2000), "Ext3, journaling filesystem", Proceedings of the Ottawa Linux Symposium: 24–29
  9. ↑ Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H, "Analysis and Evolution of Journaling File Systems" (PDF), 2005 USENIX Annual Technical Conference, USENIX Association, archived (PDF) from the original on September 26, 2007, retrieved July 27, 2007.
  10. ↑ Corbet, Jonathan (May 21, 2008), Barriers and journaling filesystems, archived from the original on March 14, 2010, retrieved March 6, 2010
  11. ↑ Seltzer, Margo I; Ganger, Gregory R; McKusick, M Kirk, "Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems", 2000 USENIX Annual Technical Conference, USENIX Association, archived from the original on October 26, 2007, retrieved July 27, 2007.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=जर्नलिंग_फ़ाइल_सिस्टम&oldid=275098’