बीटीआरएफएस

From Vigyanwiki

बीटीआरएफएस (उत्तम एफ एस के रूप में उच्चारण किया जाता है,[1] बटर एफ एस,[2][3] बी-ट्री एफ एस ,[3] या बस इसे वर्तनी द्वारा) कंप्यूटर स्टोरेज प्रारूप है जो फाइल प्रणाली को कॉपी-ऑन-राइट (सीओडब्ल्यू) सिद्धांत के आधार पर जोड़ता है लॉजिकल वॉल्यूम मैनेजर (लिनक्स के एलवीएम के साथ भ्रमित नहीं होना) के साथ मिलकर विकसित किया गया। इसकी स्थापना 2007 में लिनक्स में उपयोग के लिए क्रिस मेसन द्वारा की गई थी, और नवंबर 2013 से, फ़ाइल प्रणाली के ऑन-डिस्क प्रारूप को लिनक्स कर्नेल में स्थिर घोषित किया गया है।[4]

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

इतिहास

बीटीआरएफएस फ़ाइल प्रणाली के उपयोग की सूचना का स्क्रीनशॉट

बीटीआरएफएस की मुख्य डेटा संरचना‍—‌कॉपी-ऑन-राइट बी-ट्री ‍—‌मूल रूप से आईबीएम के शोधकर्ता ओहद रोदेह द्वारा यूसेनिक्स 2007 में प्रस्तुति में प्रस्तावित किया गया था।[6] उस समय एसयूएसई के लिए रीज़रएफएस पर कार्य कर रहे अभियंता क्रिस मेसन, उस वर्ष के अंत में ओरेकल में सम्मिलित हो गए और इन बी-ट्रीज़ पर आधारित नई फाइल प्रणाली पर कार्य करना प्रारंभ किया।[7]

2008 में, ext3 और ext4 फ़ाइल प्रणाली के प्रमुख विकासकर्ता थिओडोर त्सो ने कहा कि चूँकि ext4 में उन्नत विशेषताएं हैं, यह कोई बड़ी प्रगति नहीं है; यह प्राचीन प्रौद्योगिकी का उपयोग करता है और स्टॉप-गैप है। त्सो ने कहा कि बीटीआरएफएस उत्तम दिशा है क्योंकि यह मापनीयता, विश्वसनीयता और प्रबंधन सरलता में सुधार प्रदान करता है।[8] बीटीआरएफएस के निकट रीज़र3/4 के समान कई डिज़ाइन विचार" भी हैं।[9]

बीटीआरएफएस 1.0, अंतिम ऑन-डिस्क प्रारूप के साथ, मूल रूप से 2008 के अंत में प्रसारण के लिए निर्धारित किया गया था,[10] और अंततः 2009 में लिनक्स कर्नेल मेनलाइन में स्वीकार किया गया था।[11] कई लिनक्स वितरणों ने बीटीआरएफएस को संस्थापन के समय रूट फाइल प्रणाली के प्रायोगिक विकल्प के रूप में बीटीआरएफएस को प्रस्तुत करना प्रारंभ किया गया।[12][13][14]

जुलाई 2011 में, बीटीआरएफएस स्वचालित डीफ़्रेग्मेंटेशन और स्क्रबिंग सुविधाओं को लिनक्स कर्नेल मेनलाइन के संस्करण 3.0 में मिला दिया गया था।[15] ओरेकल में मेसन के अतिरिक्त, फुजित्सु में मियाओ शी ने प्रदर्शन सुधार में योगदान दिया।[16] जून 2012 में, क्रिस मेसन ने फ्यूजन-आईओ के लिए ओरेकल को त्याग दिया, जिसे उन्होंने एक वर्ष पश्चात जोसेफ बेसिक के साथ फेसबुक में सम्मिलित होने के लिए त्याग दिया। दोनों कंपनियों में रहते हुए, मेसन ने बीटीआरएफएस पर अपना कार्य निरंतर रखा।[17][7]

2012 में, दो लिनक्स वितरणों ने बीटीआरएफएस को प्रायोगिक से उत्पादन या समर्थित स्थिति में स्थानांतरित कर दिया: मार्च में ओरेकल लिनक्स,[18] इसके पश्चात अगस्त में एसयूएसई लिनक्स एंटरप्राइज आया।[19]

2015 में, बीटीआरएफएस को एसयूएसई लिनक्स एंटरप्राइज सर्वर (एसएलई) 12 के लिए डिफ़ॉल्ट फ़ाइल प्रणाली के रूप में अपनाया गया था।[20]

अगस्त 2017 में, रेड हैट ने रेड हैट एंटरप्राइज लिनक्स (आरएचईएल) 7.4 के प्रस्तावित नोट्स में घोषणा की कि वह अब बीटीआरएफएस को पूर्ण रूप से समर्थित सुविधा में स्थानांतरित करने की योजना नहीं बना रहा है (इसे आरएचईएल 6 बीटा के पश्चात से प्रौद्योगिकी पूर्वावलोकन के रूप में सम्मिलित किया गया है) यह देखते हुए कि यह होगा आरएचईएल 7 प्रस्तावित श्रृंखला में उपलब्ध रहेगा।[21] बीटीआरएफएस को मई 2019 में आरएचईएल 8 से विस्थापित कर दिया गया था।[22] आरएचईएल, आरएचईएल 6 में ext4 से आरएचईएल 7 में एक्सएफएस में चला गया।[23]

2020 में, बीटीआरएफएस को डेस्कटॉप वेरिएंट के लिए फेडोरा लिनक्स 33 के लिए डिफ़ॉल्ट फ़ाइल प्रणाली के रूप में चयनित किया गया था।[24]

विशेषताएं

सुविधाओं की सूची

कार्यान्वित

