जर्नलिंग फ़ाइल सिस्टम: Difference between revisions
(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}} जर्नलि...") |
No edit summary |
||
| 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|the IBM Journaled File System|JFS (file system)}} | ||
जर्नलिंग [[फाइल सिस्टम]] | |||
वास्तविक | '''जर्नलिंग [[फाइल सिस्टम]]''' ऐसा फ़ाइल सिस्टम है जो [[जर्नल (कंप्यूटिंग)]] नामक डेटा स्ट्रक्चर में ऐसे चेंजेज़ के गोल को रिकॉर्ड करके फ़ाइल सिस्टम के मुख्य भाग में अभी तक प्रतिबद्ध नहीं किए गए चेंजेज़ का ट्रैक रखता है, जो सामान्तयः [[गोलाकार लॉग|सर्कुलर लॉग]] होता है। सिस्टम क्रैश या पावर फेल्यर की स्थिति में, ऐसे फ़ाइल सिस्टम को डेटा कर्रप्ट होने की कम संभावना के साथ अधिक तीव्रता से पुनः ऑनलाइन लाया जा सकता है।<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 14: | ||
| url-status = live | | url-status = live | ||
}}</ref> | }}</ref> | ||
== इतिहास == | == इतिहास == | ||
1990 में IBM ने [[AIX]] 3.1 में JFS (फ़ाइल सिस्टम) को पहले UNIX वाणिज्यिक फ़ाइल सिस्टम में से | 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> | ||
इसके बाद इसे 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> | इसके बाद इसे 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> | उदाहरण के लिए, यूनिक्स फ़ाइल सिस्टम पर किसी फ़ाइल को हटाने में तीन चरण शामिल होते हैं:<ref>File Systems from Tanenbaum, A.S. (2008). Modern operating systems (3rd ed., pp. 287). Upper Saddle River, NJ: Prentice Hall.</ref> | ||
| Line 28: | Line 30: | ||
# सभी डिस्क ब्लॉक को मुक्त डिस्क ब्लॉक के पूल में लौटाना। | # सभी डिस्क ब्लॉक को मुक्त डिस्क ब्लॉक के पूल में लौटाना। | ||
यदि चरण 1 के बाद और चरण 2 से पहले कोई दुर्घटना होती है, तो | यदि चरण 1 के बाद और चरण 2 से पहले कोई दुर्घटना होती है, तो अनाथ इनोड होगा और इसलिए [[भंडारण रिसाव]] होगा; यदि चरण 2 और 3 के बीच कोई क्रैश होता है, तो फ़ाइल द्वारा पहले उपयोग किए गए ब्लॉक का उपयोग नई फ़ाइलों के लिए नहीं किया जा सकता है, जिससे फ़ाइल सिस्टम की भंडारण क्षमता प्रभावी रूप से कम हो जाती है। चरणों को पुनः व्यवस्थित करने से भी मदद नहीं मिलती है। यदि चरण 3 चरण 1 से पहले होता है, तो उनके बीच दुर्घटना फ़ाइल के ब्लॉक को नई फ़ाइल के लिए पुन: उपयोग करने की अनुमति दे सकती है, जिसका अर्थ है कि आंशिक रूप से हटाई गई फ़ाइल में किसी अन्य फ़ाइल की सामग्री का हिस्सा होगा, और किसी भी फ़ाइल में संशोधन दोनों में दिखाई देगा। दूसरी ओर, यदि चरण 2, चरण 1 से पहले होता है, तो उनके बीच दुर्घटना के कारण फ़ाइल अस्तित्व में प्रतीत होने के बावजूद अप्राप्य हो जाएगी। | ||
ऐसी विसंगतियों का पता लगाने और उनसे उबरने के लिए आम तौर पर ग्राफ सिद्धांत की शर्तों की पूरी शब्दावली की आवश्यकता होती है#इसके डेटा | ऐसी विसंगतियों का पता लगाने और उनसे उबरने के लिए आम तौर पर ग्राफ सिद्धांत की शर्तों की पूरी शब्दावली की आवश्यकता होती है#इसके डेटा स्ट्रक्चरओं का चलना, उदाहरण के लिए [[fsck]] (फ़ाइल सिस्टम चेकर) जैसे उपकरण द्वारा।<ref name="ostep-1" /> यह आम तौर पर पढ़ने-लिखने की पहुंच के लिए फ़ाइल सिस्टम को अगली बार माउंट करने से पहले किया जाना चाहिए। यदि फ़ाइल सिस्टम बड़ा है और यदि अपेक्षाकृत कम I/O बैंडविड्थ है, तो इसमें लंबा समय लग सकता है और इसके परिणामस्वरूप लंबे समय तक डाउनटाइम हो सकता है यदि यह शेष सिस्टम को ऑनलाइन वापस आने से रोकता है। | ||
इसे रोकने के लिए, | इसे रोकने के लिए, जर्नल फ़ाइल सिस्टम विशेष क्षेत्र - जर्नल - आवंटित करता है जिसमें वह समय से पहले किए जाने वाले परिवर्तनों को रिकॉर्ड करता है। किसी दुर्घटना के बाद, पुनर्प्राप्ति में फ़ाइल सिस्टम से जर्नल को पढ़ना और इस जर्नल से परिवर्तनों को तब तक दोहराना शामिल होता है जब तक कि फ़ाइल सिस्टम फिर से सुसंगत न हो जाए। इस प्रकार परिवर्तनों को [[परमाणुता (डेटाबेस सिस्टम)]] (विभाज्य नहीं) कहा जाता है, जिसमें वे या तो सफल होते हैं (मूल रूप से सफल होते हैं या पुनर्प्राप्ति के दौरान पूरी तरह से दोहराए जाते हैं), या बिल्कुल भी दोबारा नहीं दोहराए जाते हैं (छोड़ दिए जाते हैं क्योंकि वे अभी तक पूरी तरह से लिखे नहीं गए थे) दुर्घटना घटित होने से पहले का जर्नल)। | ||
== तकनीक == | == तकनीक == | ||
कुछ फ़ाइल सिस्टम जर्नल को | कुछ फ़ाइल सिस्टम जर्नल को नियमित फ़ाइल के रूप में बढ़ने, सिकुड़ने और पुन: आवंटित करने की अनुमति देते हैं, जबकि अन्य जर्नल को सन्निहित क्षेत्र या छिपी हुई फ़ाइल में रखते हैं जो गारंटी देता है कि फ़ाइल सिस्टम माउंट होने पर वह हिलेगा या आकार नहीं बदलेगा। कुछ फ़ाइल सिस्टम बाहरी जर्नल को अलग डिवाइस पर भी अनुमति दे सकते हैं, जैसे [[ ठोस राज्य ड्राइव |ठोस राज्य ड्राइव]] या बैटरी-समर्थित गैर-वाष्पशील रैम। जर्नल में परिवर्तन को अतिरिक्त अतिरेक के लिए स्वयं जर्नल किया जा सकता है, या डिवाइस की विफलता से बचाने के लिए जर्नल को कई भौतिक संस्करणों में वितरित किया जा सकता है। | ||
जब जर्नल स्वयं लिखा जा रहा हो तो जर्नल के आंतरिक प्रारूप को क्रैश होने से बचाना चाहिए। कई जर्नल | जब जर्नल स्वयं लिखा जा रहा हो तो जर्नल के आंतरिक प्रारूप को क्रैश होने से बचाना चाहिए। कई जर्नल इम्प्लीमेंटेशन (जैसे कि [[ext4]] में JBD2 परत) चेकसम के साथ लॉग किए गए प्रत्येक परिवर्तन को इस समझ के साथ ब्रैकेट करते हैं कि क्रैश लापता (या बेमेल) चेकसम के साथ आंशिक रूप से लिखित परिवर्तन छोड़ देगा जिसे जर्नल को दोबारा चलाने पर आसानी से अनदेखा किया जा सकता है। अगला रिमाउंट. | ||
=== भौतिक पत्रिकाएँ === | === भौतिक पत्रिकाएँ === | ||
भौतिक जर्नल प्रत्येक ब्लॉक की अग्रिम प्रतिलिपि लॉग करता है जिसे बाद में मुख्य फ़ाइल सिस्टम में लिखा जाएगा। यदि मुख्य फ़ाइल सिस्टम को लिखते समय कोई दुर्घटना होती है, तो फ़ाइल सिस्टम को अगली बार माउंट करने पर लेखन को पूरा करने के लिए फिर से चलाया जा सकता है। यदि जर्नल में लेखन लॉग करते समय कोई दुर्घटना होती है, तो आंशिक लेखन में लापता या बेमेल चेकसम होगा और अगले माउंट पर इसे अनदेखा किया जा सकता है। | |||
भौतिक पत्रिकाएँ | भौतिक पत्रिकाएँ महत्वपूर्ण प्रदर्शन जुर्माना लगाती हैं क्योंकि प्रत्येक परिवर्तित ब्लॉक को दो बार भंडारण के लिए प्रतिबद्ध किया जाना चाहिए, लेकिन पूर्ण दोष संरक्षण की आवश्यकता होने पर स्वीकार्य हो सकता है।<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> लॉजिकल जर्नल वाला फ़ाइल सिस्टम क्रैश होने के बाद भी जल्दी ठीक हो जाता है, लेकिन अनजर्नल फ़ाइल डेटा और जर्नल मेटाडेटा को -दूसरे के साथ समन्वयित होने की अनुमति दे सकता है, जिससे डेटा भ्रष्टाचार हो सकता है। | |||
उदाहरण के लिए, किसी फ़ाइल में जोड़ने पर तीन अलग-अलग लेखन शामिल हो सकते हैं: | उदाहरण के लिए, किसी फ़ाइल में जोड़ने पर तीन अलग-अलग लेखन शामिल हो सकते हैं: | ||
| Line 63: | Line 65: | ||
=== [[नरम अद्यतन]] === | === [[नरम अद्यतन]] === | ||
कुछ [[ यूनिक्स फ़ाइल सिस्टम ]] | कुछ [[ यूनिक्स फ़ाइल सिस्टम |यूनिक्स फ़ाइल सिस्टम]] इम्प्लीमेंटेशन जर्नलिंग से बचते हैं और इसके बजाय सॉफ्ट अपडेट लागू करते हैं: वे अपने राइट्स को इस तरह से ऑर्डर करते हैं कि ऑन-डिस्क फाइल सिस्टम कभी भी असंगत नहीं होता है, या क्रैश की स्थिति में बनाई जा सकने वाली मात्र असंगतता स्टोरेज है रिसना। इन लीक से उबरने के लिए, मुक्त स्थान मानचित्र को अगले माउंट पर फ़ाइल सिस्टम के पूर्ण चलने के विरुद्ध समेटा जाता है। यह [[कचरा संग्रहण (कंप्यूटर विज्ञान)]] सामान्तयः पृष्ठभूमि में किया जाता है।<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> | ||
| Line 77: | Line 79: | ||
* [[डेटाबेस]] | * [[डेटाबेस]] | ||
* [[आशय लॉग]] | * [[आशय लॉग]] | ||
* जेएफएस (फाइल सिस्टम)|जर्नल फाइल सिस्टम (जेएफएस){{snd}} आईबीएम द्वारा बनाया गया | * जेएफएस (फाइल सिस्टम)|जर्नल फाइल सिस्टम (जेएफएस){{snd}} आईबीएम द्वारा बनाया गया फाइल सिस्टम | ||
* [[लेनदेन प्रक्रिया]] | * [[लेनदेन प्रक्रिया]] | ||
* फ़ाइल सिस्टम का संस्करणीकरण | * फ़ाइल सिस्टम का संस्करणीकरण | ||
Revision as of 01:04, 23 November 2023
जर्नलिंग फाइल सिस्टम ऐसा फ़ाइल सिस्टम है जो जर्नल (कंप्यूटिंग) नामक डेटा स्ट्रक्चर में ऐसे चेंजेज़ के गोल को रिकॉर्ड करके फ़ाइल सिस्टम के मुख्य भाग में अभी तक प्रतिबद्ध नहीं किए गए चेंजेज़ का ट्रैक रखता है, जो सामान्तयः सर्कुलर लॉग होता है। सिस्टम क्रैश या पावर फेल्यर की स्थिति में, ऐसे फ़ाइल सिस्टम को डेटा कर्रप्ट होने की कम संभावना के साथ अधिक तीव्रता से पुनः ऑनलाइन लाया जा सकता है।[1][2]
वास्तविक इम्प्लीमेंटेशन के आधार पर, जर्नलिंग फ़ाइल सिस्टम केवल स्टोर्ड मेटा डेटा का ट्रैक रख सकता है, जिसके परिणामस्वरूप डेटा कर्रप्शन की बढ़ती संभावना के व्यय पर परफॉरमेंस में उन्नति होती है। वैकल्पिक रूप से, जर्नलिंग फ़ाइल सिस्टम स्टोर्ड डेटा और संबंधित मेटाडेटा दोनों को ट्रैक कर सकता है, जबकि कुछ इम्प्लीमेंटेशन इस संबंध में सेलेक्टेबल बिहेवियर की अनुमति देते हैं।[3]
इतिहास
1990 में IBM ने AIX 3.1 में JFS (फ़ाइल सिस्टम) को पहले UNIX वाणिज्यिक फ़ाइल सिस्टम में से के रूप में पेश किया, जिसने जर्नलिंग लागू की।[4] अगले वर्ष इस विचार को लॉग-संरचित फ़ाइल सिस्टम पर व्यापक रूप से उद्धृत पेपर में लोकप्रिय बनाया गया।[5] इसके बाद इसे 1993 में माइक्रोसॉफ्ट के विंडोज़ एनटी के एनटीएफएस फाइल सिस्टम में, 1998 में एप्पल के एचएफएस प्लस फाइल सिस्टम में और 2001 में लिनक्स के ext3 फाइल सिस्टम में लागू किया गया।[6]
तर्कसंगत
फ़ाइलों और निर्देशिकाओं में परिवर्तनों को प्रतिबिंबित करने के लिए फ़ाइल सिस्टम को अपडेट करने के लिए सामान्तयः कई अलग-अलग लेखन कार्यों की आवश्यकता होती है। यह डेटा स्ट्रक्चरओं को अमान्य मध्यवर्ती स्थिति में छोड़ने के लिए लिखने के बीच रुकावट (जैसे बिजली विफलता या सिस्टम क्रैश (कंप्यूटिंग)) को संभव बनाता है।[1]
उदाहरण के लिए, यूनिक्स फ़ाइल सिस्टम पर किसी फ़ाइल को हटाने में तीन चरण शामिल होते हैं:[7]
- इसकी निर्देशिका प्रविष्टि को हटाया जा रहा है.
- मुक्त इनोड के पूल में इनोड जारी करना।
- सभी डिस्क ब्लॉक को मुक्त डिस्क ब्लॉक के पूल में लौटाना।
यदि चरण 1 के बाद और चरण 2 से पहले कोई दुर्घटना होती है, तो अनाथ इनोड होगा और इसलिए भंडारण रिसाव होगा; यदि चरण 2 और 3 के बीच कोई क्रैश होता है, तो फ़ाइल द्वारा पहले उपयोग किए गए ब्लॉक का उपयोग नई फ़ाइलों के लिए नहीं किया जा सकता है, जिससे फ़ाइल सिस्टम की भंडारण क्षमता प्रभावी रूप से कम हो जाती है। चरणों को पुनः व्यवस्थित करने से भी मदद नहीं मिलती है। यदि चरण 3 चरण 1 से पहले होता है, तो उनके बीच दुर्घटना फ़ाइल के ब्लॉक को नई फ़ाइल के लिए पुन: उपयोग करने की अनुमति दे सकती है, जिसका अर्थ है कि आंशिक रूप से हटाई गई फ़ाइल में किसी अन्य फ़ाइल की सामग्री का हिस्सा होगा, और किसी भी फ़ाइल में संशोधन दोनों में दिखाई देगा। दूसरी ओर, यदि चरण 2, चरण 1 से पहले होता है, तो उनके बीच दुर्घटना के कारण फ़ाइल अस्तित्व में प्रतीत होने के बावजूद अप्राप्य हो जाएगी।
ऐसी विसंगतियों का पता लगाने और उनसे उबरने के लिए आम तौर पर ग्राफ सिद्धांत की शर्तों की पूरी शब्दावली की आवश्यकता होती है#इसके डेटा स्ट्रक्चरओं का चलना, उदाहरण के लिए fsck (फ़ाइल सिस्टम चेकर) जैसे उपकरण द्वारा।[2] यह आम तौर पर पढ़ने-लिखने की पहुंच के लिए फ़ाइल सिस्टम को अगली बार माउंट करने से पहले किया जाना चाहिए। यदि फ़ाइल सिस्टम बड़ा है और यदि अपेक्षाकृत कम I/O बैंडविड्थ है, तो इसमें लंबा समय लग सकता है और इसके परिणामस्वरूप लंबे समय तक डाउनटाइम हो सकता है यदि यह शेष सिस्टम को ऑनलाइन वापस आने से रोकता है।
इसे रोकने के लिए, जर्नल फ़ाइल सिस्टम विशेष क्षेत्र - जर्नल - आवंटित करता है जिसमें वह समय से पहले किए जाने वाले परिवर्तनों को रिकॉर्ड करता है। किसी दुर्घटना के बाद, पुनर्प्राप्ति में फ़ाइल सिस्टम से जर्नल को पढ़ना और इस जर्नल से परिवर्तनों को तब तक दोहराना शामिल होता है जब तक कि फ़ाइल सिस्टम फिर से सुसंगत न हो जाए। इस प्रकार परिवर्तनों को परमाणुता (डेटाबेस सिस्टम) (विभाज्य नहीं) कहा जाता है, जिसमें वे या तो सफल होते हैं (मूल रूप से सफल होते हैं या पुनर्प्राप्ति के दौरान पूरी तरह से दोहराए जाते हैं), या बिल्कुल भी दोबारा नहीं दोहराए जाते हैं (छोड़ दिए जाते हैं क्योंकि वे अभी तक पूरी तरह से लिखे नहीं गए थे) दुर्घटना घटित होने से पहले का जर्नल)।
तकनीक
कुछ फ़ाइल सिस्टम जर्नल को नियमित फ़ाइल के रूप में बढ़ने, सिकुड़ने और पुन: आवंटित करने की अनुमति देते हैं, जबकि अन्य जर्नल को सन्निहित क्षेत्र या छिपी हुई फ़ाइल में रखते हैं जो गारंटी देता है कि फ़ाइल सिस्टम माउंट होने पर वह हिलेगा या आकार नहीं बदलेगा। कुछ फ़ाइल सिस्टम बाहरी जर्नल को अलग डिवाइस पर भी अनुमति दे सकते हैं, जैसे ठोस राज्य ड्राइव या बैटरी-समर्थित गैर-वाष्पशील रैम। जर्नल में परिवर्तन को अतिरिक्त अतिरेक के लिए स्वयं जर्नल किया जा सकता है, या डिवाइस की विफलता से बचाने के लिए जर्नल को कई भौतिक संस्करणों में वितरित किया जा सकता है।
जब जर्नल स्वयं लिखा जा रहा हो तो जर्नल के आंतरिक प्रारूप को क्रैश होने से बचाना चाहिए। कई जर्नल इम्प्लीमेंटेशन (जैसे कि ext4 में JBD2 परत) चेकसम के साथ लॉग किए गए प्रत्येक परिवर्तन को इस समझ के साथ ब्रैकेट करते हैं कि क्रैश लापता (या बेमेल) चेकसम के साथ आंशिक रूप से लिखित परिवर्तन छोड़ देगा जिसे जर्नल को दोबारा चलाने पर आसानी से अनदेखा किया जा सकता है। अगला रिमाउंट.
भौतिक पत्रिकाएँ
भौतिक जर्नल प्रत्येक ब्लॉक की अग्रिम प्रतिलिपि लॉग करता है जिसे बाद में मुख्य फ़ाइल सिस्टम में लिखा जाएगा। यदि मुख्य फ़ाइल सिस्टम को लिखते समय कोई दुर्घटना होती है, तो फ़ाइल सिस्टम को अगली बार माउंट करने पर लेखन को पूरा करने के लिए फिर से चलाया जा सकता है। यदि जर्नल में लेखन लॉग करते समय कोई दुर्घटना होती है, तो आंशिक लेखन में लापता या बेमेल चेकसम होगा और अगले माउंट पर इसे अनदेखा किया जा सकता है।
भौतिक पत्रिकाएँ महत्वपूर्ण प्रदर्शन जुर्माना लगाती हैं क्योंकि प्रत्येक परिवर्तित ब्लॉक को दो बार भंडारण के लिए प्रतिबद्ध किया जाना चाहिए, लेकिन पूर्ण दोष संरक्षण की आवश्यकता होने पर स्वीकार्य हो सकता है।[8]
तार्किक जर्नल
तार्किक जर्नल जर्नल में फ़ाइल मेटाडेटा में केवल परिवर्तनों को स्टोर्ड करता है, और काफी बेहतर लेखन प्रदर्शन के लिए दोष सहनशीलता का व्यापार करता है।[9] लॉजिकल जर्नल वाला फ़ाइल सिस्टम क्रैश होने के बाद भी जल्दी ठीक हो जाता है, लेकिन अनजर्नल फ़ाइल डेटा और जर्नल मेटाडेटा को -दूसरे के साथ समन्वयित होने की अनुमति दे सकता है, जिससे डेटा भ्रष्टाचार हो सकता है।
उदाहरण के लिए, किसी फ़ाइल में जोड़ने पर तीन अलग-अलग लेखन शामिल हो सकते हैं:
- फ़ाइल का इनोड, फ़ाइल के मेटाडेटा में नोट करने के लिए कि इसका आकार बढ़ गया है।
- मुक्त स्थान मानचित्र, जोड़े जाने वाले डेटा के लिए स्थान के आवंटन को चिह्नित करने के लिए।
- नया आवंटित स्थान, वास्तव में संलग्न डेटा लिखने के लिए।
केवल-मेटाडेटा जर्नल में, चरण 3 लॉग नहीं किया जाएगा। यदि चरण 3 पूरा नहीं किया गया था, लेकिन पुनर्प्राप्ति के दौरान चरण 1 और 2 को दोबारा चलाया जाता है, तो फ़ाइल को कचरे के साथ जोड़ दिया जाएगा।
खतरे लिखें
अधिकांश ऑपरेटिंग सिस्टम में राइट कैश थ्रूपुट को अधिकतम करने के लिए अपने राइट्स को सॉर्ट करता है (एलिवेटर एल्गोरिदम या कुछ समान योजना का उपयोग करके)। मेटाडेटा-केवल जर्नल के साथ आउट-ऑफ़-ऑर्डर लेखन के खतरे से बचने के लिए, फ़ाइल डेटा के लिए लेखन को क्रमबद्ध किया जाना चाहिए ताकि वे अपने संबंधित मेटाडेटा से पहले भंडारण के लिए प्रतिबद्ध हों। इसे लागू करना मुश्किल हो सकता है क्योंकि इसमें फ़ाइल सिस्टम ड्राइवर और राइट कैश के बीच ऑपरेटिंग सिस्टम कर्नेल के भीतर समन्वय की आवश्यकता होती है। आउट-ऑफ़-ऑर्डर लिखने का ख़तरा तब भी उत्पन्न हो सकता है जब कोई डिवाइस अपने अंतर्निहित स्टोरेज में तुरंत ब्लॉक नहीं लिख सकता है, यानी, विलंबित लेखन सक्षम होने के कारण यह अपने राइट-कैश को डिस्क पर फ्लश नहीं कर सकता है।
मामले को जटिल बनाने के लिए, कई बड़े भंडारण उपकरणों के पास अपने स्वयं के लेखन कैश होते हैं, जिसमें वे बेहतर प्रदर्शन के लिए आक्रामक रूप से लेखन को पुन: व्यवस्थित कर सकते हैं। (यह विशेष रूप से चुंबकीय हार्ड ड्राइव पर आम है, जिसमें बड़ी खोज विलंबता होती है जिसे एलेवेटर सॉर्टिंग के साथ कम किया जा सकता है।) कुछ जर्नलिंग फ़ाइल सिस्टम रूढ़िवादी रूप से मानते हैं कि ऐसी राइट-रीऑर्डरिंग हमेशा होती है, और डिवाइस को फ्लश करने के लिए मजबूर करके शुद्धता के लिए प्रदर्शन का त्याग करते हैं। जर्नल में कुछ बिंदुओं पर कैश (ext3 और ext4 में बाधाएं कहा जाता है)।[10]
विकल्प
नरम अद्यतन
कुछ यूनिक्स फ़ाइल सिस्टम इम्प्लीमेंटेशन जर्नलिंग से बचते हैं और इसके बजाय सॉफ्ट अपडेट लागू करते हैं: वे अपने राइट्स को इस तरह से ऑर्डर करते हैं कि ऑन-डिस्क फाइल सिस्टम कभी भी असंगत नहीं होता है, या क्रैश की स्थिति में बनाई जा सकने वाली मात्र असंगतता स्टोरेज है रिसना। इन लीक से उबरने के लिए, मुक्त स्थान मानचित्र को अगले माउंट पर फ़ाइल सिस्टम के पूर्ण चलने के विरुद्ध समेटा जाता है। यह कचरा संग्रहण (कंप्यूटर विज्ञान) सामान्तयः पृष्ठभूमि में किया जाता है।[11]
लॉग-संरचित फ़ाइल सिस्टम
लॉग-संरचित फ़ाइल सिस्टम में, राइट-ट्वाइस पेनल्टी लागू नहीं होती है क्योंकि जर्नल स्वयं फ़ाइल सिस्टम है: यह संपूर्ण स्टोरेज डिवाइस पर कब्जा कर लेता है और इसे संरचित किया जाता है ताकि इसे सामान्य फ़ाइल सिस्टम की तरह ट्रैवर्स किया जा सके।
लिखने पर नकल फ़ाइल सिस्टम
पूर्ण कॉपी-ऑन-राइट फ़ाइल सिस्टम (जैसे कि ZFS और Btrfs) नए आवंटित ब्लॉकों में डेटा लिखकर फ़ाइल डेटा में होने वाले परिवर्तनों से बचते हैं, इसके बाद अद्यतन मेटाडेटा होता है जो नए डेटा को इंगित करेगा और पुराने को अस्वीकार कर देगा, इसके बाद मेटाडेटा द्वारा उस ओर इशारा करते हुए, और इसी तरह सुपरब्लॉक, या फ़ाइल सिस्टम पदानुक्रम की जड़ तक। इसमें जर्नल के समान शुद्धता-संरक्षण गुण हैं, बिना दो बार लिखने के।
यह भी देखें
- एसिड
- फ़ाइल सिस्टम की तुलना
- डेटाबेस
- आशय लॉग
- जेएफएस (फाइल सिस्टम)|जर्नल फाइल सिस्टम (जेएफएस) – आईबीएम द्वारा बनाया गया फाइल सिस्टम
- लेनदेन प्रक्रिया
- फ़ाइल सिस्टम का संस्करणीकरण
संदर्भ
- ↑ 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.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
- ↑ "tune2fs(8) – Linux man page". linux.die.net. Archived from the original on February 25, 2015. Retrieved February 20, 2015.
- ↑ 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
- ↑ Rosembaum, Mendel; Ousterhout, John (February 1991). लॉग-स्ट्रक्चर फ़ाइल सिस्टम का डिज़ाइन और कार्यान्वयन (PDF). ACM 13th Annual Symposium on Operating Systems Principles.
- ↑ "'2.4.15-final' - MARC". marc.info. Retrieved March 24, 2018.
- ↑ File Systems from Tanenbaum, A.S. (2008). Modern operating systems (3rd ed., pp. 287). Upper Saddle River, NJ: Prentice Hall.
- ↑ Tweedie, Stephen (2000), "Ext3, journaling filesystem", Proceedings of the Ottawa Linux Symposium: 24–29
- ↑ 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.
- ↑ Corbet, Jonathan (May 21, 2008), Barriers and journaling filesystems, archived from the original on March 14, 2010, retrieved March 6, 2010
- ↑ 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.