लिनक्स कर्नेल के संस्करण 5.0 के अनुसार, बीटीआरएफएस निम्नलिखित विशेषताओं को प्रारम्भ करता है:[25][26]

  • कॉपी-ऑन-राइट की प्रकृति के कारण कुछ विन्यासों में अधिकतर स्व-उपचार होता है।
  • ऑनलाइन डीफ़्रेग्मेंटेशन और ऑटोडिफ़्रेग माउंट विकल्प है।[15]
  • ऑनलाइन मात्रा में वृद्धि और सिकुड़न होता है।
  • ऑनलाइन ब्लॉक डिवाइस को जोड़ना और विस्थापित करना।
  • ऑनलाइन संतुलन (लोड को संतुलित करने के लिए ब्लॉक उपकरणों के मध्य वस्तुओं की आवागमन)
  • ऑफलाइन फ़ाइल प्रणाली का परीक्षण करें।[27]
  • त्रुटियों का शोध करने और अनावश्यक प्रतियों वाली फ़ाइलों के लिए उन्हें स्वचालित रूप से ठीक करने के लिए ऑनलाइन डेटा स्क्रबिंग
  • आरएआईडी 0, आरएआईडी 1 और आरएआईडी 10[28]
  • सबवॉल्यूम्स (प्रत्येक डिस्क विभाजन के अंदर या अधिक अलग से माउंट करने योग्य रूट निर्देशिका)
  • जेडलिब, एलजेडओ[29] और (4.14 से) जेडएसटीडी के माध्यम से पारदर्शी संपीड़न,[30] फ़ाइल या मात्रा के अनुसार विन्यास करने योग्य[31][32]
  • परमाणु लिखने योग्य (कॉपी-ऑन-राइट के माध्यम से) या केवल पढ़ने के लिए[33] उपखंडों का स्नैपशॉट (कंप्यूटर भंडारण)।
  • फाइल क्लोनिंग (रीफ्लिंक, कॉपी-ऑन-राइट) cp --reflink <source file> <destination file> के जरिए[34]
  • डेटा और मेटाडेटा पर चेकसम (CRC-32C[35]). 5.5 से नए हैश फ़ंक्शन प्रारम्भ किए गए हैं:[36] xxHash, SHA256, ब्लेक (हैश फंक्शन)।
  • ext3/4 से बीटीआरएफएस (रोलबैक के साथ) में इन-प्लेस रूपांतरण। यह सुविधा btrfs-progs संस्करण 4.0 के निकट वापस आ गई, 4.6 में खरोंच से फिर से लिखी गई।[37]
  • रीड-ओनली स्टोरेज की यूनियन माउंटिंग,जिसे फाइल प्रणाली सीडिंग के रूप में जाना जाता है (रीड-ओनली स्टोरेज को लिखने योग्य बीटीआरएफएस के लिए कॉपी-ऑन-राइट बैकिंग के रूप में उपयोग किया जाता है)[38]
  • ब्लॉक डिस्कार्ड (कुछ वर्चुअलाइजेशन सेटअप पर स्थान को पुनः प्राप्त करता है और ट्रिम के साथ एसएसडी के स्तर में सुधार करता है)
  • भेजें/प्राप्त करें (बाइनरी स्ट्रीम में स्नैपशॉट के मध्य अंतर सहेजना)[39]
  • इंक्रीमेंटल बैकअप[40]
  • आउट-ऑफ-बैंड डेटा डुप्लिकेशन (यूजरस्पेस टूल्स की आवश्यकता है)[41]
  • स्वैप फ़ाइलोंऔर स्वैप विभाजन को संभालने की क्षमता है।

प्रारम्भ किया गया किन्तु उत्पादन के उपयोग के लिए अनुशंसित नहीं

नियोजित किन्तु अभी तक प्रारम्भ नहीं

  • इन-बैंड डेटा डुप्लिकेशन[25]
  • ऑनलाइन फ़ाइल प्रणाली का परीक्षण करें।[46]
  • आरएआईडी 5 और आरएआईडी 6 की विश्वसनीयता को पार करते हुए छह समता उपकरणों के साथ आरएआईडी[47]
  • ऑब्जेक्ट-स्तर आरएआईडी 0, आरएआईडी 1, और आरएआईडी 10
  • एन्क्रिप्शन[1][48][49]
  • निरंतर पढ़ने और लिखने का कैश (L2ARC + ZIL, dm-cache, आदि)

2009 में, बीटीआरएफएस से सन माइक्रोसिस्टम्स द्वारा विकसित ओरेकल जेडएफएस के तुलनीय फीचर सेट को प्रस्तुत करने की अपेक्षा थी।[50] 2009 में ओरेकल द्वारा सन के अधिग्रहण के पश्चात, मेसन और ओरेकलने बीटीआरएफएस के विकास को निरंतर रखने का निर्णय लिया।[51]

क्लोनिंग

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

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

क्लोनिंग को हार्ड लिंक के साथ भ्रमित नहीं होना चाहिए, जो निर्देशिका प्रविष्टियाँ हैं जो एक ही फ़ाइल के साथ कई फ़ाइल नामों को जोड़ती हैं। जबकि फ़ाइल के लिए हार्ड लिंक को भिन्न-भिन्न नामों से लिया जा सकता है, बीटीआरएफएस में क्लोनिंग स्वतंत्र फ़ाइलें प्रदान करती है जो प्रारंभ में अपने सभी डिस्क ब्लॉक साझा करती हैं।[55][56]

इस बीटीआरएफएस विशेषता के लिए समर्थन को लिए विकल्प cp कमांड के --reflink विकल्प के माध्यम से जीएनयू कोरुटिल्स के संस्करण 7.5 में जोड़ा गया था।[57][58]

डेटा क्लोनिंग (FICLONE) के अतिरिक्त, बीटीआरएफएस FIDEDUPERANGE के माध्यम से आउट-ऑफ़-बैंड डुप्लीकेशन का भी समर्थन करता है। यह कार्यक्षमता दो फ़ाइलों को (आंशिक रूप से भी) समान डेटा के साथ भंडारण साझा करने की अनुमति देती है।[59][41]

सबवॉल्यूम और स्नैपशॉट

स्नैपर के साथ प्रबंधित बीटीआरएफएस फ़ाइल प्रणाली के स्नैपशॉट का उदाहरण

बीटीआरएफएस सबवोल्यूम को भिन्न POSIX फाइल नाम स्थान के रूप में माना जा सकता है, जो mount(8) यूटिलिटी के लिए subvol या subvolid विकल्पों को निकट करके अलग से माउंट करने योग्य है। इसे शीर्ष-स्तरीय सबवोल्यूम को माउंट करके भी एक्सेस किया जा सकता है, जिस स्थिति में सबवॉल्यूम इसके उपनिर्देशिकाओं के रूप में दिखाई देते हैं और पहुंच योग्य होते हैं।[60]

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

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

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

बीटीआरएफएस की कॉपी-ऑन-राइट (सीओडब्ल्यू) प्रकृति का तात्पर्य है कि स्नैपशॉट शीघ्र बन जाते हैं, जबकि प्रारंभ में अधिक अल्प डिस्क स्थान लेते हैं। चूंकि स्नैपशॉट सबवोल्यूम है, नेस्टेड स्नैपशॉट बनाना भी संभव है। सबवोल्यूम का स्नैपशॉट लेना पुनरावर्ती प्रक्रिया नहीं है; इस प्रकार, यदि सबवोल्यूम का स्नैपशॉट बनाया जाता है, तो प्रत्येक सबवॉल्यूम या स्नैपशॉट जिसमें सबवोल्यूम पूर्व से ही सम्मिलित है, स्नैपशॉट के अंदर उसी नाम की रिक्त निर्देशिका में मैप किया जाता है।[60][61]

किसी निर्देशिका का स्नैपशॉट लेना संभव नहीं है, क्योंकि केवल उपखंडों में स्नैपशॉट हो सकते हैं। चूंकि, समाधान है जिसमें उपखंडों में फैले रिलिंक्स सम्मिलित हैं: नया सबवॉल्यूम बनाया गया है, जिसमें लक्षित निर्देशिका की सामग्री के लिए क्रॉस-सबवॉल्यूम रीलिंक्स सम्मिलित हैं। उपलब्ध होने के पश्चात, इस नए वॉल्यूम का स्नैपशॉट बनाया जा सकता है।[53]

बीटीआरएफएस में सबवॉल्यूम पारंपरिक लॉजिकल वॉल्यूम मैनेजर (एलवीएम) लॉजिकल वॉल्यूम से अधिक भिन्न है। एलवीएम के साथ, लॉजिकल वॉल्यूम भिन्न ब्लॉक डिवाइस है, जबकि बीटीआरएफएस सबवोल्यूम नहीं है और इसे इस प्रकार से ट्रीट या उपयोग नहीं किया जा सकता है।[60] बीटीआरएफएस के डीडी (dd) या एलवीएम स्नैपशॉट बनाने से डेटा हानि होती है यदि या तो मूल या प्रतिलिपि माउंट की जाती है जबकि दोनों ही कंप्यूटर पर हैं।[62]

सेंड-रिसीव

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

फ़ाइल प्रणाली प्रतिकृति (कंप्यूटिंग) के सरल रूप को प्रारम्भ करने के लिए या वृद्धिशील बैकअप करने के उद्देश्य से नियमित रूप से शेड्यूल किए गए स्नैपशॉट के साथ भेजें/प्राप्त करें सुविधा का उपयोग किया जा सकता है।[39][63]

कोटा समूह

बीटीआरएफएस कोटा समूहों का उदाहरण

कोटा समूह (या क्यूग्रुप) स्थान के लिए ऊपरी सीमा लगाता है जो सबवोल्यूम या स्नैपशॉट उपभोग कर सकता है। नया स्नैपशॉट प्रारंभ में कोई कोटा नहीं लेता है क्योंकि इसका डेटा उसके माता-पिता के साथ साझा किया जाता है, किन्तु उसके पश्चात नई फ़ाइलों और उपस्थित फ़ाइलों पर कॉपी-ऑन-राइट संचालन के लिए शुल्क लगता है। जब कोटा सक्रिय होता है, प्रत्येक नए सबवॉल्यूम या स्नैपशॉट के साथ कोटा समूह स्वचालित रूप से बनाया जाता है। ये प्रारंभिक कोटा समूह बिल्डिंग ब्लॉक्स हैं जिन्हें कोटा पूल को प्रारम्भ करने के लिए पदानुक्रम में समूहीकृत किया जा सकता है ( btrfs qgroup कमांड)।[42]

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

ext2/3/4 और रीज़रएफएस से इन-प्लेस रूपांतरण

निश्चित स्थानों में अधिक अल्प मेटाडेटा के लंगर डाले जाने के परिणामस्वरूप, बीटीआरएफएस बैकएंड भंडारण उपकरणों के असामान्य स्थानिक लेआउट को फिट करने के लिए ताना मार सकता है। btrfs-convert e> टूल ext2/3/4 या रीज़रएफएस फ़ाइल प्रणाली का इन-प्लेस रूपांतरण करने की इस क्षमता का लाभ उठाता है, मूल फ़ाइल प्रणाली की असंशोधित प्रति को संरक्षित करते हुए - इसके असंबद्ध स्थान में समकक्ष बीटीआरएफएस मेटाडेटा को नेस्ट करके उपयोग किया जाता है।[64]

रूपांतरण में संपूर्ण ext2/3/4 मेटाडेटा की प्रतिलिपि बनाना सम्मिलित है, जबकि बीटीआरएफएस फ़ाइलें केवल उन्हीं ब्लॉकों की ओर संकेत करती हैं जिनका उपयोग ext2/3/4 फ़ाइलों द्वारा किया जाता है। यह रूपांतरण के स्थायी होने से पूर्व दो फ़ाइल प्रणाली के मध्य साझा किए गए अधिकांश ब्लॉक बनाता है। बीटीआरएफएस की कॉपी-ऑन-राइट प्रकृति के लिए धन्यवाद, फ़ाइल डेटा ब्लॉक के मूल संस्करण सभी फ़ाइल संशोधनों के समय संरक्षित हैं। जब तक रूपांतरण स्थायी नहीं हो जाता, तब तक केवल वे ब्लॉक जो ext2/3/4 में मुक्त के रूप में चिह्नित किए गए थे, नए बीटीआरएफएस संशोधनों को रखने के लिए उपयोग किए जाते हैं, जिसका अर्थ है कि रूपांतरण को किसी भी समय पूर्ववत किया जा सकता है (चूँकि ऐसा करने से रूपांतरण के पश्चात किए गए सभी परिवर्तन मिट जाएंगे बीटीआरएफएस के लिए)।[64]

सभी रूपांतरित फ़ाइलें उपलब्ध हैं और बीटीआरएफएस के डिफ़ॉल्ट सबवोल्यूम में लिखने योग्य हैं। मूल ext2/3/4 फाइलप्रणाली के सभी संदर्भों को धारण करने वाली विरल फाइल को भिन्न सबवोल्यूम में बनाया जाता है, जो रीड-ओनली डिस्क इमेज के रूप में अपने आप माउंट करने योग्य होती है, जिससे मूल और परिवर्तित फाइल प्रणाली दोनों को उसी समय एक्सेस किया जा सकता है। इस विरल फ़ाइल को विस्थापित करने से स्थान रिक्त हो जाता है और रूपांतरण स्थायी हो जाता है।[64]

मेनलाइन लिनक्स कर्नेल के 4.x संस्करणों में, इन-प्लेस ext3/4 रूपांतरण को अपरीक्षित और संभवतः कभी उपयोग किया गया माना जाता था।[64] चूँकि, फीचर को 2016 में स्क्रैच से पुनः लिखा गया था btrfs-progs 4.6.[37] और तब से स्थिर माना जाता है।

रीज़रएफएस से इन-प्लेस रूपांतरण सितंबर 2017 में कर्नेल 4.13 के साथ प्रस्तुत किया गया था।[65]

यूनियन माउंटिंग / सीड डिवाइस

नया बीटीआरएफएस बनाते समय, उपस्थित बीटीआरएफएस को रीड-ओनली सीड फाइल प्रणाली के रूप में उपयोग किया जा सकता है।[66] नयी फाइल प्रणाली तब बीज पर कॉपी-ऑन-राइट ओवरले के रूप में कार्य करेगा, यूनियन माउंटिंग के रूप में कार्य करेगा। बीज को अंत में बीटीआरएफएस से भिन्न किया जा सकता है, जिस बिंदु पर रिबैलेंसर भिन्न होने से पूर्व नयी फाइल प्रणाली द्वारा अभी भी संदर्भित किसी भी बीज डेटा की नकल करेगा। मेसन ने सुझाव दिया है कि यह लाइव सीडी इंस्टॉलर के लिए उपयोगी हो सकता है, जो ऑप्टिकल डिस्क पर केवल-पढ़ने के लिए बीटीआरएफएस बीज से बूट हो सकता है, पृष्ठभूमि में इंस्टाल डिस्क पर लक्ष्य विभाजन के लिए स्वयं को पुन: संतुलित करता है जबकि उपयोगकर्ता कार्य करना निरंतर रखता है, फिर डिस्क को रिबूट किए बिना स्थापना को पूर्ण करने के लिए बाहर निकाल देता है।[67]

एन्क्रिप्शन

2009 के अपने साक्षात्कार में, क्रिस मेसन ने कहा कि बीटीआरएफएस के लिए एन्क्रिप्शन के लिए समर्थन की योजना बनाई गई थी।[68] इस मध्य, बीटीआरएफएस के साथ एन्क्रिप्शन के संयोजन के लिए समाधान अंतर्निहित उपकरणों पर dm-crypt / LUKS जैसे पूर्ण-डिस्क एन्क्रिप्शन तंत्र का उपयोग करना और उस परत के शीर्ष पर बीटीआरएफएस फ़ाइल प्रणाली बनाना है।

As of 2020, विकासकर्ता एचएमएसी (HMAC) (SHA256) जैसे प्रमुख हैश को जोड़ने के लिए कार्य कर रहे थे।[69]

परीक्षण और रिकवरी

यूनिक्स प्रणाली परंपरागत रूप से फाइल प्रणाली के परीक्षण और त्रुटिनिवारण के लिए fsck प्रोग्राम पर विश्वास करते हैं। यह कार्यक्षमता btrfs check प्रोग्राम के माध्यम से कार्यान्वित की जाती है। संस्करण 4.0 के पश्चात से यह कार्यक्षमता अपेक्षाकृत स्थिर मानी जाती है। चूँकि, दिसंबर 2022 तक, बीटीआरएफएस प्रलेखन से ज्ञात होता है कि इसके --repair विकल्प का उपयोग केवल तभी किया जा सकता है जब आपको किसी डेवलपर या अनुभवी उपयोगकर्ता द्वारा सम्मति दी गई हो।[70] अगस्त 2022 तक, एसएलई प्रलेखन लाइव सीडी का उपयोग करने, बैकअप करने और केवल अंतिम उपाय के रूप में त्रुटिनिवारण विकल्प का उपयोग करने की अनुशंसा करता है।[71]

अन्य उपकरण है, जिसका नाम btrfs-restore है, जिसका उपयोग खंडित फ़ाइल प्रणाली को संशोधित किए बिना (अर्थात , गैर-विनाशकारी रूप से) अनमाउंटेबल फ़ाइल प्रणाली से फ़ाइलों को पुनर्प्राप्त करने के लिए किया जा सकता है।[72][73]

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

डिजाइन

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

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

बीटीआरएफएस को ऐसे ट्री की कई परतों के रूप में संरचित किया जाता है, सभी बी-ट्री कार्यान्वयन का उपयोग करते हैं। ट्री 136-बिट कुंजी द्वारा क्रमबद्ध सामान्य वस्तुओं को संग्रहीत करता है। कुंजी के सबसे महत्वपूर्ण 64 बिट अद्वितीय ऑब्जेक्ट आईडी हैं। मध्य आठ बिट्स आइटम प्रकार फ़ील्ड हैं: इसका उपयोग ट्री लुकअप में आइटम फ़िल्टर के रूप में कोड में हार्डवायर किया गया है। ऑब्जेक्ट्स में विभिन्न प्रकार के अनेक आइटम हो सकते हैं। शेष (अल्प से अल्प महत्वपूर्ण) 64 बिट प्रकार-विशिष्ट विधियों से उपयोग किए जाते हैं। इसलिए, एक ही वस्तु के लिए आइटम प्रकार के आधार पर समूहीकृत ट्री में दूसरे के निकट समाप्त होते हैं। कुछ प्रमुख मूल्यों का चयन करके, वस्तुएं उसी प्रकार की वस्तुओं को विशेष क्रम में आगे रख सकती हैं।[50][77]

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

फाइल प्रणाली ट्री

प्रत्येक निर्देशिका के अंदर, निर्देशिका प्रविष्टियाँ निर्देशिका आइटम के रूप में दिखाई देती हैं, जिनके अल्प से अल्प महत्वपूर्ण बिट्स उनके फ़ाइल नाम का सीआरसी32सी हैश हैं। उनका डेटा स्थान कुंजी है, या उस इनोड आइटम की कुंजी है जो इसे प्रदर्शित करता है। निर्देशिका आइटम एक साथ पथ-से-इनोड लुकअप के लिए सूचकांक के रूप में कार्य कर सकते हैं, किन्तु पुनरावृत्ति के लिए उपयोग नहीं किया जाता है क्योंकि वे उनके हैश द्वारा क्रमबद्ध होते हैं, उन्हें प्रभावी रूप से यादृच्छिक रूप से अनुमति देते हैं। इसका तात्पर्य यह है कि बड़ी निर्देशिका में फ़ाइलों को खोलने और खोलने वाले उपयोगकर्ता अनुप्रयोग इस प्रकार गैर-निकटवर्ती फ़ाइलों के मध्य कई और डिस्क शोध उत्पन्न करेंगे - अन्य फ़ाइल प्रणाली में उल्लेखनीय प्रदर्शन ड्रेन हैश-ऑर्डर वाली निर्देशिकाओं जैसे रीज़रएफएस ,[78] ext3 (Htree-indexes सक्षम के साथ[79]) और ext4, जिनमें से सभी में टिनी एन्क्रिप्शन एल्गोरिथम-हैश फ़ाइल नाम हैं। इससे बचने के लिए, प्रत्येक निर्देशिका प्रविष्टि में निर्देशिका अनुक्रमणिका आइटम होता है, जिसका आइटम का मुख्य मूल्य प्रति-निर्देशिका काउंटर पर सेट होता है जो प्रत्येक नई निर्देशिका प्रविष्टि के साथ बढ़ता है। इन अनुक्रमणिका मदों पर पुनरावृत्ति इस प्रकार प्रविष्टियों को सामान्यतः उसी क्रम में लौटाती है जैसा कि डिस्क पर संग्रहीत है।

एकाधिक निर्देशिकाओं में हार्ड लिंक वाली फ़ाइलों में प्रत्येक मूल निर्देशिका के लिए एकाधिक संदर्भ आइटम होते हैं। एक ही निर्देशिका में कई हार्ड लिंक वाली फ़ाइलें सभी लिंक के फ़ाइलनामों को ही संदर्भ आइटम में पैक करती हैं। यह डिज़ाइन दोष था जिसने समान-निर्देशिका हार्ड लिंक की संख्या को सीमित कर दिया था, चूँकि कई ट्री ब्लॉक में फिट हो सकते थे। (4 KiB के डिफॉल्ट ब्लॉक आकार, 8 बाइट्स की औसत फ़ाइल नाम लंबाई और 4 बाइट्स के प्रति-फ़ाइल नाम हेडर पर, यह 350 से अल्प होगा।) कई समान-निर्देशिका हार्ड लिंक जैसे कि Git (सॉफ़्टवेयर), Gnus, जीमैम (GMame) और बैकअपपीसी (BackupPC) का भारी उपयोग करने वाले एप्लिकेशन इस सीमा पर विफल होते देखे गए।[80] सीमा को अंततः विस्थापित कर दिया गया था[81] (और अक्टूबर 2012 तक विलय कर दिया गया है[82] लिनक्स 3.7 में लंबित प्रस्तावित) हार्ड लिंक फ़ाइलनामों को रखने के लिए स्पिलओवर विस्तारित संदर्भ आइटम प्रस्तुत करके जो अन्यथा फिट नहीं होते हैं।

विस्तार

फ़ाइल डेटा को ट्री के बाहर विस्तार में रखा जाता है, जो डिस्क डेटा ब्लॉक के सन्निहित रन हैं। सीमा ब्लॉक डिफ़ॉल्ट रूप से 4 KiB के आकार का होता है, इसमें हेडर नहीं होते हैं और इसमें केवल (संभावित रूप से संपीड़ित) फ़ाइल डेटा होता है। संकुचित विस्तार में, भिन्न-भिन्न ब्लॉक भिन्न-भिन्न संपीड़ित नहीं होते हैं; जबकि, कम्प्रेशन स्ट्रीम पूर्ण सीमा तक विस्तारित है।

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

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

विस्तार आवंटन ट्री

सीमा आवंटन ट्री फाइल प्रणाली के लिए आवंटन मानचित्र के रूप में कार्य करता है। अन्य ट्री के विपरीत, इस ट्री की वस्तुओं में ऑब्जेक्ट आईडी नहीं होते हैं। वे अंतरिक्ष के क्षेत्रों का प्रतिनिधित्व करते हैं: उनके प्रमुख मूल्यों में प्रारंभिक ऑफसेट और उनके द्वारा प्रतिनिधित्व किए जाने वाले क्षेत्रों की लंबाई होती है।

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

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

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

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

चेकसम ट्री और स्क्रबिंग

सीआरसी-32सी चेकसम की गणना डेटा और मेटाडेटा दोनों के लिए की जाती है और चेकसम ट्री में चेकसम आइटम के रूप में संग्रहीत की जाती है। मेटाडेटा चेकसम के 256 बिट्स और डेटा चेकसम के लिए पूर्ण नोड तक (लगभग 4 KB या अधिक) तक का स्थान है। बीटीआरएफएस में फाइल प्रणाली के भविष्य के संस्करणों में जोड़े जाने वाले अतिरिक्त चेकसम एल्गोरिदम के प्रावधान हैं।[25][84]

आवंटित ब्लॉकों के प्रति सन्निहित रन में चेकसम आइटम है, जिसमें आइटम डेटा में एंड-टू-एंड पैक किए गए प्रति-ब्लॉक चेकसम हैं। यदि फिट होने से अधिक चेकसम हैं, तो वे नए पत्ते में दूसरे चेकसम आइटम में विस्तारित हो जाते हैं। यदि फ़ाइल प्रणाली किसी ब्लॉक को पढ़ते समय चेकसम असमान को ज्ञात करता है, तो वह पूर्व इस ब्लॉक की अच्छी प्रति किसी अन्य डिवाइस से प्राप्त करने (या बनाने) का प्रयास करता है। – यदि आंतरिक मिररिंग या आरएआईडी प्रौद्योगिकी उपयोग में हैं।[85][86]

बीटीआरएफएस फ़ाइल प्रणाली स्क्रब कार्य को ट्रिगर करके पूर्ण फ़ाइल प्रणाली का ऑनलाइन परीक्षण प्रारंभ कर सकता है जो बैकग्राउंड में किया जाता है। स्क्रब कार्य पूर्ण फाइल प्रणाली को अखंडता के लिए स्कैन करता है और स्वचालित रूप से रास्ते में मिलने वाले किसी भी दुर्गत ब्लॉक की रिपोर्ट करने और त्रुटिनिवारण करने का प्रयास करता है।[85][87]

लॉग ट्री

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

चंक और डिवाइस ट्री

ब्लॉक उपकरणों को डेटा के लिए 1 GiB और मेटाडेटा के लिए 256 MiB के भौतिक भागों में विभाजित किया गया है।[88] कई उपकरणों में भौतिक भाग को तार्किक खंड में एक साथ प्रतिबिंबित या धारीदार किया जा सकता है। इन लॉजिकल चंक्स को सिंगल लॉजिकल एड्रेस स्पेस में संयोजित किया जाता है, जिसका उपयोग शेष फाइलप्रणाली करती है।

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

सिंगल
1 तार्किक से 1 भौतिक चंक
dup
1 ब्लॉक डिवाइस पर 1 तार्किक चंक से 2 भौतिक चंक
Raid0
N≥2 ब्लॉक डिवाइसेस में N≥2 भौतिक चंक्स के लिए N तार्किक चंक्स
Raid1
N≥2 ब्लॉक उपकरणों में से 2 में 1 तार्किक चंक से 2 भौतिक चंक्स,[89] पारंपरिक आरएआईडी 1 के विपरीत जिसमें N भौतिक चंक्स है।
Raid1c3
N≥3 ब्लॉक डिवाइस में से 1 तार्किक चंक से 3 भौतिक चंक
Raid1c4
N≥4 ब्लॉक डिवाइस में से 1 तार्किक चंक से 4 भौतिक चंक
Raid5
N (N≥2 के लिए) N+1 ब्लॉक उपकरणों में N+1 भौतिक भाग के लिए तार्किक भाग, 1 भौतिक खंड के साथ समता के रूप में उपयोग किया जाता है।
Raid6
N (N≥2 के लिए) N+2 ब्लॉक उपकरणों में N+2 भौतिक चंक्स के लिए तार्किक चंक्स, जिसमें 2 भौतिक चंक्स पैरिटी के रूप में उपयोग किए जाते हैं।

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

रीलोकेशन ट्री

डीफ़्रैग्मेन्टेशन, सिकुडऩ, और पुनर्संतुलन संचालन के लिए विस्तार को स्थानांतरित करने की आवश्यकता होती है। चूँकि, रिलोकेटिंग सीमा की साधारण कॉपी-ऑन-राइट करने से स्नैपशॉट के मध्य साझाकरण विभक्त हो जाएगा और डिस्क स्थान का उपभोग होगा। साझाकरण को संरक्षित करने के लिए, अपडेट-एंड-स्वैप एल्गोरिथम का उपयोग किया जाता है, जिसमें विशेष रीलोकेशन ट्री प्रभावित मेटाडेटा के लिए स्क्रैच स्पेस के रूप में कार्य करता है। स्थानांतरित की जाने वाली सीमा को प्रथम उसके गंतव्य पर कॉपी किया जाता है। फिर, प्रभावित सबवोल्यूम के फाइल प्रणाली ट्री के माध्यम से ऊपर की ओर बैकरेफरेंस का अनुसरण करके, प्राचीन विस्तार की ओर संकेत करते हुए मेटाडेटा को नए बिंदु पर प्रदर्शित करने के लिए उत्तरोत्तर अद्यतन किया जाता है; किसी भी नए अपडेट किए गए आइटम को रीलोकेशन ट्री में स्टोर किया जाता है। एक बार अपडेट पूर्ण हो जाने के पश्चात, रिलोकेशन ट्री में आइटम्स को प्रभावित सबवोल्यूम में उनके समकक्षों के साथ स्वैप किया जाता है, और रिलोकेशन ट्री को विस्थापित कर दिया जाता है।[90]

सुपरब्लॉक

सभी फाइल प्रणाली के ट्री-चंक ट्री सहित-चंक्स में संग्रहीत होते हैं, जिससे फाइल प्रणाली को बढ़ते समय संभावित बूटस्ट्रैपिंग समस्या उत्पन्न होती है। माउंट में बूटस्ट्रैप करने के लिए, चंक और रूट ट्री से संबंधित चंक्स के भौतिक पतों की सूची संग्रहीत की जाती है।[91]

सुपरब्लॉक मिरर को निश्चित स्थानों पर रखा जाता है:[92] प्रत्येक ब्लॉक डिवाइस में 64 KiB, 64 MiB, 256 GiB और 1 PiB पर अतिरिक्त प्रतियों के साथ होता है। जब सुपरब्लॉक मिरर को अपडेट किया जाता है, तो इसकी जनरेशन संख्या बढ़ जाती है। आरोह समय पर, उच्चतम पीढ़ी संख्या वाली प्रतिलिपि का उपयोग किया जाता है। एसएसडी मोड को त्यागकर सभी सुपरब्लॉक मिरर को अग्रानुक्रम में अपडेट किया जाता है, जो कुछ वियर लेवलिंग प्रदान करने के लिए मिरर के मध्य अपडेट को वैकल्पिक करता है।

वाणिज्यिक समर्थन

समर्थित

  • ओरेकल लिनक्स संस्करण 7 से[93][94]
  • संस्करण 12 से एसयूएसई लिनक्स एंटरप्राइज़ सर्वर[95][96]
  • सिनोलॉजी डिस्कस्टेशन मैनेजर (डीएसएम) संस्करण 6.0 से[97]

अब समर्थित नहीं

  • बीटीआरएफएस को रेड हैट एंटरप्राइज लिनक्स 6 और 7 में "प्रौद्योगिकी पूर्वावलोकन" के रूप में सम्मिलित किया गया था;[12][21] इसे 2018 में आरएचईएल (RHEL) 8 में विस्थापित कर दिया गया था।[22][98][99]
  • 2013 के निकट नेटगियर रेडीएनएएस आर्म-आधारित 1xx और इंटेल-आधारित 3xx में एमडीएडीएम-आरएआईडी सरणियों पर बीटीआरएफएस को स्तरित किया गया था (संभवतः अभी भी अस्थिर बीटीआरएफएस-आरएआईडी कार्यात्मकताओं से बचने के लिए बीटीआरएफएस चेकसम और स्नैपशॉट का लाभ उठाने के लिए)। डेबियन जेसी आधारित ओएस6 के अपडेट अभी भी 2022 के निकट प्रस्तुत किए गए थे (संभवतः अभी भी समर्थित माना जाता है?)।

यह भी देखें

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

टिप्पणियाँ

Cite error: <ref> tag with name "kernel-limits" defined in <references> has group attribute "lower-alpha" which does not appear in prior text.

Cite error: <ref> tag with name "maximum-files" defined in <references> has group attribute "lower-alpha" which does not appear in prior text.

संदर्भ

  1. 1.0 1.1 1.2 McPherson, Amanda (22 June 2009). "A Conversation with Chris Mason on BTRfs: the next generation file system for Linux". Linux Foundation. Archived from the original on 27 June 2012. Retrieved 2009-09-01.
  2. "संग्रहीत प्रति". Event occurs at 1m 15s. Archived from the original on 18 August 2016. Retrieved 6 February 2016.
  3. 3.0 3.1 Henson, Valerie (31 January 2008). Chunkfs: Fast file system check and repair. Melbourne, Australia. Event occurs at 18m 49s. Retrieved 2008-02-05. इसे बटर एफएस या बी-ट्री एफएस कहा जाता है, लेकिन सभी अच्छे बच्चे बटर एफएस कहते हैं
  4. "Linux kernel commit changing stability status in fs/btrfs/Kconfig". Retrieved 2019-02-08.
  5. Kerner, Sean Michael (30 October 2008). "A Better File System for Linux?". InternetNews.com. Archived from the original on 8 April 2011. Retrieved 27 August 2020.
  6. 6.0 6.1 Rodeh, Ohad (2007). B-trees, shadowing, and clones (PDF). USENIX Linux Storage & Filesystem Workshop. Also Rodeh, Ohad (2008). "B-trees, shadowing, and clones". ACM Transactions on Storage. 3 (4): 1–27. doi:10.1145/1326542.1326544. S2CID 207166167.
  7. 7.0 7.1 "Lead Btrfs File-System Developers Join Facebook". phoronix.com. Retrieved 19 April 2015.
  8. Paul, Ryan (13 April 2009). "लिनक्स सहयोग शिखर सम्मेलन में पैनलिस्ट कर्नेल पर विचार करते हैं". Ars Technica. Archived from the original on 17 June 2012. Retrieved 2009-08-22. {{cite journal}}: Cite journal requires |journal= (help)
  9. Ts'o, Theodore (1 August 2008). "Re: reiser4 for 2.6.27-rc1". linux-kernel (Mailing list). Retrieved 2010-12-31.
  10. "विकास समयरेखा". Btrfs wiki. 11 December 2008. Archived from the original on 20 December 2008. Retrieved 5 November 2011.
  11. Wuelfing, Britta (12 January 2009). "Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem". Linux Magazine. Retrieved 5 November 2011.
  12. 12.0 12.1 "Red Hat Enterprise Linux 6 documentation: Technology Previews". Archived from the original on 28 May 2011. Retrieved 21 January 2011.
  13. "Fedora Weekly News Issue 276". 25 May 2011.
  14. "Debian 6.0 "Squeeze" released" (Press release). Debian. 6 February 2011. Retrieved 2011-02-08. Support has also been added for the ext4 and Btrfs filesystems...
  15. 15.0 15.1 "Linux kernel 3.0, Section 1.1. Btrfs: Automatic defragmentation, scrubbing, performance improvements". kernelnewbies.org. 2011-07-21. Retrieved 2016-04-05.
  16. Leemhuis, Thorsten (21 June 2011). "Kernel Log: Coming in 3.0 (Part 2) - Filesystems". The H Open. Retrieved 8 November 2011.
  17. Varghese, Sam. "iTwire". ITWire.com. Retrieved 19 April 2015.
  18. "Unbreakable Enterprise Kernel Release 2 has been released". Retrieved 2019-05-08.
  19. "SLES 11 SP2 Release Notes". 21 August 2012. Retrieved 2012-08-29.
  20. "SUSE Linux Enterprise Server 12 Release Notes". 2015-11-05. Retrieved 2016-01-20.
  21. 21.0 21.1 "Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality". 2017-08-01. Archived from the original on 8 August 2017. Retrieved 2017-08-15.
  22. 22.0 22.1 "Considerations in adopting RHEL 8". Product Documentation for Red Hat Enterprise Linux 8. Red Hat. Retrieved 2019-05-09.
  23. "How to Choose Your Red Hat Enterprise Linux File System". Retrieved 2022-01-03.
  24. "Btrfs Coming to Fedora 33". Fedora Magazine. 2020-08-24. Retrieved 2020-08-25.
  25. 25.0 25.1 25.2 "Btrfs Wiki: Features". btrfs.wiki.kernel.org. 2013-11-27. Retrieved 2013-11-27.
  26. "Btrfs Wiki: Changelog". btrfs.wiki.kernel.org. 2019-05-29. Retrieved 2013-11-27.
  27. "Manpage btrfs-check".
  28. "Using Btrfs with Multiple Devices". kernel.org. 2013-11-07. Retrieved 2013-11-20.
  29. Cite error: Invalid <ref> tag; no text was provided for refs named btrfs Wiki
  30. Cite error: Invalid <ref> tag; no text was provided for refs named kernelnewbies.org
  31. "Compression". kernel.org. 2013-06-25. Retrieved 2014-04-01.
  32. "Btrfs: add support for inode properties". kernel.org. 2014-01-28. Retrieved 2014-04-01.
  33. "btrfs: Readonly snapshots". Retrieved 2011-12-12.
  34. "Save disk space on Linux by cloning files on Btrfs and OCFS2". Retrieved 2017-08-01.
  35. "Wiki FAQ: What checksum function does Btrfs use?". Btrfs wiki. Retrieved 2009-06-15.
  36. "Btrfs hilights in 5.5: new hashes". Retrieved 2020-08-29.
  37. 37.0 37.1 "Btrfs progs release 4.6". Retrieved 2017-08-01.
  38. Mason, Chris (12 January 2009). "Btrfs चेंजलॉग". Archived from the original on 29 February 2012. Retrieved 2012-02-12.
  39. 39.0 39.1 39.2 Corbet, Jonathan (2012-07-11), Btrfs send/receive, LWN.net, retrieved 2012-11-14
  40. "Btrfs Wiki: Incremental Backup". 2013-05-27. Retrieved 2013-11-27.
  41. 41.0 41.1 Cite error: Invalid <ref> tag; no text was provided for refs named dedup
  42. 42.0 42.1 Jansen, Arne (2011), Btrfs Subvolume Quota Groups (PDF), Strato AG, retrieved 2012-11-14
  43. btrfs (2016-07-16). "RAID 5/6". kernel.org. Retrieved 2016-10-01.
  44. Zygo Blaxell. "How to use btrfs raid5 successfully(ish)". lore.kernel.org. Retrieved 2022-06-26.
  45. Zygo Blaxell. "Current bugs with operational impact on btrfs raid5". lore.kernel.org. Retrieved 2022-06-26.
  46. Corbet, Jonathan (2 November 2011). "A btrfs update at LinuxCon Europe". Retrieved 12 February 2012.
  47. Mazzoleni, Andrea. "btrfs: lib: raid: New RAID library supporting up to six parities". Retrieved 2014-03-16.
  48. "Btrfs Project ideas". 21 February 2013. Retrieved 21 February 2013.
  49. Dorminy, Sweet Tea (13 July 2022). "btrfs: add fscrypt integration". Retrieved 2022-08-01.
  50. 50.0 50.1 50.2 50.3 Aurora, Valerie (22 July 2009). "A short history of btrfs". LWN.net. Retrieved 5 November 2011.
  51. Hilzinger, Marcel (22 April 2009). "Btrfs का भविष्य सुरक्षित". Linux Magazine. Retrieved 5 November 2011.
  52. Corbet, Jonathan (2009-05-05). "The two sides of reflink()". LWN.net. Retrieved 2013-10-17.
  53. 53.0 53.1 "UseCases – btrfs documentation". kernel.org. Retrieved 2013-11-04.
  54. "btrfs: allow cross-subvolume file clone". github.com. Retrieved 2013-11-04.
  55. "Symlinks reference names, hardlinks reference meta-data and reflinks reference data". pixelbeat.org. 2010-10-27. Retrieved 2013-10-17.
  56. Meyering, Jim (20 August 2009). "GNU coreutils NEWS: Noteworthy changes in release 7.5". savannah.gnu.org. Retrieved 2009-08-30.
  57. Scrivano, Giuseppe (1 August 2009). "cp: accept the --reflink option". savannah.gnu.org. Retrieved 2009-11-02.
  58. ioctl_fideduperange(2) – Linux Programmer's Manual – System Calls
  59. 60.0 60.1 60.2 60.3 "SysadminGuide – Btrfs documentation". kernel.org. Retrieved 2013-10-31.
  60. 61.0 61.1 61.2 "5.6 Creating Subvolumes and Snapshots [needs update]". oracle.com. 2013. Retrieved 2013-10-31.
  61. "Gotchas - btrfs विकी". btrfs.wiki.kernel.org.
  62. 63.0 63.1 "5.7 Using the Send/Receive Feature". oracle.com. 2013. Retrieved 2013-10-31.
  63. 64.0 64.1 64.2 64.3 Mason, Chris (2015-06-25). "Conversion from Ext3 (Btrfs documentation)". kernel.org. Retrieved 2016-04-22.
  64. "btrfs-convert(8) — BTRFS Documentation". Retrieved 2022-10-16.
  65. "बीज यंत्र". Archived from the original on 12 June 2017. Retrieved 1 August 2017.
  66. Mason, Chris (2012-04-05), Btrfs Filesystem: Status and New Features, Linux Foundation, retrieved 2012-11-16[permanent dead link]
  67. McPherson, Amanda (2009-06-22). "A Conversation with Chris Mason on BTRfs: the next generation file system for Linux". Linux Foundation. Archived from the original on 27 June 2012. Retrieved 2014-10-09. भविष्य के रिलीज में हम ऑनलाइन fsck, डुप्लीकेशन, एन्क्रिप्शन और अन्य सुविधाओं को जोड़ने की योजना बना रहे हैं जो लंबे समय से व्यवस्थापक इच्छा सूची में हैं।
  68. Sterba, David. "authenticated file systems using HMAC(SHA256)". Lore.Kernel.org. Retrieved 25 April 2020.
  69. "btrfs-check(8)". btrfs.readthedocs.io.
  70. "How to recover from BTRFS errors | Support | SUSE". www.suse.com. Retrieved 2023-01-28.
  71. "पुनर्स्थापित करें - btrfs विकी". btrfs.wiki.kernel.org.
  72. "btrfs-restore(8) - Linux manual page". man7.org. Retrieved 2023-01-28.
  73. "समस्या अक्सर पूछे जाने वाले प्रश्न - btrfs विकी". kernel.org. 2013-07-31. Retrieved 2014-01-16.
  74. "kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree)". kernel.org. 2013-11-21. Retrieved 2014-02-06.
  75. "Mount options - btrfs Wiki". kernel.org. 2013-11-12. Retrieved 2014-01-16.
  76. 77.0 77.1 77.2 Mason, Chris. "Btrfs design". Btrfs wiki. Retrieved 8 November 2011.
  77. Reiser, Hans (2001-12-07). "Re: Ext2 directory index: ALS paper and benchmarks". ReiserFS developers mailing list. Retrieved 2009-08-28.
  78. Mason, Chris. "एसीपी". Oracle personal web page. Retrieved 2011-11-05.
  79. Fasheh, Mark (2012-10-09). "btrfs: extended inode refs". Archived from the original on 2013-04-15. Retrieved 2012-11-07.
  80. Torvalds, Linus (2012-10-10). "क्रिस मेसन से btrfs अद्यतन प्राप्त करें". git.kernel.org. Archived from the original on 2013-04-15. Retrieved 2012-11-07.
  81. Larabel, Michael (2010-12-24). "Btrfs स्पेस कैश विकल्प के बेंचमार्क". Phoronix. Retrieved 2012-11-16.
  82. "FAQ - btrfs Wiki: What checksum function does Btrfs use?". The btrfs Project. Retrieved 2020-11-22.
  83. 85.0 85.1 Bierman, Margaret; Grimmer, Lenz (August 2012). "How I Use the Advanced Capabilities of Btrfs". Retrieved 2013-09-20.
  84. Salter, Jim (15 January 2014). "Bitrot and Atomic COWs: Inside "Next-Gen" Filesystems". Ars Technica. Retrieved 15 January 2014.
  85. Coekaerts, Wim (2011-09-28). "Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!". Retrieved 2013-09-20.
  86. "शब्दकोष". Btrfs Wiki. Retrieved 2021-07-31.
  87. "Manpage/mkfs.btrfs". Btrfs Wiki. Profiles. Retrieved 2021-07-31.
  88. Mason, Chris; Rodeh, Ohad; Bacik, Josef (2012-07-09), BTRFS: The Linux B-tree Filesystem (PDF), IBM Research, retrieved 2012-11-12
  89. Mason, Chris (30 April 2008). "मल्टीपल डिवाइस सपोर्ट". Btrfs wiki. Archived from the original on 20 July 2011. Retrieved 5 November 2011.
  90. Bartell, Sean (2010-04-20). "Re: Restoring BTRFS partition". linux-btrfs (Mailing list).
  91. "Oracle Now Supports Btrfs RAID5/6 on Their Unbreakable Enterprise Kernel - Phoronix". Phoronix.com.
  92. "Managing Btrfs in Oracle Linux 8". docs.oracle.com. Retrieved 6 June 2020.[dead link]
  93. "SUSE ने Btrfs के लिए समर्थन की फिर से पुष्टि की". LWN.net.
  94. "SUSE Linux Enterprise Server 12 Release Notes". SUSE.com. Retrieved 2021-02-28.
  95. "क्लाउड स्टेशन श्वेत पत्र" (PDF). Synology.com. Synology. p. 11. Archived from the original (PDF) on 11 November 2020. Retrieved 2021-04-02. Starting from DSM 6.0, data volumes can be formatted as Btrfs
  96. "Btrfs has been deprecated in RHEL | Hacker News". News.YCombinator.com.
  97. "ऐसा प्रतीत होता है कि Red Hat अपनी Btrfs आशाओं का परित्याग कर रहा है - Phoronix". Phoronix.com.
  98. Andreas Jaeger (2005-02-15). "Large File Support in Linux". users.suse.com. Retrieved 2015-08-12.
  99. "Linux kernel configuration help for CONFIG_LBD in 2.6.29 on x86". kernel.xc.net. Archived from the original on 6 September 2015. Retrieved 2015-08-12.
Cite error: <ref> tag with name "file-system-limits" defined in <references> is not used in prior text.


बाहरी संबंध