बीटीआरएफएस: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 60: Line 60:
}}
}}


बीटीआरएफएस (उत्तम एफ एस के रूप में उच्चारण किया जाता है,<ref name="CM090622" /> बटर एफ एस,<ref>{{Cite web |url=http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4 |title=संग्रहीत प्रति|access-date=6 February 2016 |archive-date=18 August 2016 |archive-url=https://web.archive.org/web/20160818163705/http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4 | time = 1m 15s |url-status=dead }}</ref><ref name="auto">{{cite video | first = Valerie |last=Henson | title = Chunkfs: Fast file system check and repair | date = 31 January 2008 | url = http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-262.ogg | time = 18m 49s | quote = इसे बटर एफएस या बी-ट्री एफएस कहा जाता है, लेकिन सभी अच्छे बच्चे बटर एफएस कहते हैं| location = [[Melbourne]], Australia | access-date = 2008-02-05 }}</ref> बी-ट्री एफ एस ,<ref name="auto" /> या बस इसे वर्तनी द्वारा) कंप्यूटर स्टोरेज प्रारूप है जो कॉपी-ऑन-राइट कंप्यूटर स्टोरेज में कॉपी-ऑन-राइट (COW) सिद्धांत के आधार पर [[फाइल सिस्टम]] को [[ तार्किक मात्रा प्रबंधन |तार्किक मात्रा प्रबंधन]] के साथ जोड़ता है (भ्रमित नहीं होना चाहिए) [[लिनक्स]] का [[लॉजिकल वॉल्यूम मैनेजर (लिनक्स)]]), साथ विकसित हुआ। इसे शुरू में लिनक्स में उपयोग के लिए 2007 में [[Oracle Corporation]] में डिज़ाइन किया गया था, और नवंबर 2013 से, फ़ाइल सिस्टम के ऑन-डिस्क प्रारूप को Linux कर्नेल में स्थिर घोषित किया गया है।<ref>{{cite web |title = Linux kernel commit changing stability status in fs/btrfs/Kconfig | url = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4204617d142c0887e45fda2562cb5c58097b918e | access-date = 2019-02-08 }}</ref> Btrfs का उद्देश्य Linux फ़ाइल सिस्टम में फैले [[पूल (कंप्यूटर विज्ञान)]], [[ स्नैपशॉट (कंप्यूटर भंडारण) |स्नैपशॉट (कंप्यूटर भंडारण)]] , [[ अंततः, |अंततः,]] और इंटीग्रल मल्टी-डिवाइस की कमी को दूर करना है।<ref name="CM090622" />Btrfs के प्रमुख लेखक क्रिस मेसन ने कहा कि इसका लक्ष्य उपलब्ध होने वाले स्टोरेज के लिए [लिनक्स] स्केल देना था। स्केलिंग केवल स्टोरेज को संबोधित करने के बारे में नहीं है, बल्कि इसका मतलब यह भी है कि इसे साफ इंटरफ़ेस के साथ प्रशासित और प्रबंधित करने में सक्षम होना चाहिए जो लोगों को यह देखने देता है कि क्या उपयोग किया जा रहा है और इसे और अधिक विश्वसनीय बनाता है।<ref>{{cite web |title=A Better File System for Linux? |first=Sean Michael |last=Kerner |date=30 October 2008 |access-date=27 August 2020 |website=InternetNews.com |url=http://www.internetnews.com/dev-news/article.php/3781676/A+Better+File+System+for+Linux.htm |archive-url=https://web.archive.org/web/20110408185904/http://www.internetnews.com/dev-news/article.php/3781676/A%20Better%20File%20System%20for%20Linux.htm |archive-date=8 April 2011 |url-status=live }}</ref>
बीटीआरएफएस (उत्तम एफ एस के रूप में उच्चारण किया जाता है,<ref name="CM090622" /> बटर एफ एस,<ref>{{Cite web |url=http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4 |title=संग्रहीत प्रति|access-date=6 February 2016 |archive-date=18 August 2016 |archive-url=https://web.archive.org/web/20160818163705/http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4 | time = 1m 15s |url-status=dead }}</ref><ref name="auto">{{cite video | first = Valerie |last=Henson | title = Chunkfs: Fast file system check and repair | date = 31 January 2008 | url = http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-262.ogg | time = 18m 49s | quote = इसे बटर एफएस या बी-ट्री एफएस कहा जाता है, लेकिन सभी अच्छे बच्चे बटर एफएस कहते हैं| location = [[Melbourne]], Australia | access-date = 2008-02-05 }}</ref> बी-ट्री एफ एस ,<ref name="auto" /> या बस इसे वर्तनी द्वारा) कंप्यूटर स्टोरेज प्रारूप है जो कॉपी-ऑन-राइट कंप्यूटर स्टोरेज में कॉपी-ऑन-राइट (COW) सिद्धांत के आधार पर [[फाइल सिस्टम]] को [[ तार्किक मात्रा प्रबंधन |तार्किक मात्रा प्रबंधन]] के साथ जोड़ता है (भ्रमित नहीं होना चाहिए) [[लिनक्स]] का [[लॉजिकल वॉल्यूम मैनेजर (लिनक्स)]]), साथ विकसित हुआ। इसे प्रारंभ में लिनक्स में उपयोग के लिए 2007 में [[Oracle Corporation]] में डिज़ाइन किया गया था, और नवंबर 2013 से, फ़ाइल सिस्टम के ऑन-डिस्क प्रारूप को Linux कर्नेल में स्थिर घोषित किया गया है।<ref>{{cite web |title = Linux kernel commit changing stability status in fs/btrfs/Kconfig | url = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4204617d142c0887e45fda2562cb5c58097b918e | access-date = 2019-02-08 }}</ref> Btrfs का उद्देश्य Linux फ़ाइल सिस्टम में फैले [[पूल (कंप्यूटर विज्ञान)]], [[ स्नैपशॉट (कंप्यूटर भंडारण) |स्नैपशॉट (कंप्यूटर भंडारण)]] , [[ अंततः, |अंततः,]] और इंटीग्रल मल्टी-डिवाइस की कमी को दूर करना है।<ref name="CM090622" />Btrfs के प्रमुख लेखक क्रिस मेसन ने कहा कि इसका लक्ष्य उपलब्ध होने वाले स्टोरेज के लिए [लिनक्स] स्केल देना था। स्केलिंग केवल स्टोरेज को संबोधित करने के बारे में नहीं है, जबकि इसका तात्पर्य यह भी है कि इसे साफ इंटरफ़ेस के साथ प्रशासित और प्रबंधित करने में सक्षम होना चाहिए जो लोगों को यह देखने देता है कि क्या उपयोग किया जा रहा है और इसे और अधिक विश्वसनीय बनाता है।<ref>{{cite web |title=A Better File System for Linux? |first=Sean Michael |last=Kerner |date=30 October 2008 |access-date=27 August 2020 |website=InternetNews.com |url=http://www.internetnews.com/dev-news/article.php/3781676/A+Better+File+System+for+Linux.htm |archive-url=https://web.archive.org/web/20110408185904/http://www.internetnews.com/dev-news/article.php/3781676/A%20Better%20File%20System%20for%20Linux.htm |archive-date=8 April 2011 |url-status=live }}</ref>
== इतिहास ==
== इतिहास ==
[[File:Btrfs filesystem usage screenshot.png|upright=1.5|thumb|Btrfs फ़ाइल सिस्टम के उपयोग की जानकारी का स्क्रीनशॉट]]Btrfs की मुख्य डेटा संरचना{{mdashb}}कॉपी-ऑन-राइट [[ बी-वृक्ष |बी-वृक्ष]] {{mdashb}}मूल रूप से [[IBM]] के शोधकर्ता ओहद रोदेह द्वारा [[USENIX]] 2007 में प्रस्तुति में प्रस्तावित किया गया था।<ref name="rodeh-1" />क्रिस मेसन, उस समय SUSE लाइनेक्स के लिए [[ReiserFS]] पर काम कर रहे इंजीनियर, उस वर्ष बाद में Oracle में शामिल हो गए और इन B-ट्रीज़ पर आधारित नई फाइल सिस्टम पर काम करना शुरू किया।<ref name="joinfb" />
[[File:Btrfs filesystem usage screenshot.png|upright=1.5|thumb|Btrfs फ़ाइल सिस्टम के उपयोग की जानकारी का स्क्रीनशॉट]]Btrfs की मुख्य डेटा संरचना{{mdashb}}कॉपी-ऑन-राइट [[ बी-वृक्ष |बी-वृक्ष]] {{mdashb}}मूल रूप से [[IBM]] के शोधकर्ता ओहद रोदेह द्वारा [[USENIX]] 2007 में प्रस्तुति में प्रस्तावित किया गया था।<ref name="rodeh-1" />क्रिस मेसन, उस समय SUSE लाइनेक्स के लिए [[ReiserFS]] पर काम कर रहे इंजीनियर, उस वर्ष बाद में Oracle में सम्मिलित हो गए और इन B-ट्रीज़ पर आधारित नई फाइल सिस्टम पर काम करना प्रारंभ किया।<ref name="joinfb" />


2008 में, [[ext3]] और [[ext4]] फ़ाइल सिस्टम के प्रमुख विकासकर्ता थिओडोर त्सो ने कहा कि हालांकि ext4 में उन्नत विशेषताएं हैं, यह कोई बड़ी प्रगति नहीं है; यह पुरानी तकनीक का उपयोग करता है और स्टॉप-गैप है। Ts'o ने कहा कि Btrfs बेहतर दिशा है क्योंकि यह मापनीयता, विश्वसनीयता और प्रबंधन में आसानी में सुधार प्रदान करता है।<ref>{{cite journal |url=https://arstechnica.com/open-source/news/2009/04/linux-collaboration-summit-the-kernel-panel.ars |title=लिनक्स सहयोग शिखर सम्मेलन में पैनलिस्ट कर्नेल पर विचार करते हैं|first=Ryan |last=Paul |date=13 April 2009 |access-date=2009-08-22 |publisher=Ars Technica|archive-url=https://web.archive.org/web/20120617204105/http://arstechnica.com/information-technology/2009/04/linux-collaboration-summit-the-kernel-panel/ |archive-date=17 June 2012 |url-status=dead }}</ref> Btrfs के पास भी वही डिज़ाइन विचार हैं जो ReiserFS/[[Reiser4]] के पास थे।<ref>{{cite mailing list | title = Re: reiser4 for 2.6.27-rc1 | first = Theodore |last=Ts'o | url = https://lkml.org/lkml/2008/8/1/217 | date = 1 August 2008 | access-date = 2010-12-31 | mailing-list = linux-kernel }}</ref>
2008 में, [[ext3]] और [[ext4]] फ़ाइल सिस्टम के प्रमुख विकासकर्ता थिओडोर त्सो ने कहा कि हालांकि ext4 में उन्नत विशेषताएं हैं, यह कोई बड़ी प्रगति नहीं है; यह पुरानी तकनीक का उपयोग करता है और स्टॉप-गैप है। Ts'o ने कहा कि Btrfs बेहतर दिशा है क्योंकि यह मापनीयता, विश्वसनीयता और प्रबंधन में आसानी में सुधार प्रदान करता है।<ref>{{cite journal |url=https://arstechnica.com/open-source/news/2009/04/linux-collaboration-summit-the-kernel-panel.ars |title=लिनक्स सहयोग शिखर सम्मेलन में पैनलिस्ट कर्नेल पर विचार करते हैं|first=Ryan |last=Paul |date=13 April 2009 |access-date=2009-08-22 |publisher=Ars Technica|archive-url=https://web.archive.org/web/20120617204105/http://arstechnica.com/information-technology/2009/04/linux-collaboration-summit-the-kernel-panel/ |archive-date=17 June 2012 |url-status=dead }}</ref> Btrfs के पास भी वही डिज़ाइन विचार हैं जो ReiserFS/[[Reiser4]] के पास थे।<ref>{{cite mailing list | title = Re: reiser4 for 2.6.27-rc1 | first = Theodore |last=Ts'o | url = https://lkml.org/lkml/2008/8/1/217 | date = 1 August 2008 | access-date = 2010-12-31 | mailing-list = linux-kernel }}</ref>
Btrfs 1.0, अंतिम रूप से ऑन-डिस्क प्रारूप के साथ, मूल रूप से 2008 के अंत में रिलीज़ के लिए निर्धारित किया गया था,<ref>{{cite web | url = http://btrfs.wiki.kernel.org/index.php/Development_timeline |url-status= dead | title = विकास समयरेखा| work= Btrfs wiki | date = 11 December 2008 | access-date = 5 November 2011 | archive-date= 20 December 2008 |archive-url= https://web.archive.org/web/20081220083235/http://btrfs.wiki.kernel.org/index.php/Development_timeline }}</ref> और अंततः 2009 में [[लिनक्स कर्नेल मेनलाइन]] में स्वीकार कर लिया गया।<ref>{{cite news | url = http://www.linux-magazine.com/Online/News/Kernel-2.6.29-Corbet-Says-Btrfs-Next-Generation-Filesystem | title = Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem |first= Britta |last=Wuelfing |work= [[Linux Magazine]] | date = 12 January 2009 | access-date= 5 November 2011 }}</ref> कई Linux वितरणों ने Btrfs को संस्थापन के दौरान [[रूट फाइल सिस्टम]] के प्रायोगिक विकल्प के रूप में पेश करना शुरू किया।<ref name="RHEL 6">{{cite web |title=Red Hat Enterprise Linux 6 documentation: Technology Previews |url=http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html#id4452791 |access-date=21 January 2011 |archive-url=https://web.archive.org/web/20110528160211/http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html |archive-date=28 May 2011 }}</ref><ref>{{cite web |title=Fedora Weekly News Issue 276 |url=http://fedoraproject.org/wiki/FWN/LatestIssue#What.27s_new_in_Fedora_15_.28Lovelock.29.3F |date=25 May 2011}}</ref><ref>{{cite press release | url=http://www.debian.org/News/2011/20110205a.en.html | title=Debian 6.0 "Squeeze" released | date=6 February 2011 | publisher=[[Debian]] | quote=Support has also been added for the ext4 and Btrfs filesystems... | access-date=2011-02-08 }}</ref>
Btrfs 1.0, अंतिम रूप से ऑन-डिस्क प्रारूप के साथ, मूल रूप से 2008 के अंत में रिलीज़ के लिए निर्धारित किया गया था,<ref>{{cite web | url = http://btrfs.wiki.kernel.org/index.php/Development_timeline |url-status= dead | title = विकास समयरेखा| work= Btrfs wiki | date = 11 December 2008 | access-date = 5 November 2011 | archive-date= 20 December 2008 |archive-url= https://web.archive.org/web/20081220083235/http://btrfs.wiki.kernel.org/index.php/Development_timeline }}</ref> और अंततः 2009 में [[लिनक्स कर्नेल मेनलाइन]] में स्वीकार कर लिया गया।<ref>{{cite news | url = http://www.linux-magazine.com/Online/News/Kernel-2.6.29-Corbet-Says-Btrfs-Next-Generation-Filesystem | title = Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem |first= Britta |last=Wuelfing |work= [[Linux Magazine]] | date = 12 January 2009 | access-date= 5 November 2011 }}</ref> कई Linux वितरणों ने Btrfs को संस्थापन के दौरान [[रूट फाइल सिस्टम]] के प्रायोगिक विकल्प के रूप में प्रस्तुत करना प्रारंभ किया।<ref name="RHEL 6">{{cite web |title=Red Hat Enterprise Linux 6 documentation: Technology Previews |url=http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html#id4452791 |access-date=21 January 2011 |archive-url=https://web.archive.org/web/20110528160211/http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html |archive-date=28 May 2011 }}</ref><ref>{{cite web |title=Fedora Weekly News Issue 276 |url=http://fedoraproject.org/wiki/FWN/LatestIssue#What.27s_new_in_Fedora_15_.28Lovelock.29.3F |date=25 May 2011}}</ref><ref>{{cite press release | url=http://www.debian.org/News/2011/20110205a.en.html | title=Debian 6.0 "Squeeze" released | date=6 February 2011 | publisher=[[Debian]] | quote=Support has also been added for the ext4 and Btrfs filesystems... | access-date=2011-02-08 }}</ref>
जुलाई 2011 में, Btrfs स्वचालित [[defragmentation]] और [[डेटा स्क्रबिंग]] सुविधाओं को Linux कर्नेल मेनलाइन के संस्करण 3.0 में मिला दिया गया था।<ref name="defragandscrubbing" />Oracle में मेसन के अलावा, Fujitsu में Miao Xie ने प्रदर्शन सुधार में योगदान दिया।<ref>{{cite news |title= Kernel Log: Coming in 3.0 (Part 2) - Filesystems |first=Thorsten |last=Leemhuis |work= The H Open |date= 21 June 2011 |url= http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-0-Part-2-Filesystems-1263681.html |access-date= 8 November 2011 }}</ref> जून 2012 में, क्रिस मेसन ने [[ फ्यूजन-कब |फ्यूजन-कब]] के लिए ओरेकल छोड़ दिया, जिसे उन्होंने साल बाद जोसेफ बेसिक के साथ [[फेसबुक]] में शामिल होने के लिए छोड़ दिया। दोनों कंपनियों में रहते हुए, मेसन ने Btrfs पर अपना काम जारी रखा।<ref>{{cite web |url=http://www.itwire.com/business-it-news/open-source/62417-faecbook-lures-top-btrfs-hackers|title=iTwire|first=Sam|last=Varghese|website=ITWire.com|access-date=19 April 2015 }}</ref><ref name="joinfb" />
जुलाई 2011 में, Btrfs स्वचालित [[defragmentation]] और [[डेटा स्क्रबिंग]] सुविधाओं को Linux कर्नेल मेनलाइन के संस्करण 3.0 में मिला दिया गया था।<ref name="defragandscrubbing" />Oracle में मेसन के अतिरिक्त, Fujitsu में Miao Xie ने प्रदर्शन सुधार में योगदान दिया।<ref>{{cite news |title= Kernel Log: Coming in 3.0 (Part 2) - Filesystems |first=Thorsten |last=Leemhuis |work= The H Open |date= 21 June 2011 |url= http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-0-Part-2-Filesystems-1263681.html |access-date= 8 November 2011 }}</ref> जून 2012 में, क्रिस मेसन ने [[ फ्यूजन-कब |फ्यूजन-कब]] के लिए ओरेकल छोड़ दिया, जिसे उन्होंने साल बाद जोसेफ बेसिक के साथ [[फेसबुक]] में सम्मिलित होने के लिए छोड़ दिया। दोनों कंपनियों में रहते हुए, मेसन ने Btrfs पर अपना काम जारी रखा।<ref>{{cite web |url=http://www.itwire.com/business-it-news/open-source/62417-faecbook-lures-top-btrfs-hackers|title=iTwire|first=Sam|last=Varghese|website=ITWire.com|access-date=19 April 2015 }}</ref><ref name="joinfb" />


2012 में, दो Linux वितरणों ने Btrfs को प्रयोगात्मक से उत्पादन या समर्थित स्थिति में स्थानांतरित कर दिया: मार्च में [[Oracle Linux]],<ref>{{cite web|url=https://blogs.oracle.com/linux/unbreakable-enterprise-kernel-release-2-has-been-released|title=Unbreakable Enterprise Kernel Release 2 has been released|access-date=2019-05-08}}</ref> इसके बाद अगस्त में [[एसयूएसई लिनक्स एंटरप्राइज]] आया।<ref>{{cite web|url=http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP2/#fate-306585|title=SLES 11 SP2 Release Notes|date=21 August 2012|access-date=2012-08-29}}</ref>
2012 में, दो Linux वितरणों ने Btrfs को प्रयोगात्मक से उत्पादन या समर्थित स्थिति में स्थानांतरित कर दिया: मार्च में [[Oracle Linux]],<ref>{{cite web|url=https://blogs.oracle.com/linux/unbreakable-enterprise-kernel-release-2-has-been-released|title=Unbreakable Enterprise Kernel Release 2 has been released|access-date=2019-05-08}}</ref> इसके बाद अगस्त में [[एसयूएसई लिनक्स एंटरप्राइज]] आया।<ref>{{cite web|url=http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP2/#fate-306585|title=SLES 11 SP2 Release Notes|date=21 August 2012|access-date=2012-08-29}}</ref>
2015 में, Btrfs को [[SUSE Linux Enterprise Server]] (SLE) 12 के लिए डिफ़ॉल्ट फ़ाइल सिस्टम के रूप में अपनाया गया था।<ref>{{cite web|url=https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221|title=SUSE Linux Enterprise Server 12 Release Notes|date=2015-11-05|access-date=2016-01-20}}</ref>
2015 में, Btrfs को [[SUSE Linux Enterprise Server]] (SLE) 12 के लिए डिफ़ॉल्ट फ़ाइल सिस्टम के रूप में अपनाया गया था।<ref>{{cite web|url=https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221|title=SUSE Linux Enterprise Server 12 Release Notes|date=2015-11-05|access-date=2016-01-20}}</ref>
अगस्त 2017 में, Red Hat ने [[Red Hat Enterprise Linux]] (RHEL) 7.4 के लिए रिलीज़ नोट्स में घोषणा की कि वह अब Btrfs को पूरी तरह से समर्थित सुविधा में स्थानांतरित करने की योजना नहीं बना रहा है (इसे RHEL 6 बीटा के बाद से तकनीकी पूर्वावलोकन के रूप में शामिल किया गया है) यह देखते हुए कि यह होगा RHEL 7 रिलीज़ सीरीज़ में उपलब्ध रहें।<ref name="RHEL 7">{{cite web | url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html | title=Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality | date=2017-08-01 | access-date=2017-08-15 | archive-url=https://web.archive.org/web/20170808013554/https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html|archive-date=8 August 2017|url-status=dead}}</ref> Btrfs को मई 2019 में RHEL 8 से हटा दिया गया था।<ref name="RHEL 8">{{cite web |url = https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/file-systems-and-storage_considerations-in-adopting-rhel-8#btrfs-has-been-removed_file-systems-and-storage | title = Considerations in adopting RHEL 8 |access-date = 2019-05-09 |work = Product Documentation for Red Hat Enterprise Linux 8 | publisher = [[Red Hat]]}}</ref> RHEL RHEL 6 में ext4 से RHEL 7 में [[XFS]] में चला गया।<ref>{{cite web |url=https://access.redhat.com/articles/3129891 |access-date=2022-01-03 |title= How to Choose Your Red Hat Enterprise Linux File System }}</ref>
अगस्त 2017 में, Red Hat ने [[Red Hat Enterprise Linux]] (RHEL) 7.4 के लिए रिलीज़ नोट्स में घोषणा की कि वह अब Btrfs को पूरी तरह से समर्थित सुविधा में स्थानांतरित करने की योजना नहीं बना रहा है (इसे RHEL 6 बीटा के बाद से तकनीकी पूर्वावलोकन के रूप में सम्मिलित किया गया है) यह देखते हुए कि यह होगा RHEL 7 रिलीज़ सीरीज़ में उपलब्ध रहें।<ref name="RHEL 7">{{cite web | url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html | title=Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality | date=2017-08-01 | access-date=2017-08-15 | archive-url=https://web.archive.org/web/20170808013554/https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html|archive-date=8 August 2017|url-status=dead}}</ref> Btrfs को मई 2019 में RHEL 8 से हटा दिया गया था।<ref name="RHEL 8">{{cite web |url = https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/file-systems-and-storage_considerations-in-adopting-rhel-8#btrfs-has-been-removed_file-systems-and-storage | title = Considerations in adopting RHEL 8 |access-date = 2019-05-09 |work = Product Documentation for Red Hat Enterprise Linux 8 | publisher = [[Red Hat]]}}</ref> RHEL RHEL 6 में ext4 से RHEL 7 में [[XFS]] में चला गया।<ref>{{cite web |url=https://access.redhat.com/articles/3129891 |access-date=2022-01-03 |title= How to Choose Your Red Hat Enterprise Linux File System }}</ref>
2020 में, Btrfs को डेस्कटॉप वेरिएंट के लिए [[Fedora Linux]] 33 के लिए डिफ़ॉल्ट फ़ाइल सिस्टम के रूप में चुना गया था।<ref>{{Cite web|date=2020-08-24|title=Btrfs Coming to Fedora 33|url=https://fedoramagazine.org/btrfs-coming-to-fedora-33/|access-date=2020-08-25|website=Fedora Magazine}}</ref>
2020 में, Btrfs को डेस्कटॉप वेरिएंट के लिए [[Fedora Linux]] 33 के लिए डिफ़ॉल्ट फ़ाइल सिस्टम के रूप में चुना गया था।<ref>{{Cite web|date=2020-08-24|title=Btrfs Coming to Fedora 33|url=https://fedoramagazine.org/btrfs-coming-to-fedora-33/|access-date=2020-08-25|website=Fedora Magazine}}</ref>
== विशेषताएं ==
== विशेषताएं ==
Line 81: Line 81:
* ऑनलाइन डीफ़्रेग्मेंटेशन और ऑटोडिफ़्रेग माउंट विकल्प<ref name="defragandscrubbing" />* ऑनलाइन मात्रा में वृद्धि और सिकुड़न
* ऑनलाइन डीफ़्रेग्मेंटेशन और ऑटोडिफ़्रेग माउंट विकल्प<ref name="defragandscrubbing" />* ऑनलाइन मात्रा में वृद्धि और सिकुड़न
* ऑनलाइन [[ब्लॉक डिवाइस]] को जोड़ना और हटाना
* ऑनलाइन [[ब्लॉक डिवाइस]] को जोड़ना और हटाना
* ऑनलाइन संतुलन (लोड को संतुलित करने के लिए ब्लॉक उपकरणों के बीच वस्तुओं की आवाजाही)
* ऑनलाइन संतुलन (लोड को संतुलित करने के लिए ब्लॉक उपकरणों के मध्य वस्तुओं की आवाजाही)
* ऑफलाइन एफएसके<ref>{{cite web | url=https://btrfs.readthedocs.io/en/latest/btrfs-check.html | title=Manpage btrfs-check}}</ref>
* ऑफलाइन एफएसके<ref>{{cite web | url=https://btrfs.readthedocs.io/en/latest/btrfs-check.html | title=Manpage btrfs-check}}</ref>
* त्रुटियों को खोजने और अनावश्यक प्रतियों वाली फ़ाइलों के लिए उन्हें स्वचालित रूप से ठीक करने के लिए ऑनलाइन डेटा स्क्रबिंग
* त्रुटियों को खोजने और अनावश्यक प्रतियों वाली फ़ाइलों के लिए उन्हें स्वचालित रूप से ठीक करने के लिए ऑनलाइन डेटा स्क्रबिंग
Line 108: Line 108:
* रीड-ओनली स्टोरेज की [[ संघ पर्वत |संघ पर्वत]] िंग, जिसे फाइल सिस्टम सीडिंग के रूप में जाना जाता है (रीड-ओनली स्टोरेज को लिखने योग्य Btrfs के लिए कॉपी-ऑन-राइट बैकिंग के रूप में उपयोग किया जाता है)<ref>{{cite web | title = Btrfs चेंजलॉग| first = Chris | last = Mason | date = 12 January 2009 | access-date = 2012-02-12 | url = http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support | archive-url = https://web.archive.org/web/20120229050222/http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support | archive-date = 29 February 2012 | url-status = dead }}</ref>
* रीड-ओनली स्टोरेज की [[ संघ पर्वत |संघ पर्वत]] िंग, जिसे फाइल सिस्टम सीडिंग के रूप में जाना जाता है (रीड-ओनली स्टोरेज को लिखने योग्य Btrfs के लिए कॉपी-ऑन-राइट बैकिंग के रूप में उपयोग किया जाता है)<ref>{{cite web | title = Btrfs चेंजलॉग| first = Chris | last = Mason | date = 12 January 2009 | access-date = 2012-02-12 | url = http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support | archive-url = https://web.archive.org/web/20120229050222/http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support | archive-date = 29 February 2012 | url-status = dead }}</ref>
* ब्लॉक डिस्कार्ड (कुछ [[हार्डवेयर वर्चुअलाइजेशन]] सेटअप पर स्थान को पुनः प्राप्त करता है और [[ट्रिम (कंप्यूटिंग)]] के साथ [[ ठोस राज्य ड्राइव |ठोस राज्य ड्राइव]] पर [[ समतलन पुराना होना |समतलन पुराना होना]] में सुधार करता है)
* ब्लॉक डिस्कार्ड (कुछ [[हार्डवेयर वर्चुअलाइजेशन]] सेटअप पर स्थान को पुनः प्राप्त करता है और [[ट्रिम (कंप्यूटिंग)]] के साथ [[ ठोस राज्य ड्राइव |ठोस राज्य ड्राइव]] पर [[ समतलन पुराना होना |समतलन पुराना होना]] में सुधार करता है)
* भेजें/प्राप्त करें (बाइनरी स्ट्रीम में स्नैपशॉट के बीच [[अंतर]] सहेजना)<ref name="corbet-jul2011" />* [[वृध्दिशील बैकअप]]<ref>{{cite web|title = Btrfs Wiki: Incremental Backup|date = 2013-05-27|access-date = 2013-11-27|url = https://btrfs.wiki.kernel.org/index.php/Incremental_Backup}}</ref>
* भेजें/प्राप्त करें (बाइनरी स्ट्रीम में स्नैपशॉट के मध्य [[अंतर]] सहेजना)<ref name="corbet-jul2011" />* [[वृध्दिशील बैकअप]]<ref>{{cite web|title = Btrfs Wiki: Incremental Backup|date = 2013-05-27|access-date = 2013-11-27|url = https://btrfs.wiki.kernel.org/index.php/Incremental_Backup}}</ref>
* आउट-ऑफ-बैंड [[डेटा डुप्लिकेशन]] (यूजरस्पेस टूल्स की आवश्यकता है)<ref name="dedup" />* [[ फ़ाइल की अदला - बदली करें |फ़ाइल की अदला - बदली करें]] ों और स्वैप विभाजन को संभालने की क्षमता
* आउट-ऑफ-बैंड [[डेटा डुप्लिकेशन]] (यूजरस्पेस टूल्स की आवश्यकता है)<ref name="dedup" />* [[ फ़ाइल की अदला - बदली करें |फ़ाइल की अदला - बदली करें]] ों और स्वैप विभाजन को संभालने की क्षमता


Line 132: Line 132:
* कूटलेखन<ref name="CM090622" /><ref name="project ideas" /><ref name="add-fscrypt-2022" />* लगातार पढ़ने और लिखने का कैश (ZFS#Caching Mechanism|L2ARC + ZIL, [[dm-cache]], आदि)
* कूटलेखन<ref name="CM090622" /><ref name="project ideas" /><ref name="add-fscrypt-2022" />* लगातार पढ़ने और लिखने का कैश (ZFS#Caching Mechanism|L2ARC + ZIL, [[dm-cache]], आदि)


2009 में, Btrfs से [[सन माइक्रोसिस्टम्स]] द्वारा विकसित [[Oracle ZFS]] के तुलनीय फीचर सेट की पेशकश करने की उम्मीद थी।<ref name="aurora-1" />2009 में Oracle द्वारा Sun के अधिग्रहण के बाद, मेसन और Oracle ने Btrfs के विकास को जारी रखने का निर्णय लिया।<ref>{{cite magazine |date= 22 April 2009 |first=Marcel |last=Hilzinger |title=Btrfs का भविष्य सुरक्षित|magazine=Linux Magazine |url=http://www.linux-magazine.com/Online/News/Future-of-Btrfs-Secured |access-date = 5 November 2011}}</ref>
2009 में, Btrfs से [[सन माइक्रोसिस्टम्स]] द्वारा विकसित [[Oracle ZFS]] के तुलनीय फीचर सेट की प्रस्तुतकश करने की उम्मीद थी।<ref name="aurora-1" />2009 में Oracle द्वारा Sun के अधिग्रहण के बाद, मेसन और Oracle ने Btrfs के विकास को जारी रखने का निर्णय लिया।<ref>{{cite magazine |date= 22 April 2009 |first=Marcel |last=Hilzinger |title=Btrfs का भविष्य सुरक्षित|magazine=Linux Magazine |url=http://www.linux-magazine.com/Online/News/Future-of-Btrfs-Secured |access-date = 5 November 2011}}</ref>
=== क्लोनिंग ===
=== क्लोनिंग ===
Btrfs क्लोन ऑपरेशन प्रदान करता है जो परमाणु (प्रोग्रामिंग) [[कम्प्यूटर फाइल]] का कॉपी-ऑन-राइट स्नैपशॉट बनाता है। प्रस्तावित संबद्ध लिनक्स कर्नेल [[सिस्टम कॉल]] के आलोक में, ऐसी क्लोन फ़ाइलों को कभी-कभी रिफ्लिंक्स के रूप में संदर्भित किया जाता है।<ref>{{cite web
Btrfs क्लोन ऑपरेशन प्रदान करता है जो परमाणु (प्रोग्रामिंग) [[कम्प्यूटर फाइल]] का कॉपी-ऑन-राइट स्नैपशॉट बनाता है। प्रस्तावित संबद्ध लिनक्स कर्नेल [[सिस्टम कॉल]] के आलोक में, ऐसी क्लोन फ़ाइलों को कभी-कभी रिफ्लिंक्स के रूप में संदर्भित किया जाता है।<ref>{{cite web
Line 141: Line 141:
  | first      = Jonathan | last = Corbet
  | first      = Jonathan | last = Corbet
  | publisher  = [[LWN.net]]}}</ref>
  | publisher  = [[LWN.net]]}}</ref>
क्लोनिंग द्वारा, फाइल सिस्टम मौजूदा [[इनोड]] की ओर इशारा करते हुए नया लिंक नहीं बनाता है; इसके बजाय, यह नया इनोड बनाता है जो प्रारंभ में मूल फ़ाइल के साथ समान डिस्क ब्लॉक साझा करता है। नतीजतन, क्लोनिंग केवल उसी Btrfs फाइल सिस्टम की सीमाओं के भीतर काम करती है, लेकिन लिनक्स कर्नेल के संस्करण 3.6 के बाद से यह कुछ परिस्थितियों में उपखंडों की सीमाओं को पार कर सकता है।<ref name="btrfs-usecases" /><ref>{{cite web
क्लोनिंग द्वारा, फाइल सिस्टम मौजूदा [[इनोड]] की ओर इशारा करते हुए नया लिंक नहीं बनाता है; इसके अतिरिक्त, यह नया इनोड बनाता है जो प्रारंभ में मूल फ़ाइल के साथ समान डिस्क ब्लॉक साझा करता है। नतीजतन, क्लोनिंग केवल उसी Btrfs फाइल सिस्टम की सीमाओं के भीतर काम करती है, लेकिन लिनक्स कर्नेल के संस्करण 3.6 के बाद से यह कुछ परिस्थितियों में उपखंडों की सीमाओं को पार कर सकता है।<ref name="btrfs-usecases" /><ref>{{cite web
  | url        = https://github.com/torvalds/linux/commit/362a20c5e27614739c46707d1c5f55c214d164ce
  | url        = https://github.com/torvalds/linux/commit/362a20c5e27614739c46707d1c5f55c214d164ce
  | title      = btrfs: allow cross-subvolume file clone
  | title      = btrfs: allow cross-subvolume file clone
Line 147: Line 147:
  | website    = github.com}}</ref> वास्तविक डेटा ब्लॉक डुप्लिकेट नहीं हैं; उसी समय, Btrfs की कॉपी-ऑन-राइट (CoW) प्रकृति के कारण, किसी भी क्लोन फ़ाइल में संशोधन मूल फ़ाइल में दिखाई नहीं देता है और इसके विपरीत।<ref name="oracle-reflinks" />
  | website    = github.com}}</ref> वास्तविक डेटा ब्लॉक डुप्लिकेट नहीं हैं; उसी समय, Btrfs की कॉपी-ऑन-राइट (CoW) प्रकृति के कारण, किसी भी क्लोन फ़ाइल में संशोधन मूल फ़ाइल में दिखाई नहीं देता है और इसके विपरीत।<ref name="oracle-reflinks" />


क्लोनिंग को [[कठिन कड़ियाँ]] के साथ भ्रमित नहीं होना चाहिए, जो निर्देशिका प्रविष्टियाँ हैं जो ही फ़ाइल के साथ कई फ़ाइल नामों को जोड़ती हैं। जबकि हार्ड लिंक को ही फ़ाइल के लिए अलग-अलग नामों से लिया जा सकता है, Btrfs में क्लोनिंग स्वतंत्र फ़ाइलें प्रदान करती है जो शुरू में अपने सभी डिस्क ब्लॉक साझा करती हैं।<ref name="oracle-reflinks" /><ref>{{cite web
क्लोनिंग को [[कठिन कड़ियाँ]] के साथ भ्रमित नहीं होना चाहिए, जो निर्देशिका प्रविष्टियाँ हैं जो ही फ़ाइल के साथ कई फ़ाइल नामों को जोड़ती हैं। जबकि हार्ड लिंक को ही फ़ाइल के लिए अलग-अलग नामों से लिया जा सकता है, Btrfs में क्लोनिंग स्वतंत्र फ़ाइलें प्रदान करती है जो प्रारंभ में अपने सभी डिस्क ब्लॉक साझा करती हैं।<ref name="oracle-reflinks" /><ref>{{cite web
  | url        = http://www.pixelbeat.org/docs/unix_links.html
  | url        = http://www.pixelbeat.org/docs/unix_links.html
  | title      = Symlinks reference names, hardlinks reference meta-data and reflinks reference data
  | title      = Symlinks reference names, hardlinks reference meta-data and reflinks reference data
Line 168: Line 168:
  | access-date = 2009-11-02
  | access-date = 2009-11-02
  | website    = savannah.gnu.org}}</ref>
  | website    = savannah.gnu.org}}</ref>
डेटा क्लोनिंग के अलावा ({{tt|FICLONE}}), Btrfs द्वारा आउट-ऑफ़-बैंड डुप्लीकेशन का भी समर्थन करता है {{tt|FIDEDUPERANGE}}. यह कार्यक्षमता दो फ़ाइलों को (आंशिक रूप से भी) समान डेटा के साथ भंडारण साझा करने की अनुमति देती है।<ref>{{man|2|ioctl_fideduperange|Linux}}</ref><ref name=dedup/>
डेटा क्लोनिंग के अतिरिक्त ({{tt|FICLONE}}), Btrfs द्वारा आउट-ऑफ़-बैंड डुप्लीकेशन का भी समर्थन करता है {{tt|FIDEDUPERANGE}}. यह कार्यक्षमता दो फ़ाइलों को (आंशिक रूप से भी) समान डेटा के साथ भंडारण साझा करने की अनुमति देती है।<ref>{{man|2|ioctl_fideduperange|Linux}}</ref><ref name=dedup/>
=== उपखंड और स्नैपशॉट ===
=== उपखंड और स्नैपशॉट ===
[[File:Snapper root list screenshot.png|upright=1.5|thumb|स्नैपर के साथ प्रबंधित Btrfs फ़ाइल सिस्टम के स्नैपशॉट का उदाहरण]]Btrfs सबवोल्यूम को अलग POSIX फाइल [[ नाम स्थान |नाम स्थान]] , [[माउंट (कंप्यूटिंग)]] के रूप में अलग से पास करके सोचा जा सकता है <code>subvol</code> या <code>subvolid</code> के लिए विकल्प {{man|8|mount|man.cx||inline}} उपयोगिता। इसे शीर्ष-स्तरीय सबवोल्यूम को आरोहित करके भी एक्सेस किया जा सकता है, जिस स्थिति में सबवॉल्यूम इसके उपनिर्देशिकाओं के रूप में दिखाई और पहुंच योग्य होते हैं।<ref name="btrfs-sysadmin-guide" />
[[File:Snapper root list screenshot.png|upright=1.5|thumb|स्नैपर के साथ प्रबंधित Btrfs फ़ाइल सिस्टम के स्नैपशॉट का उदाहरण]]Btrfs सबवोल्यूम को अलग POSIX फाइल [[ नाम स्थान |नाम स्थान]] , [[माउंट (कंप्यूटिंग)]] के रूप में अलग से पास करके सोचा जा सकता है <code>subvol</code> या <code>subvolid</code> के लिए विकल्प {{man|8|mount|man.cx||inline}} उपयोगिता। इसे शीर्ष-स्तरीय सबवोल्यूम को आरोहित करके भी एक्सेस किया जा सकता है, जिस स्थिति में सबवॉल्यूम इसके उपनिर्देशिकाओं के रूप में दिखाई और पहुंच योग्य होते हैं।<ref name="btrfs-sysadmin-guide" />
Line 174: Line 174:
फ़ाइल सिस्टम पदानुक्रम के भीतर किसी भी स्थान पर उपखंड बनाए जा सकते हैं, और उन्हें नेस्टेड भी किया जा सकता है। नेस्टेड उपखंड अपने मूल उपखंडों के भीतर उपनिर्देशिकाओं के रूप में दिखाई देते हैं, उसी तरह जिस तरह शीर्ष-स्तरीय उपखंड अपने उपखंडों को उपनिर्देशिकाओं के रूप में प्रस्तुत करता है। किसी सबवॉल्यूम को हटाना तब तक संभव नहीं है जब तक नेस्टिंग पदानुक्रम में उसके नीचे के सभी सबवॉल्यूम हटा नहीं दिए जाते; परिणामस्वरूप, शीर्ष-स्तरीय उपखंडों को हटाया नहीं जा सकता।<ref name="oracle-btrfs-subvolumes" />
फ़ाइल सिस्टम पदानुक्रम के भीतर किसी भी स्थान पर उपखंड बनाए जा सकते हैं, और उन्हें नेस्टेड भी किया जा सकता है। नेस्टेड उपखंड अपने मूल उपखंडों के भीतर उपनिर्देशिकाओं के रूप में दिखाई देते हैं, उसी तरह जिस तरह शीर्ष-स्तरीय उपखंड अपने उपखंडों को उपनिर्देशिकाओं के रूप में प्रस्तुत करता है। किसी सबवॉल्यूम को हटाना तब तक संभव नहीं है जब तक नेस्टिंग पदानुक्रम में उसके नीचे के सभी सबवॉल्यूम हटा नहीं दिए जाते; परिणामस्वरूप, शीर्ष-स्तरीय उपखंडों को हटाया नहीं जा सकता।<ref name="oracle-btrfs-subvolumes" />


किसी भी Btrfs फाइल सिस्टम में हमेशा डिफ़ॉल्ट सबवॉल्यूम होता है, जो शुरू में शीर्ष-स्तरीय सबवॉल्यूम के रूप में सेट होता है, और डिफ़ॉल्ट रूप से आरोहित होता है यदि कोई सबवॉल्यूम चयन विकल्प पास नहीं किया जाता है <code>mount</code>. डिफ़ॉल्ट सबवोल्यूम को आवश्यकतानुसार बदला जा सकता है।<ref name="oracle-btrfs-subvolumes" />
किसी भी Btrfs फाइल सिस्टम में हमेशा डिफ़ॉल्ट सबवॉल्यूम होता है, जो प्रारंभ में शीर्ष-स्तरीय सबवॉल्यूम के रूप में सेट होता है, और डिफ़ॉल्ट रूप से आरोहित होता है यदि कोई सबवॉल्यूम चयन विकल्प पास नहीं किया जाता है <code>mount</code>. डिफ़ॉल्ट सबवोल्यूम को आवश्यकतानुसार बदला जा सकता है।<ref name="oracle-btrfs-subvolumes" />


Btrfs स्नैपशॉट (कंप्यूटर स्टोरेज) सबवॉल्यूम है जो Btrfs की कॉपी-ऑन-राइट क्षमताओं का उपयोग करके अपने डेटा (और मेटाडेटा) को किसी अन्य सबवॉल्यूम के साथ साझा करता है, और स्नैपशॉट में संशोधन मूल सबवॉल्यूम में दिखाई नहीं देते हैं। बार लिखने योग्य स्नैपशॉट बनने के बाद, इसे मूल फ़ाइल सिस्टम के वैकल्पिक संस्करण के रूप में माना जा सकता है। उदाहरण के लिए, स्नैपशॉट पर वापस जाने के लिए, संशोधित मूल सबवॉल्यूम को अनमाउंट करने की आवश्यकता होती है और स्नैपशॉट को उसके स्थान पर माउंट करने की आवश्यकता होती है। उस समय, मूल सबवॉल्यूम को भी हटाया जा सकता है।<ref name="btrfs-sysadmin-guide" />
Btrfs स्नैपशॉट (कंप्यूटर स्टोरेज) सबवॉल्यूम है जो Btrfs की कॉपी-ऑन-राइट क्षमताओं का उपयोग करके अपने डेटा (और मेटाडेटा) को किसी अन्य सबवॉल्यूम के साथ साझा करता है, और स्नैपशॉट में संशोधन मूल सबवॉल्यूम में दिखाई नहीं देते हैं। बार लिखने योग्य स्नैपशॉट बनने के बाद, इसे मूल फ़ाइल सिस्टम के वैकल्पिक संस्करण के रूप में माना जा सकता है। उदाहरण के लिए, स्नैपशॉट पर वापस जाने के लिए, संशोधित मूल सबवॉल्यूम को अनमाउंट करने की आवश्यकता होती है और स्नैपशॉट को उसके स्थान पर माउंट करने की आवश्यकता होती है। उस समय, मूल सबवॉल्यूम को भी हटाया जा सकता है।<ref name="btrfs-sysadmin-guide" />


Btrfs की कॉपी-ऑन-राइट (CoW) प्रकृति का मतलब है कि स्नैपशॉट जल्दी बन जाते हैं, जबकि शुरुआत में बहुत कम डिस्क स्थान लेते हैं। चूंकि स्नैपशॉट सबवोल्यूम है, नेस्टेड स्नैपशॉट बनाना भी संभव है। सबवोल्यूम का स्नैपशॉट लेना पुनरावर्ती प्रक्रिया नहीं है; इस प्रकार, यदि सबवोल्यूम का स्नैपशॉट बनाया जाता है, तो प्रत्येक सबवॉल्यूम या स्नैपशॉट जिसमें सबवोल्यूम पहले से ही शामिल है, स्नैपशॉट के अंदर उसी नाम की खाली निर्देशिका में मैप किया जाता है।<ref name="btrfs-sysadmin-guide" /><ref name="oracle-btrfs-subvolumes" />
Btrfs की कॉपी-ऑन-राइट (CoW) प्रकृति का तात्पर्य है कि स्नैपशॉट जल्दी बन जाते हैं, जबकि शुरुआत में बहुत कम डिस्क स्थान लेते हैं। चूंकि स्नैपशॉट सबवोल्यूम है, नेस्टेड स्नैपशॉट बनाना भी संभव है। सबवोल्यूम का स्नैपशॉट लेना पुनरावर्ती प्रक्रिया नहीं है; इस प्रकार, यदि सबवोल्यूम का स्नैपशॉट बनाया जाता है, तो प्रत्येक सबवॉल्यूम या स्नैपशॉट जिसमें सबवोल्यूम पहले से ही सम्मिलित है, स्नैपशॉट के अंदर उसी नाम की खाली निर्देशिका में मैप किया जाता है।<ref name="btrfs-sysadmin-guide" /><ref name="oracle-btrfs-subvolumes" />


किसी निर्देशिका का स्नैपशॉट लेना संभव नहीं है, क्योंकि केवल उपखंडों में स्नैपशॉट हो सकते हैं। हालाँकि, समाधान है जिसमें उपखंडों में फैले रिलिंक्स शामिल हैं: नया सबवॉल्यूम बनाया गया है, जिसमें लक्षित निर्देशिका की सामग्री के लिए क्रॉस-सबवॉल्यूम रीलिंक्स शामिल हैं। उपलब्ध होने के बाद, इस नए वॉल्यूम का स्नैपशॉट बनाया जा सकता है।<ref name="btrfs-usecases" />
किसी निर्देशिका का स्नैपशॉट लेना संभव नहीं है, क्योंकि केवल उपखंडों में स्नैपशॉट हो सकते हैं। हालाँकि, समाधान है जिसमें उपखंडों में फैले रिलिंक्स सम्मिलित हैं: नया सबवॉल्यूम बनाया गया है, जिसमें लक्षित निर्देशिका की सामग्री के लिए क्रॉस-सबवॉल्यूम रीलिंक्स सम्मिलित हैं। उपलब्ध होने के बाद, इस नए वॉल्यूम का स्नैपशॉट बनाया जा सकता है।<ref name="btrfs-usecases" />


Btrfs में सबवॉल्यूम पारंपरिक [[लॉजिकल वॉल्यूम मैनेजर]] (LVM) लॉजिकल वॉल्यूम से काफी अलग है। LVM के साथ, लॉजिकल वॉल्यूम अलग ब्लॉक डिवाइस है, जबकि Btrfs सबवोल्यूम नहीं है और इसे इस तरह से ट्रीट या इस्तेमाल नहीं किया जा सकता है।<ref name="btrfs-sysadmin-guide" />btrfs के dd या LVM स्नैपशॉट बनाने से डेटा हानि होती है यदि या तो मूल या प्रतिलिपि माउंट की जाती है जबकि दोनों ही कंप्यूटर पर हैं।<ref>{{Cite web|url=https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices|title=Gotchas - btrfs विकी|website=btrfs.wiki.kernel.org}}</ref>
Btrfs में सबवॉल्यूम पारंपरिक [[लॉजिकल वॉल्यूम मैनेजर]] (LVM) लॉजिकल वॉल्यूम से काफी अलग है। LVM के साथ, लॉजिकल वॉल्यूम अलग ब्लॉक डिवाइस है, जबकि Btrfs सबवोल्यूम नहीं है और इसे इस तरह से ट्रीट या इस्तेमाल नहीं किया जा सकता है।<ref name="btrfs-sysadmin-guide" />btrfs के dd या LVM स्नैपशॉट बनाने से डेटा हानि होती है यदि या तो मूल या प्रतिलिपि माउंट की जाती है जबकि दोनों ही कंप्यूटर पर हैं।<ref>{{Cite web|url=https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices|title=Gotchas - btrfs विकी|website=btrfs.wiki.kernel.org}}</ref>
===भेजें–प्राप्त करें===
===भेजें–प्राप्त करें===
उपखंडों (या स्नैपशॉट्स) की किसी भी जोड़ी को देखते हुए, Btrfs उनके बीच द्विआधारी अंतर उत्पन्न कर सकता है ( <code>btrfs send</code> कमांड) जिसे बाद में फिर से चलाया जा सकता है (उपयोग करके <code>btrfs receive</code>), संभवतः भिन्न Btrfs फ़ाइल सिस्टम पर। भेजें-प्राप्त करें सुविधा प्रभावी रूप से सबवॉल्यूम को दूसरे में परिवर्तित करने के लिए आवश्यक डेटा संशोधनों का सेट बनाती है (और लागू करती है)।<ref name="corbet-jul2011" /><ref name="oracle-btrfs-send-receive" />
उपखंडों (या स्नैपशॉट्स) की किसी भी जोड़ी को देखते हुए, Btrfs उनके मध्य द्विआधारी अंतर उत्पन्न कर सकता है ( <code>btrfs send</code> कमांड) जिसे बाद में फिर से चलाया जा सकता है (उपयोग करके <code>btrfs receive</code>), संभवतः भिन्न Btrfs फ़ाइल सिस्टम पर। भेजें-प्राप्त करें सुविधा प्रभावी रूप से सबवॉल्यूम को दूसरे में परिवर्तित करने के लिए आवश्यक डेटा संशोधनों का सेट बनाती है (और लागू करती है)।<ref name="corbet-jul2011" /><ref name="oracle-btrfs-send-receive" />


फ़ाइल सिस्टम प्रतिकृति (कंप्यूटिंग) के सरल रूप को लागू करने के लिए या वृद्धिशील बैकअप करने के उद्देश्य से नियमित रूप से शेड्यूल किए गए स्नैपशॉट के साथ भेजें/प्राप्त करें सुविधा का उपयोग किया जा सकता है।<ref name="corbet-jul2011" /><ref name="oracle-btrfs-send-receive" />
फ़ाइल सिस्टम प्रतिकृति (कंप्यूटिंग) के सरल रूप को लागू करने के लिए या वृद्धिशील बैकअप करने के उद्देश्य से नियमित रूप से शेड्यूल किए गए स्नैपशॉट के साथ भेजें/प्राप्त करें सुविधा का उपयोग किया जा सकता है।<ref name="corbet-jul2011" /><ref name="oracle-btrfs-send-receive" />
=== कोटा समूह ===
=== कोटा समूह ===
[[File:Btrfs qgroup screenshot.png|upright=1.5|thumb|Btrfs कोटा समूहों का उदाहरण]]कोटा समूह (या क्यूग्रुप) स्थान के लिए ऊपरी सीमा लगाता है जो सबवोल्यूम या स्नैपशॉट उपभोग कर सकता है। नया स्नैपशॉट शुरू में कोई कोटा नहीं लेता है क्योंकि इसका डेटा उसके माता-पिता के साथ साझा किया जाता है, लेकिन उसके बाद नई फ़ाइलों और मौजूदा फ़ाइलों पर कॉपी-ऑन-राइट संचालन के लिए शुल्क लगता है। जब कोटा सक्रिय होता है, प्रत्येक नए सबवॉल्यूम या स्नैपशॉट के साथ कोटा समूह स्वचालित रूप से बनाया जाता है। ये प्रारंभिक कोटा समूह बिल्डिंग ब्लॉक्स हैं जिन्हें समूहीकृत किया जा सकता है ( <code>btrfs qgroup</code> कमांड) कोटा पूल को लागू करने के लिए पदानुक्रम में।<ref name="jansen-oct2011" />
[[File:Btrfs qgroup screenshot.png|upright=1.5|thumb|Btrfs कोटा समूहों का उदाहरण]]कोटा समूह (या क्यूग्रुप) स्थान के लिए ऊपरी सीमा लगाता है जो सबवोल्यूम या स्नैपशॉट उपभोग कर सकता है। नया स्नैपशॉट प्रारंभ में कोई कोटा नहीं लेता है क्योंकि इसका डेटा उसके माता-पिता के साथ साझा किया जाता है, लेकिन उसके बाद नई फ़ाइलों और मौजूदा फ़ाइलों पर कॉपी-ऑन-राइट संचालन के लिए शुल्क लगता है। जब कोटा सक्रिय होता है, प्रत्येक नए सबवॉल्यूम या स्नैपशॉट के साथ कोटा समूह स्वचालित रूप से बनाया जाता है। ये प्रारंभिक कोटा समूह बिल्डिंग ब्लॉक्स हैं जिन्हें समूहीकृत किया जा सकता है ( <code>btrfs qgroup</code> कमांड) कोटा पूल को लागू करने के लिए पदानुक्रम में।<ref name="jansen-oct2011" />


कोटा समूह केवल उपखंडों और स्नैपशॉट पर लागू होते हैं, जबकि अलग-अलग उपनिर्देशिकाओं, उपयोगकर्ताओं या उपयोगकर्ता समूहों पर कोटा लागू करना संभव नहीं है। हालाँकि, सभी उपयोगकर्ताओं या उपयोगकर्ता समूहों के लिए अलग-अलग सबवॉल्यूम का उपयोग करके वर्कअराउंड संभव है, जिसके लिए कोटा लागू करने की आवश्यकता होती है।
कोटा समूह केवल उपखंडों और स्नैपशॉट पर लागू होते हैं, जबकि अलग-अलग उपनिर्देशिकाओं, उपयोगकर्ताओं या उपयोगकर्ता समूहों पर कोटा लागू करना संभव नहीं है। हालाँकि, सभी उपयोगकर्ताओं या उपयोगकर्ता समूहों के लिए अलग-अलग सबवॉल्यूम का उपयोग करके वर्कअराउंड संभव है, जिसके लिए कोटा लागू करने की आवश्यकता होती है।
Line 195: Line 195:
निश्चित स्थानों में बहुत कम मेटाडेटा के लंगर डाले जाने के परिणामस्वरूप, Btrfs बैकएंड भंडारण उपकरणों के असामान्य स्थानिक लेआउट को फिट करने के लिए ताना मार सकता है। <code>btrfs-convert</code> e> टूल मूल फ़ाइल सिस्टम की असंशोधित प्रति को संरक्षित करते हुए - इसके असंबद्ध स्थान में समकक्ष Btrfs मेटाडेटा को नेस्ट करके, ext2/3/4 या ReiserFS फ़ाइल सिस्टम का इन-प्लेस रूपांतरण करने की इस क्षमता का उपयोग करता है।<ref name="ext3_conversion" />
निश्चित स्थानों में बहुत कम मेटाडेटा के लंगर डाले जाने के परिणामस्वरूप, Btrfs बैकएंड भंडारण उपकरणों के असामान्य स्थानिक लेआउट को फिट करने के लिए ताना मार सकता है। <code>btrfs-convert</code> e> टूल मूल फ़ाइल सिस्टम की असंशोधित प्रति को संरक्षित करते हुए - इसके असंबद्ध स्थान में समकक्ष Btrfs मेटाडेटा को नेस्ट करके, ext2/3/4 या ReiserFS फ़ाइल सिस्टम का इन-प्लेस रूपांतरण करने की इस क्षमता का उपयोग करता है।<ref name="ext3_conversion" />


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


सभी रूपांतरित फ़ाइलें उपलब्ध हैं और Btrfs के डिफ़ॉल्ट सबवोल्यूम में लिखने योग्य हैं। मूल ext2/3/4 फाइलसिस्टम के सभी संदर्भों को धारण करने वाली विरल फाइल को अलग सबवोल्यूम में बनाया जाता है, जो रीड-ओनली डिस्क इमेज के रूप में अपने आप माउंट करने योग्य होती है, जिससे मूल और परिवर्तित फाइल सिस्टम दोनों को एक्सेस किया जा सकता है। उसी समय। इस विरल फ़ाइल को हटाने से स्थान खाली हो जाता है और रूपांतरण स्थायी हो जाता है।<ref name="ext3_conversion" />
सभी रूपांतरित फ़ाइलें उपलब्ध हैं और Btrfs के डिफ़ॉल्ट सबवोल्यूम में लिखने योग्य हैं। मूल ext2/3/4 फाइलसिस्टम के सभी संदर्भों को धारण करने वाली विरल फाइल को अलग सबवोल्यूम में बनाया जाता है, जो रीड-ओनली डिस्क इमेज के रूप में अपने आप माउंट करने योग्य होती है, जिससे मूल और परिवर्तित फाइल सिस्टम दोनों को एक्सेस किया जा सकता है। उसी समय। इस विरल फ़ाइल को हटाने से स्थान खाली हो जाता है और रूपांतरण स्थायी हो जाता है।<ref name="ext3_conversion" />
Line 201: Line 201:
मेनलाइन लिनक्स कर्नेल के 4.x संस्करणों में, इन-प्लेस ext3/4 रूपांतरण को अपरीक्षित और शायद ही कभी इस्तेमाल किया गया माना जाता था।<ref name="ext3_conversion" />हालाँकि, फीचर को 2016 में स्क्रैच से फिर से लिखा गया था <code>btrfs-progs</code> 4.6.<ref name="Btrfs progs release 4.6"/>और तब से स्थिर माना जाता है।
मेनलाइन लिनक्स कर्नेल के 4.x संस्करणों में, इन-प्लेस ext3/4 रूपांतरण को अपरीक्षित और शायद ही कभी इस्तेमाल किया गया माना जाता था।<ref name="ext3_conversion" />हालाँकि, फीचर को 2016 में स्क्रैच से फिर से लिखा गया था <code>btrfs-progs</code> 4.6.<ref name="Btrfs progs release 4.6"/>और तब से स्थिर माना जाता है।


ReiserFS से इन-प्लेस रूपांतरण सितंबर 2017 में कर्नेल 4.13 के साथ पेश किया गया था।<ref>{{cite web | url = https://btrfs.readthedocs.io/en/latest/btrfs-convert.html | title = btrfs-convert(8) — BTRFS Documentation | access-date = 2022-10-16 }}</ref>
ReiserFS से इन-प्लेस रूपांतरण सितंबर 2017 में कर्नेल 4.13 के साथ प्रस्तुत किया गया था।<ref>{{cite web | url = https://btrfs.readthedocs.io/en/latest/btrfs-convert.html | title = btrfs-convert(8) — BTRFS Documentation | access-date = 2022-10-16 }}</ref>
=== यूनियन माउंटिंग / सीड डिवाइस ===
=== यूनियन माउंटिंग / सीड डिवाइस ===
नया Btrfs बनाते समय, मौजूदा Btrfs को रीड-ओनली सीड फाइल सिस्टम के रूप में इस्तेमाल किया जा सकता है।<ref>{{cite web | url=https://btrfs.wiki.kernel.org/index.php/Seed-device | title=बीज यंत्र| access-date=1 August 2017 | archive-date=12 June 2017 | archive-url=https://web.archive.org/web/20170612105214/https://btrfs.wiki.kernel.org/index.php/Seed-device | url-status=dead }}</ref> नया फाइल सिस्टम तब बीज पर कॉपी-ऑन-राइट ओवरले के रूप में कार्य करेगा, यूनियन माउंटिंग के रूप में। बीज को बाद में Btrfs से अलग किया जा सकता है, जिस बिंदु पर रिबैलेंसर अलग होने से पहले नए फाइल सिस्टम द्वारा अभी भी संदर्भित किसी भी बीज डेटा की नकल करेगा। मेसन ने सुझाव दिया है कि यह [[लाइव सीडी]] इंस्टॉलर के लिए उपयोगी हो सकता है, जो ऑप्टिकल डिस्क पर केवल-पढ़ने के लिए Btrfs बीज से बूट हो सकता है, पृष्ठभूमि में इंस्टाल डिस्क पर लक्ष्य विभाजन के लिए खुद को पुन: संतुलित करता है जबकि उपयोगकर्ता काम करना जारी रखता है, फिर बाहर निकाल देता है डिस्क को रिबूट किए बिना स्थापना को पूरा करने के लिए।<ref name="mason-apr2012" />
नया Btrfs बनाते समय, मौजूदा Btrfs को रीड-ओनली सीड फाइल सिस्टम के रूप में इस्तेमाल किया जा सकता है।<ref>{{cite web | url=https://btrfs.wiki.kernel.org/index.php/Seed-device | title=बीज यंत्र| access-date=1 August 2017 | archive-date=12 June 2017 | archive-url=https://web.archive.org/web/20170612105214/https://btrfs.wiki.kernel.org/index.php/Seed-device | url-status=dead }}</ref> नया फाइल सिस्टम तब बीज पर कॉपी-ऑन-राइट ओवरले के रूप में कार्य करेगा, यूनियन माउंटिंग के रूप में। बीज को बाद में Btrfs से अलग किया जा सकता है, जिस बिंदु पर रिबैलेंसर अलग होने से पहले नए फाइल सिस्टम द्वारा अभी भी संदर्भित किसी भी बीज डेटा की नकल करेगा। मेसन ने सुझाव दिया है कि यह [[लाइव सीडी]] इंस्टॉलर के लिए उपयोगी हो सकता है, जो ऑप्टिकल डिस्क पर केवल-पढ़ने के लिए Btrfs बीज से बूट हो सकता है, पृष्ठभूमि में इंस्टाल डिस्क पर लक्ष्य विभाजन के लिए खुद को पुन: संतुलित करता है जबकि उपयोगकर्ता काम करना जारी रखता है, फिर बाहर निकाल देता है डिस्क को रिबूट किए बिना स्थापना को पूरा करने के लिए।<ref name="mason-apr2012" />
=== एन्क्रिप्शन ===
=== एन्क्रिप्शन ===
2009 के अपने साक्षात्कार में, क्रिस मेसन ने कहा कि Btrfs के लिए एन्क्रिप्शन के लिए समर्थन की योजना बनाई गई थी।<ref>{{cite web |url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux |title=A Conversation with Chris Mason on BTRfs: the next generation file system for Linux |date=2009-06-22 |access-date=2014-10-09 |first=Amanda |last=McPherson |publisher=[[Linux Foundation]] |quote=भविष्य के रिलीज में हम ऑनलाइन fsck, डुप्लीकेशन, एन्क्रिप्शन और अन्य सुविधाओं को जोड़ने की योजना बना रहे हैं जो लंबे समय से व्यवस्थापक इच्छा सूची में हैं।|archive-url=https://web.archive.org/web/20120627065427/http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux |archive-date=27 June 2012 }}</ref> इस बीच, एन्क्रिप्शन को Btrfs के साथ संयोजित करने का समाधान अंतर्निहित उपकरणों पर पूर्ण-डिस्क एन्क्रिप्शन तंत्र जैसे [[dm-crypt]] / [[LUKS]] का उपयोग करना और उस परत के शीर्ष पर Btrfs फ़ाइल सिस्टम बनाना है।
2009 के अपने साक्षात्कार में, क्रिस मेसन ने कहा कि Btrfs के लिए एन्क्रिप्शन के लिए समर्थन की योजना बनाई गई थी।<ref>{{cite web |url=http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux |title=A Conversation with Chris Mason on BTRfs: the next generation file system for Linux |date=2009-06-22 |access-date=2014-10-09 |first=Amanda |last=McPherson |publisher=[[Linux Foundation]] |quote=भविष्य के रिलीज में हम ऑनलाइन fsck, डुप्लीकेशन, एन्क्रिप्शन और अन्य सुविधाओं को जोड़ने की योजना बना रहे हैं जो लंबे समय से व्यवस्थापक इच्छा सूची में हैं।|archive-url=https://web.archive.org/web/20120627065427/http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux |archive-date=27 June 2012 }}</ref> इस मध्य, एन्क्रिप्शन को Btrfs के साथ संयोजित करने का समाधान अंतर्निहित उपकरणों पर पूर्ण-डिस्क एन्क्रिप्शन तंत्र जैसे [[dm-crypt]] / [[LUKS]] का उपयोग करना और उस परत के शीर्ष पर Btrfs फ़ाइल सिस्टम बनाना है।


{{As of|2020|post=,}} विकासकर्ता [[HMAC]] (SHA256) जैसे प्रमुख हैश को जोड़ने के लिए काम कर रहे थे।<ref>{{cite web |last=Sterba |first=David |title=authenticated file systems using HMAC(SHA256) |url=https://lore.kernel.org/linux-btrfs/3ca669b7-7447-5793-f231-32d5417bd8ee@suse.com/T/#m949c14afbe4485faf61bd6a568abfe21163bf5bd |website=Lore.Kernel.org |access-date=25 April 2020 }}</ref>
{{As of|2020|post=,}} विकासकर्ता [[HMAC]] (SHA256) जैसे प्रमुख हैश को जोड़ने के लिए काम कर रहे थे।<ref>{{cite web |last=Sterba |first=David |title=authenticated file systems using HMAC(SHA256) |url=https://lore.kernel.org/linux-btrfs/3ca669b7-7447-5793-f231-32d5417bd8ee@suse.com/T/#m949c14afbe4485faf61bd6a568abfe21163bf5bd |website=Lore.Kernel.org |access-date=25 April 2020 }}</ref>
=== जांच और वसूली ===
=== जांच और वसूली ===
यूनिक्स सिस्टम परंपरागत रूप से फाइल सिस्टम की जांच और मरम्मत के लिए fsck प्रोग्राम पर भरोसा करते हैं। यह कार्यक्षमता के माध्यम से कार्यान्वित की जाती है <code>btrfs check</code> कार्यक्रम। संस्करण 4.0 के बाद से यह कार्यक्षमता अपेक्षाकृत स्थिर मानी जाती है। हालाँकि, दिसंबर 2022 तक, btrfs प्रलेखन से पता चलता है कि इसका <code>--repair</code> विकल्प का उपयोग केवल तभी किया जाना चाहिए जब आपको किसी डेवलपर या अनुभवी उपयोगकर्ता द्वारा सलाह दी गई हो।<ref name="btrfs-check" />अगस्त 2022 तक, एसएलई प्रलेखन लाइव सीडी का उपयोग करने, बैकअप करने और केवल अंतिम उपाय के रूप में मरम्मत विकल्प का उपयोग करने की सिफारिश करता है।<ref>{{Cite web |title=How to recover from BTRFS errors {{!}} Support {{!}} SUSE |url=https://www.suse.com/support/kb/doc/?id=000018769 |access-date=2023-01-28 |website=www.suse.com}}</ref>
यूनिक्स सिस्टम परंपरागत रूप से फाइल सिस्टम की जांच और मरम्मत के लिए fsck प्रोग्राम पर भरोसा करते हैं। यह कार्यक्षमता के माध्यम से कार्यान्वित की जाती है <code>btrfs check</code> कार्यक्रम। संस्करण 4.0 के बाद से यह कार्यक्षमता अपेक्षाकृत स्थिर मानी जाती है। हालाँकि, दिसंबर 2022 तक, btrfs प्रलेखन से पता चलता है कि इसका <code>--repair</code> विकल्प का उपयोग केवल तभी किया जाना चाहिए जब आपको किसी डेवलपर या अनुभवी उपयोगकर्ता द्वारा सलाह दी गई हो।<ref name="btrfs-check" />अगस्त 2022 तक, एसएलई प्रलेखन लाइव सीडी का उपयोग करने, बैकअप करने और केवल अंतिम उपाय के रूप में मरम्मत विकल्प का उपयोग करने की सिफारिश करता है।<ref>{{Cite web |title=How to recover from BTRFS errors {{!}} Support {{!}} SUSE |url=https://www.suse.com/support/kb/doc/?id=000018769 |access-date=2023-01-28 |website=www.suse.com}}</ref>
और टूल है, जिसका नाम है <code>btrfs-restore</code>, जिसका उपयोग टूटे हुए फ़ाइल सिस्टम को संशोधित किए बिना (यानी, गैर-विनाशकारी रूप से) बिना किसी अनमाउंट फ़ाइल सिस्टम से फ़ाइलों को पुनर्प्राप्त करने के लिए किया जा सकता है।<ref>{{Cite web|url=https://btrfs.wiki.kernel.org/index.php/Restore|title=पुनर्स्थापित करें - btrfs विकी|website=btrfs.wiki.kernel.org}}</ref><ref>{{Cite web |title=btrfs-restore(8) - Linux manual page |url=https://man7.org/linux/man-pages/man8/btrfs-restore.8.html |access-date=2023-01-28 |website=man7.org}}</ref>
और टूल है, जिसका नाम है <code>btrfs-restore</code>, जिसका उपयोग टूटे हुए फ़ाइल सिस्टम को संशोधित किए बिना (अर्थात , गैर-विनाशकारी रूप से) बिना किसी अनमाउंट फ़ाइल सिस्टम से फ़ाइलों को पुनर्प्राप्त करने के लिए किया जा सकता है।<ref>{{Cite web|url=https://btrfs.wiki.kernel.org/index.php/Restore|title=पुनर्स्थापित करें - btrfs विकी|website=btrfs.wiki.kernel.org}}</ref><ref>{{Cite web |title=btrfs-restore(8) - Linux manual page |url=https://man7.org/linux/man-pages/man8/btrfs-restore.8.html |access-date=2023-01-28 |website=man7.org}}</ref>
सामान्य उपयोग में, Btrfs ज्यादातर स्व-चिकित्सा है और माउंट समय पर टूटे हुए जड़ वाले पेड़ों से पुनर्प्राप्त कर सकता है, आवधिक डेटा को स्थायी भंडारण के लिए फ़्लश करने के लिए धन्यवाद, डिफ़ॉल्ट रूप से हर 30 सेकंड में। इस प्रकार, अलग-अलग त्रुटियों के कारण अधिकतम 30 सेकंड के फ़ाइल सिस्टम परिवर्तन अगले माउंट पर गुम हो जाएंगे।<ref>{{cite web|url=https://btrfs.wiki.kernel.org/index.php/Problem_FAQ |title=समस्या अक्सर पूछे जाने वाले प्रश्न - btrfs विकी|website=kernel.org |date=2013-07-31 |access-date=2014-01-16}}</ref> इस अवधि को वांछित मान (सेकंड में) निर्दिष्ट करके बदला जा सकता है <code>commit</code> माउंट विकल्प।<ref>{{cite web
सामान्य उपयोग में, Btrfs ज्यादातर स्व-चिकित्सा है और माउंट समय पर टूटे हुए जड़ वाले पेड़ों से पुनर्प्राप्त कर सकता है, आवधिक डेटा को स्थायी भंडारण के लिए फ़्लश करने के लिए धन्यवाद, डिफ़ॉल्ट रूप से हर 30 सेकंड में। इस प्रकार, अलग-अलग त्रुटियों के कारण अधिकतम 30 सेकंड के फ़ाइल सिस्टम परिवर्तन अगले माउंट पर गुम हो जाएंगे।<ref>{{cite web|url=https://btrfs.wiki.kernel.org/index.php/Problem_FAQ |title=समस्या अक्सर पूछे जाने वाले प्रश्न - btrfs विकी|website=kernel.org |date=2013-07-31 |access-date=2014-01-16}}</ref> इस अवधि को वांछित मान (सेकंड में) निर्दिष्ट करके बदला जा सकता है <code>commit</code> माउंट विकल्प।<ref>{{cite web
  | url        = https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=906c176e541f89ed3c04d0e9af1c7cf7b3cc1adb
  | url        = https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=906c176e541f89ed3c04d0e9af1c7cf7b3cc1adb
Line 223: Line 223:
  | access-date = 2014-01-16}}</ref>
  | access-date = 2014-01-16}}</ref>
== डिजाइन ==
== डिजाइन ==
USENIX 2007 में ओहद रोदेह के मूल प्रस्ताव ने नोट किया कि [[बी + पेड़]], जो व्यापक रूप से डेटाबेस के लिए ऑन-डिस्क डेटा संरचनाओं के रूप में उपयोग किए जाते हैं, कुशलता से कॉपी-ऑन-राइट-आधारित स्नैपशॉट की अनुमति नहीं दे सकते क्योंकि इसके पत्ते नोड्स साथ जुड़े हुए थे: यदि पत्ते की नकल की गई थी लिखने पर, उसके भाई-बहनों और माता-पिता को भी उतना ही होना पड़ेगा, जितना कि उनके भाई-बहनों और माता-पिता वगैरह को, जब तक कि पूरे पेड़ की नकल नहीं हो जाती। उन्होंने इसके बजाय संशोधित बी-ट्री (जिसमें कोई पत्ती लिंकेज नहीं है) का सुझाव दिया, जिसमें प्रत्येक ट्री नोड से जुड़ी संदर्भ गणना होती है, लेकिन तदर्थ मुक्त मानचित्र संरचना में संग्रहीत होती है और उन्हें कॉपी-ऑन-राइट बनाने के लिए पेड़ के संतुलन एल्गोरिदम में कुछ छूट मिलती है। दोस्ताना। परिणाम उच्च-प्रदर्शन ऑब्जेक्ट स्टोर के लिए उपयुक्त डेटा संरचना होगी जो अच्छे [[समवर्ती कंप्यूटिंग]] को बनाए रखते हुए कॉपी-ऑन-राइट स्नैपशॉट का प्रदर्शन कर सकती है।<ref name="rodeh-1" />
USENIX 2007 में ओहद रोदेह के मूल प्रस्ताव ने नोट किया कि [[बी + पेड़]], जो व्यापक रूप से डेटाबेस के लिए ऑन-डिस्क डेटा संरचनाओं के रूप में उपयोग किए जाते हैं, कुशलता से कॉपी-ऑन-राइट-आधारित स्नैपशॉट की अनुमति नहीं दे सकते क्योंकि इसके पत्ते नोड्स साथ जुड़े हुए थे: यदि पत्ते की नकल की गई थी लिखने पर, उसके भाई-बहनों और माता-पिता को भी उतना ही होना पड़ेगा, जितना कि उनके भाई-बहनों और माता-पिता वगैरह को, जब तक कि पूरे पेड़ की नकल नहीं हो जाती। उन्होंने इसके अतिरिक्त संशोधित बी-ट्री (जिसमें कोई पत्ती लिंकेज नहीं है) का सुझाव दिया, जिसमें प्रत्येक ट्री नोड से जुड़ी संदर्भ गणना होती है, लेकिन तदर्थ मुक्त मानचित्र संरचना में संग्रहीत होती है और उन्हें कॉपी-ऑन-राइट बनाने के लिए पेड़ के संतुलन एल्गोरिदम में कुछ छूट मिलती है। दोस्ताना। परिणाम उच्च-प्रदर्शन ऑब्जेक्ट स्टोर के लिए उपयुक्त डेटा संरचना होगी जो अच्छे [[समवर्ती कंप्यूटिंग]] को बनाए रखते हुए कॉपी-ऑन-राइट स्नैपशॉट का प्रदर्शन कर सकती है।<ref name="rodeh-1" />


उस वर्ष बाद में Oracle में, क्रिस मेसन ने स्नैपशॉट-सक्षम फ़ाइल सिस्टम पर काम करना शुरू किया, जो इस डेटा संरचना का लगभग विशेष रूप से उपयोग करेगा—न केवल मेटाडेटा और फ़ाइल डेटा के लिए, बल्कि पुनरावर्ती रूप से पेड़ों के स्थान आवंटन को ट्रैक करने के लिए भी। इसने सभी ट्रैवर्सल और संशोधनों को ही कोड पथ के माध्यम से फ़नल करने की अनुमति दी, जिसके विरुद्ध संपूर्ण फ़ाइल सिस्टम को लाभ पहुंचाने के लिए केवल बार कॉपी ऑन राइट, चेकसमिंग और मिररिंग जैसी सुविधाओं को लागू करने की आवश्यकता थी।<ref name="aurora-1" />
उस वर्ष बाद में Oracle में, क्रिस मेसन ने स्नैपशॉट-सक्षम फ़ाइल सिस्टम पर काम करना प्रारंभ किया, जो इस डेटा संरचना का लगभग विशेष रूप से उपयोग करेगा—न केवल मेटाडेटा और फ़ाइल डेटा के लिए, जबकि पुनरावर्ती रूप से पेड़ों के स्थान आवंटन को ट्रैक करने के लिए भी। इसने सभी ट्रैवर्सल और संशोधनों को ही कोड पथ के माध्यम से फ़नल करने की अनुमति दी, जिसके विरुद्ध संपूर्ण फ़ाइल सिस्टम को लाभ पहुंचाने के लिए केवल बार कॉपी ऑन राइट, चेकसमिंग और मिररिंग जैसी सुविधाओं को लागू करने की आवश्यकता थी।<ref name="aurora-1" />


Btrfs को ऐसे पेड़ों की कई परतों के रूप में संरचित किया गया है, सभी ही B-ट्री कार्यान्वयन का उपयोग करते हैं। पेड़ 136-बिट कुंजी द्वारा क्रमबद्ध सामान्य वस्तुओं को संग्रहीत करता है। कुंजी के सबसे महत्वपूर्ण 64 बिट अद्वितीय ऑब्जेक्ट आईडी हैं। मध्य आठ बिट्स आइटम प्रकार फ़ील्ड हैं: इसका उपयोग ट्री लुकअप में आइटम फ़िल्टर के रूप में कोड में हार्डवायर किया गया है। ऑब्जेक्ट्स में कई प्रकार के कई आइटम हो सकते हैं। शेष (कम से कम महत्वपूर्ण) 64 बिट प्रकार-विशिष्ट तरीकों से उपयोग किए जाते हैं। इसलिए, ही वस्तु के लिए आइटम प्रकार के आधार पर समूहीकृत पेड़ में दूसरे के निकट समाप्त होते हैं। कुछ प्रमुख मूल्यों को चुनकर, वस्तुएं उसी प्रकार की वस्तुओं को विशेष क्रम में आगे रख सकती हैं।<ref name="aurora-1" /><ref name="btrfs-wiki-1" />
Btrfs को ऐसे पेड़ों की कई परतों के रूप में संरचित किया गया है, सभी ही B-ट्री कार्यान्वयन का उपयोग करते हैं। पेड़ 136-बिट कुंजी द्वारा क्रमबद्ध सामान्य वस्तुओं को संग्रहीत करता है। कुंजी के सबसे महत्वपूर्ण 64 बिट अद्वितीय ऑब्जेक्ट आईडी हैं। मध्य आठ बिट्स आइटम प्रकार फ़ील्ड हैं: इसका उपयोग ट्री लुकअप में आइटम फ़िल्टर के रूप में कोड में हार्डवायर किया गया है। ऑब्जेक्ट्स में कई प्रकार के कई आइटम हो सकते हैं। शेष (कम से कम महत्वपूर्ण) 64 बिट प्रकार-विशिष्ट तरीकों से उपयोग किए जाते हैं। इसलिए, ही वस्तु के लिए आइटम प्रकार के आधार पर समूहीकृत पेड़ में दूसरे के निकट समाप्त होते हैं। कुछ प्रमुख मूल्यों को चुनकर, वस्तुएं उसी प्रकार की वस्तुओं को विशेष क्रम में आगे रख सकती हैं।<ref name="aurora-1" /><ref name="btrfs-wiki-1" />
Line 231: Line 231:
इंटीरियर ट्री नोड्स केवल की-पॉइंटर जोड़े की फ्लैट लिस्ट हैं, जहां पॉइंटर चाइल्ड नोड का लॉजिकल ब्लॉक नंबर है। लीफ नोड्स में आइटम कीज़ को नोड के सामने पैक किया जाता है और आइटम डेटा को अंत में पैक किया जाता है, दोनों दूसरे की ओर बढ़ रहे हैं जैसे पत्ता भरता है।<ref name="aurora-1" />
इंटीरियर ट्री नोड्स केवल की-पॉइंटर जोड़े की फ्लैट लिस्ट हैं, जहां पॉइंटर चाइल्ड नोड का लॉजिकल ब्लॉक नंबर है। लीफ नोड्स में आइटम कीज़ को नोड के सामने पैक किया जाता है और आइटम डेटा को अंत में पैक किया जाता है, दोनों दूसरे की ओर बढ़ रहे हैं जैसे पत्ता भरता है।<ref name="aurora-1" />
=== फाइल सिस्टम ट्री ===
=== फाइल सिस्टम ट्री ===
प्रत्येक निर्देशिका के भीतर, निर्देशिका प्रविष्टियाँ निर्देशिका आइटम के रूप में दिखाई देती हैं, जिनके महत्वपूर्ण मूल्यों के कम से कम महत्वपूर्ण बिट्स उनके फ़ाइल नाम के चक्रीय अतिरेक जाँच हैश हैं। उनका डेटा स्थान कुंजी है, या उस इनोड आइटम की कुंजी है जो इसे इंगित करता है। निर्देशिका आइटम साथ पथ-से-इनोड लुकअप के लिए सूचकांक के रूप में कार्य कर सकते हैं, लेकिन पुनरावृत्ति के लिए उपयोग नहीं किया जाता है क्योंकि वे उनके हैश द्वारा क्रमबद्ध होते हैं, उन्हें प्रभावी रूप से [[यादृच्छिक क्रमपरिवर्तन]] करते हैं। इसका मतलब यह है कि बड़ी निर्देशिका में फ़ाइलों को खोलने और खोलने वाले उपयोगकर्ता अनुप्रयोग इस प्रकार गैर-आसन्न फ़ाइलों के बीच कई और डिस्क खोज उत्पन्न करेंगे - हैश-ऑर्डर वाली निर्देशिकाओं जैसे ReiserFS, के साथ अन्य फ़ाइल सिस्टम में उल्लेखनीय प्रदर्शन नाली।<ref>{{cite web|url = http://lkml.indiana.edu/hypermail/linux/kernel/0112.0/2019.html|title = Re: Ext2 directory index: ALS paper and benchmarks|work = ReiserFS developers mailing list|first = Hans|last = Reiser|date = 2001-12-07|access-date = 2009-08-28}}</ref> ext3 (Htree-indexes सक्षम के साथ<ref>{{cite web|url = http://oss.oracle.com/~mason/acp/ |first=Chris |last=Mason |title = एसीपी|work = Oracle personal web page|access-date = 2011-11-05}}</ref>) और ext4, जिनमें से सभी में [[टिनी एन्क्रिप्शन एल्गोरिथम]]-हैश फ़ाइल नाम हैं। इससे बचने के लिए, प्रत्येक निर्देशिका प्रविष्टि में निर्देशिका अनुक्रमणिका आइटम होता है, जिसका आइटम का मुख्य मूल्य प्रति-निर्देशिका काउंटर पर सेट होता है जो प्रत्येक नई निर्देशिका प्रविष्टि के साथ बढ़ता है। इन अनुक्रमणिका मदों पर पुनरावृत्ति इस प्रकार प्रविष्टियों को मोटे तौर पर उसी क्रम में लौटाती है जैसा कि डिस्क पर संग्रहीत है।
प्रत्येक निर्देशिका के भीतर, निर्देशिका प्रविष्टियाँ निर्देशिका आइटम के रूप में दिखाई देती हैं, जिनके महत्वपूर्ण मूल्यों के कम से कम महत्वपूर्ण बिट्स उनके फ़ाइल नाम के चक्रीय अतिरेक जाँच हैश हैं। उनका डेटा स्थान कुंजी है, या उस इनोड आइटम की कुंजी है जो इसे इंगित करता है। निर्देशिका आइटम साथ पथ-से-इनोड लुकअप के लिए सूचकांक के रूप में कार्य कर सकते हैं, लेकिन पुनरावृत्ति के लिए उपयोग नहीं किया जाता है क्योंकि वे उनके हैश द्वारा क्रमबद्ध होते हैं, उन्हें प्रभावी रूप से [[यादृच्छिक क्रमपरिवर्तन]] करते हैं। इसका तात्पर्य यह है कि बड़ी निर्देशिका में फ़ाइलों को खोलने और खोलने वाले उपयोगकर्ता अनुप्रयोग इस प्रकार गैर-आसन्न फ़ाइलों के मध्य कई और डिस्क खोज उत्पन्न करेंगे - हैश-ऑर्डर वाली निर्देशिकाओं जैसे ReiserFS, के साथ अन्य फ़ाइल सिस्टम में उल्लेखनीय प्रदर्शन नाली।<ref>{{cite web|url = http://lkml.indiana.edu/hypermail/linux/kernel/0112.0/2019.html|title = Re: Ext2 directory index: ALS paper and benchmarks|work = ReiserFS developers mailing list|first = Hans|last = Reiser|date = 2001-12-07|access-date = 2009-08-28}}</ref> ext3 (Htree-indexes सक्षम के साथ<ref>{{cite web|url = http://oss.oracle.com/~mason/acp/ |first=Chris |last=Mason |title = एसीपी|work = Oracle personal web page|access-date = 2011-11-05}}</ref>) और ext4, जिनमें से सभी में [[टिनी एन्क्रिप्शन एल्गोरिथम]]-हैश फ़ाइल नाम हैं। इससे बचने के लिए, प्रत्येक निर्देशिका प्रविष्टि में निर्देशिका अनुक्रमणिका आइटम होता है, जिसका आइटम का मुख्य मूल्य प्रति-निर्देशिका काउंटर पर सेट होता है जो प्रत्येक नई निर्देशिका प्रविष्टि के साथ बढ़ता है। इन अनुक्रमणिका मदों पर पुनरावृत्ति इस प्रकार प्रविष्टियों को मोटे तौर पर उसी क्रम में लौटाती है जैसा कि डिस्क पर संग्रहीत है।


एकाधिक निर्देशिकाओं में हार्ड लिंक वाली फ़ाइलों में एकाधिक संदर्भ आइटम होते हैं, प्रत्येक मूल निर्देशिका के लिए एक। ही निर्देशिका में कई हार्ड लिंक वाली फ़ाइलें सभी लिंक के फ़ाइलनामों को ही संदर्भ आइटम में पैक करती हैं। यह डिज़ाइन दोष था जिसने समान-निर्देशिका हार्ड लिंक की संख्या को सीमित कर दिया था, हालांकि कई पेड़ ब्लॉक में फिट हो सकते थे। (4 KiB के डिफॉल्ट ब्लॉक आकार, 8 बाइट्स की औसत फ़ाइल नाम लंबाई और 4 बाइट्स के प्रति-फ़ाइल नाम हेडर पर, यह 350 से कम होगा।) कई समान-निर्देशिका हार्ड लिंक का भारी उपयोग करने वाले एप्लिकेशन, जैसे कि Git (सॉफ़्टवेयर), [[Gnus]], [[MAME]] और [[BackupPC]] इस सीमा पर विफल होते देखे गए।<ref name="hard_link_limit" />सीमा को अंततः हटा दिया गया था<ref>{{cite web|title = btrfs: extended inode refs|first = Mark|last = Fasheh|date = 2012-10-09|access-date = 2012-11-07|url = https://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298|archive-url = https://archive.today/20130415062145/http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298|url-status = dead|archive-date = 2013-04-15}}</ref> (और अक्टूबर 2012 तक विलय कर दिया गया है<ref>{{cite web|title = क्रिस मेसन से btrfs अद्यतन प्राप्त करें|first = Linus|last = Torvalds|date = 2012-10-10|access-date = 2012-11-07|url = https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5|archive-url = https://archive.today/20130415043758/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5|url-status = dead|archive-date = 2013-04-15|work = [[kernel.org|git.kernel.org]]}}</ref> लिनक्स 3.7 में लंबित रिलीज़) हार्ड लिंक फ़ाइलनामों को रखने के लिए स्पिलओवर विस्तारित संदर्भ आइटम पेश करके जो अन्यथा फिट नहीं होते हैं।
एकाधिक निर्देशिकाओं में हार्ड लिंक वाली फ़ाइलों में एकाधिक संदर्भ आइटम होते हैं, प्रत्येक मूल निर्देशिका के लिए एक। ही निर्देशिका में कई हार्ड लिंक वाली फ़ाइलें सभी लिंक के फ़ाइलनामों को ही संदर्भ आइटम में पैक करती हैं। यह डिज़ाइन दोष था जिसने समान-निर्देशिका हार्ड लिंक की संख्या को सीमित कर दिया था, हालांकि कई पेड़ ब्लॉक में फिट हो सकते थे। (4 KiB के डिफॉल्ट ब्लॉक आकार, 8 बाइट्स की औसत फ़ाइल नाम लंबाई और 4 बाइट्स के प्रति-फ़ाइल नाम हेडर पर, यह 350 से कम होगा।) कई समान-निर्देशिका हार्ड लिंक का भारी उपयोग करने वाले एप्लिकेशन, जैसे कि Git (सॉफ़्टवेयर), [[Gnus]], [[MAME]] और [[BackupPC]] इस सीमा पर विफल होते देखे गए।<ref name="hard_link_limit" />सीमा को अंततः हटा दिया गया था<ref>{{cite web|title = btrfs: extended inode refs|first = Mark|last = Fasheh|date = 2012-10-09|access-date = 2012-11-07|url = https://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298|archive-url = https://archive.today/20130415062145/http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=f186373fef005cee948a4a39e6a14c2e5f517298|url-status = dead|archive-date = 2013-04-15}}</ref> (और अक्टूबर 2012 तक विलय कर दिया गया है<ref>{{cite web|title = क्रिस मेसन से btrfs अद्यतन प्राप्त करें|first = Linus|last = Torvalds|date = 2012-10-10|access-date = 2012-11-07|url = https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5|archive-url = https://archive.today/20130415043758/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72055425e53540d9d0e59a57ac8c9b8ce77b62d5|url-status = dead|archive-date = 2013-04-15|work = [[kernel.org|git.kernel.org]]}}</ref> लिनक्स 3.7 में लंबित रिलीज़) हार्ड लिंक फ़ाइलनामों को रखने के लिए स्पिलओवर विस्तारित संदर्भ आइटम प्रस्तुत करके जो अन्यथा फिट नहीं होते हैं।


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


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


स्नैपशॉट और क्लोन की गई फ़ाइलें साझा करती हैं। जब इस तरह की बड़ी सीमा का छोटा सा हिस्सा ओवरराइट किया जाता है, तो परिणामी कॉपी-ऑन-राइट तीन नए विस्तार बना सकता है: ओवरराइट किए गए डेटा वाले छोटे से और ओवरराइट के दोनों तरफ असम्बद्ध डेटा वाले दो बड़े। असंशोधित डेटा को फिर से लिखने से बचने के लिए, कॉपी-ऑन-राइट इसके बजाय बुकेंड विस्तार या विस्तार कर सकता है जो मौजूदा विस्तार के टुकड़े हैं। डेटा आइटम की सीमा इसकी ट्रैकिंग की सीमा में ऑफ़सेट शामिल करके इसकी अनुमति देती है: बुकएंड के लिए आइटम गैर-शून्य ऑफ़सेट वाले होते हैं।<ref name="btrfs-wiki-1" />
स्नैपशॉट और क्लोन की गई फ़ाइलें साझा करती हैं। जब इस तरह की बड़ी सीमा का छोटा सा हिस्सा ओवरराइट किया जाता है, तो परिणामी कॉपी-ऑन-राइट तीन नए विस्तार बना सकता है: ओवरराइट किए गए डेटा वाले छोटे से और ओवरराइट के दोनों तरफ असम्बद्ध डेटा वाले दो बड़े। असंशोधित डेटा को फिर से लिखने से बचने के लिए, कॉपी-ऑन-राइट इसके अतिरिक्त बुकेंड विस्तार या विस्तार कर सकता है जो मौजूदा विस्तार के टुकड़े हैं। डेटा आइटम की सीमा इसकी ट्रैकिंग की सीमा में ऑफ़सेट सम्मिलित करके इसकी अनुमति देती है: बुकएंड के लिए आइटम गैर-शून्य ऑफ़सेट वाले होते हैं।<ref name="btrfs-wiki-1" />
=== विस्तार आवंटन पेड़ ===
=== विस्तार आवंटन पेड़ ===
सीमा आवंटन ट्री फाइल सिस्टम के लिए आवंटन मानचित्र के रूप में कार्य करता है। अन्य पेड़ों के विपरीत, इस पेड़ की वस्तुओं में ऑब्जेक्ट आईडी नहीं होते हैं। वे अंतरिक्ष के क्षेत्रों का प्रतिनिधित्व करते हैं: उनके प्रमुख मूल्यों में शुरुआती ऑफसेट और उनके द्वारा प्रतिनिधित्व किए जाने वाले क्षेत्रों की लंबाई होती है।
सीमा आवंटन ट्री फाइल सिस्टम के लिए आवंटन मानचित्र के रूप में कार्य करता है। अन्य पेड़ों के विपरीत, इस पेड़ की वस्तुओं में ऑब्जेक्ट आईडी नहीं होते हैं। वे अंतरिक्ष के क्षेत्रों का प्रतिनिधित्व करते हैं: उनके प्रमुख मूल्यों में प्रारंभिक ऑफसेट और उनके द्वारा प्रतिनिधित्व किए जाने वाले क्षेत्रों की लंबाई होती है।


फ़ाइल सिस्टम अपने आवंटित स्थान को ब्लॉक समूहों में विभाजित करता है जो चर-आकार के आवंटन क्षेत्र होते हैं जो मेटाडेटा विस्तार (ट्री नोड्स) और डेटा विस्तार (फ़ाइल सामग्री) के बीच वैकल्पिक होते हैं। मेटाडेटा ब्लॉक समूहों के लिए डेटा का डिफ़ॉल्ट अनुपात 1:2 है। उनका उद्देश्य संबंधित फाइलों को साथ आवंटित करने और समूहों के बीच मुक्त स्थान छोड़कर विखंडन का विरोध करने के लिए ओर्लोव ब्लॉक आवंटक की अवधारणाओं का उपयोग करना है। (Ext3 ब्लॉक समूह, हालांकि, फ़ाइल सिस्टम के आकार से गणना किए गए निश्चित स्थान हैं, जबकि Btrfs में वे गतिशील हैं और आवश्यकतानुसार बनाए गए हैं।) प्रत्येक ब्लॉक समूह ब्लॉक समूह आइटम के साथ जुड़ा हुआ है। फ़ाइल सिस्टम ट्री में इनोड आइटम्स में उनके वर्तमान ब्लॉक समूह का संदर्भ शामिल है।<ref name="btrfs-wiki-1" />
फ़ाइल सिस्टम अपने आवंटित स्थान को ब्लॉक समूहों में विभाजित करता है जो चर-आकार के आवंटन क्षेत्र होते हैं जो मेटाडेटा विस्तार (ट्री नोड्स) और डेटा विस्तार (फ़ाइल सामग्री) के मध्य वैकल्पिक होते हैं। मेटाडेटा ब्लॉक समूहों के लिए डेटा का डिफ़ॉल्ट अनुपात 1:2 है। उनका उद्देश्य संबंधित फाइलों को साथ आवंटित करने और समूहों के मध्य मुक्त स्थान छोड़कर विखंडन का विरोध करने के लिए ओर्लोव ब्लॉक आवंटक की अवधारणाओं का उपयोग करना है। (Ext3 ब्लॉक समूह, हालांकि, फ़ाइल सिस्टम के आकार से गणना किए गए निश्चित स्थान हैं, जबकि Btrfs में वे गतिशील हैं और आवश्यकतानुसार बनाए गए हैं।) प्रत्येक ब्लॉक समूह ब्लॉक समूह आइटम के साथ जुड़ा हुआ है। फ़ाइल सिस्टम ट्री में इनोड आइटम्स में उनके वर्तमान ब्लॉक समूह का संदर्भ सम्मिलित है।<ref name="btrfs-wiki-1" />


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


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


सिद्धांत रूप में, सीमा आवंटन वृक्ष पारंपरिक [[फ्री-स्पेस बिटमैप]] को अनावश्यक बनाता है क्योंकि सीमा आवंटन पेड़ [[बाइनरी स्पेस विभाजन]] के बी-ट्री संस्करण के रूप में कार्य करता है। व्यवहार में, हालांकि, [[पृष्ठ (कंप्यूटिंग)]]-आकार के बिटमैप्स के इन-मेमोरी लाल-काले पेड़ का उपयोग आवंटन को गति देने के लिए किया जाता है। ये बिटमैप्स डिस्क पर बने रहते हैं (लिनक्स 2.6.37 में शुरू होकर, <code>space_cache</code> माउंट विकल्प<ref>{{cite web | title = Btrfs स्पेस कैश विकल्प के बेंचमार्क|access-date = 2012-11-16 |date = 2010-12-24 |first = Michael |last = Larabel |url = https://www.phoronix.com/scan.php?page=article&item=btrfs_space_cache&num=1 |publisher = [[Phoronix]] }}</ref>) विशेष विस्तार के रूप में जो चेकसमिंग और कॉपी-ऑन-राइट से छूट प्राप्त हैं।
सिद्धांत रूप में, सीमा आवंटन वृक्ष पारंपरिक [[फ्री-स्पेस बिटमैप]] को अनावश्यक बनाता है क्योंकि सीमा आवंटन पेड़ [[बाइनरी स्पेस विभाजन]] के बी-ट्री संस्करण के रूप में कार्य करता है। व्यवहार में, हालांकि, [[पृष्ठ (कंप्यूटिंग)]]-आकार के बिटमैप्स के इन-मेमोरी लाल-काले पेड़ का उपयोग आवंटन को गति देने के लिए किया जाता है। ये बिटमैप्स डिस्क पर बने रहते हैं (लिनक्स 2.6.37 में प्रारंभ होकर, <code>space_cache</code> माउंट विकल्प<ref>{{cite web | title = Btrfs स्पेस कैश विकल्प के बेंचमार्क|access-date = 2012-11-16 |date = 2010-12-24 |first = Michael |last = Larabel |url = https://www.phoronix.com/scan.php?page=article&item=btrfs_space_cache&num=1 |publisher = [[Phoronix]] }}</ref>) विशेष विस्तार के रूप में जो चेकसमिंग और कॉपी-ऑन-राइट से छूट प्राप्त हैं।


=== चेकसम ट्री और स्क्रबिंग ===
=== चेकसम ट्री और स्क्रबिंग ===
Line 262: Line 262:
}}</ref>
}}</ref>
आवंटित ब्लॉकों के प्रति सन्निहित रन में चेकसम आइटम है, जिसमें आइटम डेटा में एंड-टू-एंड पैक किए गए प्रति-ब्लॉक चेकसम हैं। यदि फिट होने से अधिक चेकसम हैं, तो वे नए पत्ते में दूसरे चेकसम आइटम में फैल जाते हैं। यदि फ़ाइल सिस्टम किसी ब्लॉक को पढ़ते समय चेकसम बेमेल का पता लगाता है, तो वह पहले इस ब्लॉक की अच्छी प्रति किसी अन्य डिवाइस से प्राप्त करने (या बनाने) का प्रयास करता है।{{spaced ndash}} यदि आंतरिक मिररिंग या RAID तकनीकें उपयोग में हैं।<ref name="oracle-advanced-btrfs" /><ref>{{cite web |last=Salter |first=Jim |title=Bitrot and Atomic COWs: Inside "Next-Gen" Filesystems |url=https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ |website=Ars Technica |access-date=15 January 2014 |date=15 January 2014}}</ref>
आवंटित ब्लॉकों के प्रति सन्निहित रन में चेकसम आइटम है, जिसमें आइटम डेटा में एंड-टू-एंड पैक किए गए प्रति-ब्लॉक चेकसम हैं। यदि फिट होने से अधिक चेकसम हैं, तो वे नए पत्ते में दूसरे चेकसम आइटम में फैल जाते हैं। यदि फ़ाइल सिस्टम किसी ब्लॉक को पढ़ते समय चेकसम बेमेल का पता लगाता है, तो वह पहले इस ब्लॉक की अच्छी प्रति किसी अन्य डिवाइस से प्राप्त करने (या बनाने) का प्रयास करता है।{{spaced ndash}} यदि आंतरिक मिररिंग या RAID तकनीकें उपयोग में हैं।<ref name="oracle-advanced-btrfs" /><ref>{{cite web |last=Salter |first=Jim |title=Bitrot and Atomic COWs: Inside "Next-Gen" Filesystems |url=https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ |website=Ars Technica |access-date=15 January 2014 |date=15 January 2014}}</ref>
Btrfs फ़ाइल सिस्टम स्क्रब जॉब को ट्रिगर करके पूरे फ़ाइल सिस्टम की ऑनलाइन जाँच शुरू कर सकता है जो बैकग्राउंड में किया जाता है। स्क्रब जॉब पूरे फाइल सिस्टम को अखंडता के लिए स्कैन करता है और स्वचालित रूप से रास्ते में मिलने वाले किसी भी खराब ब्लॉक की रिपोर्ट करने और मरम्मत करने का प्रयास करता है।<ref name="oracle-advanced-btrfs" /><ref>{{cite web
Btrfs फ़ाइल सिस्टम स्क्रब जॉब को ट्रिगर करके पूरे फ़ाइल सिस्टम की ऑनलाइन जाँच प्रारंभ कर सकता है जो बैकग्राउंड में किया जाता है। स्क्रब जॉब पूरे फाइल सिस्टम को अखंडता के लिए स्कैन करता है और स्वचालित रूप से रास्ते में मिलने वाले किसी भी खराब ब्लॉक की रिपोर्ट करने और मरम्मत करने का प्रयास करता है।<ref name="oracle-advanced-btrfs" /><ref>{{cite web
  | url        = https://blogs.oracle.com/wim/entry/btrfs_scrub_go_fix_corruptions
  | url        = https://blogs.oracle.com/wim/entry/btrfs_scrub_go_fix_corruptions
  | title      = Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!
  | title      = Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!
Line 287: Line 287:


===पुनर्स्थापन पेड़===
===पुनर्स्थापन पेड़===
डीफ़्रैग्मेन्टेशन, सिकुडऩ, और पुनर्संतुलन संचालन के लिए विस्तार को स्थानांतरित करने की आवश्यकता होती है। हालांकि, रिलोकेटिंग सीमा की साधारण कॉपी-ऑन-राइट करने से स्नैपशॉट के बीच साझाकरण टूट जाएगा और डिस्क स्थान का उपभोग होगा। साझाकरण को संरक्षित करने के लिए, अपडेट-एंड-स्वैप एल्गोरिथम का उपयोग किया जाता है, जिसमें विशेष रीलोकेशन ट्री प्रभावित मेटाडेटा के लिए स्क्रैच स्पेस के रूप में कार्य करता है। स्थानांतरित की जाने वाली सीमा को पहले उसके गंतव्य पर कॉपी किया जाता है। फिर, प्रभावित सबवोल्यूम के फाइल सिस्टम ट्री के माध्यम से ऊपर की ओर बैकरेफरेंस का अनुसरण करके, पुराने विस्तार की ओर इशारा करते हुए मेटाडेटा को नए बिंदु पर इंगित करने के लिए उत्तरोत्तर अद्यतन किया जाता है; किसी भी नए अपडेट किए गए आइटम को रीलोकेशन ट्री में स्टोर किया जाता है। बार अपडेट पूरा हो जाने के बाद, रिलोकेशन ट्री में आइटम्स को प्रभावित सबवोल्यूम में उनके समकक्षों के साथ स्वैप किया जाता है, और रिलोकेशन ट्री को छोड़ दिया जाता है।<ref>{{citation|title = BTRFS: The Linux B-tree Filesystem|date = 2012-07-09|first1 = Chris|last1 = Mason|first2 = Ohad|last2 = Rodeh|first3 = Josef|last3 = Bacik|publisher = [[IBM Research]]|url = http://domino.watson.ibm.com/library/CyberDig.nsf/papers/6E1C5B6A1B6EDD9885257A38006B6130/$File/rj10501.pdf|access-date = 2012-11-12}}</ref>
डीफ़्रैग्मेन्टेशन, सिकुडऩ, और पुनर्संतुलन संचालन के लिए विस्तार को स्थानांतरित करने की आवश्यकता होती है। हालांकि, रिलोकेटिंग सीमा की साधारण कॉपी-ऑन-राइट करने से स्नैपशॉट के मध्य साझाकरण टूट जाएगा और डिस्क स्थान का उपभोग होगा। साझाकरण को संरक्षित करने के लिए, अपडेट-एंड-स्वैप एल्गोरिथम का उपयोग किया जाता है, जिसमें विशेष रीलोकेशन ट्री प्रभावित मेटाडेटा के लिए स्क्रैच स्पेस के रूप में कार्य करता है। स्थानांतरित की जाने वाली सीमा को पहले उसके गंतव्य पर कॉपी किया जाता है। फिर, प्रभावित सबवोल्यूम के फाइल सिस्टम ट्री के माध्यम से ऊपर की ओर बैकरेफरेंस का अनुसरण करके, पुराने विस्तार की ओर इशारा करते हुए मेटाडेटा को नए बिंदु पर इंगित करने के लिए उत्तरोत्तर अद्यतन किया जाता है; किसी भी नए अपडेट किए गए आइटम को रीलोकेशन ट्री में स्टोर किया जाता है। बार अपडेट पूरा हो जाने के बाद, रिलोकेशन ट्री में आइटम्स को प्रभावित सबवोल्यूम में उनके समकक्षों के साथ स्वैप किया जाता है, और रिलोकेशन ट्री को छोड़ दिया जाता है।<ref>{{citation|title = BTRFS: The Linux B-tree Filesystem|date = 2012-07-09|first1 = Chris|last1 = Mason|first2 = Ohad|last2 = Rodeh|first3 = Josef|last3 = Bacik|publisher = [[IBM Research]]|url = http://domino.watson.ibm.com/library/CyberDig.nsf/papers/6E1C5B6A1B6EDD9885257A38006B6130/$File/rj10501.pdf|access-date = 2012-11-12}}</ref>
=== सुपरब्लॉक ===
=== सुपरब्लॉक ===
सभी फाइल सिस्टम के पेड़- खुद चंक ट्री सहित- चंक्स में संग्रहीत होते हैं, जिससे फाइल सिस्टम को माउंट (कंप्यूटिंग) करते समय संभावित [[बूटस्ट्रैपिंग]] समस्या पैदा होती है। माउंट में [[बूटस्ट्रैपिंग (कंप्यूटिंग)]] करने के लिए, ब्लॉक डिवाइस में चंक और रूट ट्री से संबंधित चंक्स के भौतिक पतों की सूची संग्रहीत की जाती है।<ref>{{cite web | url = http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support |url-status= dead |first=Chris |last=Mason | website=Btrfs wiki | access-date = 5 November 2011 | date = 30 April 2008 |title = मल्टीपल डिवाइस सपोर्ट| archive-date= 20 July 2011 |archive-url= https://web.archive.org/web/20110720220543/https://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support }}</ref>
सभी फाइल सिस्टम के पेड़- खुद चंक ट्री सहित- चंक्स में संग्रहीत होते हैं, जिससे फाइल सिस्टम को माउंट (कंप्यूटिंग) करते समय संभावित [[बूटस्ट्रैपिंग]] समस्या पैदा होती है। माउंट में [[बूटस्ट्रैपिंग (कंप्यूटिंग)]] करने के लिए, ब्लॉक डिवाइस में चंक और रूट ट्री से संबंधित चंक्स के भौतिक पतों की सूची संग्रहीत की जाती है।<ref>{{cite web | url = http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support |url-status= dead |first=Chris |last=Mason | website=Btrfs wiki | access-date = 5 November 2011 | date = 30 April 2008 |title = मल्टीपल डिवाइस सपोर्ट| archive-date= 20 July 2011 |archive-url= https://web.archive.org/web/20110720220543/https://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support }}</ref>
सुपरब्लॉक दर्पणों को निश्चित स्थानों पर रखा जाता है:<ref>{{cite mailing list|url = http://kerneltrap.org/mailarchive/linux-btrfs/2010/4/20/6884623|title = Re: Restoring BTRFS partition|mailing-list = linux-btrfs|date = 2010-04-20|last = Bartell|first = Sean}}</ref> प्रत्येक ब्लॉक डिवाइस में 64 KiB, 64 MiB, 256 GiB और 1 PiB पर अतिरिक्त प्रतियों के साथ। जब सुपरब्लॉक मिरर को अपडेट किया जाता है, तो इसका जनरेशन नंबर बढ़ जाता है। आरोह समय पर, उच्चतम पीढ़ी संख्या वाली प्रतिलिपि का उपयोग किया जाता है। सॉलिड-स्टेट ड्राइव मोड को छोड़कर सभी सुपरब्लॉक दर्पणों को अग्रानुक्रम में अपडेट किया जाता है, जो कुछ [[ लेवलिंग पहनें |लेवलिंग पहनें]] प्रदान करने के लिए दर्पणों के बीच अपडेट को वैकल्पिक करता है।
सुपरब्लॉक दर्पणों को निश्चित स्थानों पर रखा जाता है:<ref>{{cite mailing list|url = http://kerneltrap.org/mailarchive/linux-btrfs/2010/4/20/6884623|title = Re: Restoring BTRFS partition|mailing-list = linux-btrfs|date = 2010-04-20|last = Bartell|first = Sean}}</ref> प्रत्येक ब्लॉक डिवाइस में 64 KiB, 64 MiB, 256 GiB और 1 PiB पर अतिरिक्त प्रतियों के साथ। जब सुपरब्लॉक मिरर को अपडेट किया जाता है, तो इसका जनरेशन नंबर बढ़ जाता है। आरोह समय पर, उच्चतम पीढ़ी संख्या वाली प्रतिलिपि का उपयोग किया जाता है। सॉलिड-स्टेट ड्राइव मोड को छोड़कर सभी सुपरब्लॉक दर्पणों को अग्रानुक्रम में अपडेट किया जाता है, जो कुछ [[ लेवलिंग पहनें |लेवलिंग पहनें]] प्रदान करने के लिए दर्पणों के मध्य अपडेट को वैकल्पिक करता है।


== वाणिज्यिक समर्थन ==
== वाणिज्यिक समर्थन ==
Line 299: Line 299:
* [[Synology]] DiskStation Manager (DSM) संस्करण 6.0 से<ref>{{Cite web |url=https://global.download.synology.com/download/Document/Software/WhitePaper/Package/CloudStation/All/enu/Synology_Cloud_Station_White_Paper-Based_on_DSM_6.0.pdf |title=क्लाउड स्टेशन श्वेत पत्र|website=Synology.com |publisher=[[Synology]] |access-date=2021-04-02 |quote=Starting from DSM 6.0, data volumes can be formatted as Btrfs |page=11 |archive-date=11 November 2020 |archive-url=https://web.archive.org/web/20201111190843/https://global.download.synology.com/download/Document/Software/WhitePaper/Package/CloudStation/All/enu/Synology_Cloud_Station_White_Paper-Based_on_DSM_6.0.pdf |url-status=dead }}</ref>
* [[Synology]] DiskStation Manager (DSM) संस्करण 6.0 से<ref>{{Cite web |url=https://global.download.synology.com/download/Document/Software/WhitePaper/Package/CloudStation/All/enu/Synology_Cloud_Station_White_Paper-Based_on_DSM_6.0.pdf |title=क्लाउड स्टेशन श्वेत पत्र|website=Synology.com |publisher=[[Synology]] |access-date=2021-04-02 |quote=Starting from DSM 6.0, data volumes can be formatted as Btrfs |page=11 |archive-date=11 November 2020 |archive-url=https://web.archive.org/web/20201111190843/https://global.download.synology.com/download/Document/Software/WhitePaper/Package/CloudStation/All/enu/Synology_Cloud_Station_White_Paper-Based_on_DSM_6.0.pdf |url-status=dead }}</ref>
=== अब समर्थित नहीं ===
=== अब समर्थित नहीं ===
* Btrfs को Red Hat Enterprise Linux 6 और 7 में तकनीकी पूर्वावलोकन के रूप में शामिल किया गया था;<ref name="RHEL 6"/><ref name="RHEL 7"/>इसे 2018 में Red Hat Enterprise Linux में हटा दिया गया था।<ref name="RHEL 8"/><ref>{{Cite web |url=https://news.ycombinator.com/item?id=14907771|title=Btrfs has been deprecated in RHEL &#124; Hacker News |website=News.YCombinator.com }}</ref><ref>{{Cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again|title=ऐसा प्रतीत होता है कि Red Hat अपनी Btrfs आशाओं का परित्याग कर रहा है - Phoronix|website=Phoronix.com}}</ref>
* Btrfs को Red Hat Enterprise Linux 6 और 7 में तकनीकी पूर्वावलोकन के रूप में सम्मिलित किया गया था;<ref name="RHEL 6"/><ref name="RHEL 7"/>इसे 2018 में Red Hat Enterprise Linux में हटा दिया गया था।<ref name="RHEL 8"/><ref>{{Cite web |url=https://news.ycombinator.com/item?id=14907771|title=Btrfs has been deprecated in RHEL &#124; Hacker News |website=News.YCombinator.com }}</ref><ref>{{Cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again|title=ऐसा प्रतीत होता है कि Red Hat अपनी Btrfs आशाओं का परित्याग कर रहा है - Phoronix|website=Phoronix.com}}</ref>
* Btrfs को 2013 के आसपास [[नेटगियर रेडीएनएएस आर्म-आधारित 1xx और इंटेल-आधारित 3xx]] में mdadm-raid सरणियों पर स्तरित किया गया था (शायद अभी भी अस्थिर btrfs-raid कार्यात्मकताओं से बचने के लिए btrfs चेकसम और स्नैपशॉट का फायदा उठाने के लिए)। डेबियन जेसी आधारित OS6 के अपडेट अभी भी 2022 के आसपास पेश किए गए थे (शायद अभी भी समर्थित माना जाता है?)।
* Btrfs को 2013 के आसपास [[नेटगियर रेडीएनएएस आर्म-आधारित 1xx और इंटेल-आधारित 3xx]] में mdadm-raid सरणियों पर स्तरित किया गया था (शायद अभी भी अस्थिर btrfs-raid कार्यात्मकताओं से बचने के लिए btrfs चेकसम और स्नैपशॉट का फायदा उठाने के लिए)। डेबियन जेसी आधारित OS6 के अपडेट अभी भी 2022 के आसपास प्रस्तुत किए गए थे (शायद अभी भी समर्थित माना जाता है?)।


== यह भी देखें ==
== यह भी देखें ==

Revision as of 19:35, 15 June 2023

Btrfs
Developer(s)SUSE, Meta, Western Digital, Oracle Corporation, Fujitsu, Fusion-io, Intel, The Linux Foundation, Red Hat, and Strato AG[1]
Full nameB-tree file system
IntroducedLinux kernel 2.6.29, March 2009; 15 years ago (2009-03)
Structures
Directory contentsB-tree
File allocationExtents
Bad blocksNone recorded
Limits
Max. volume size16 EiB[2][lower-alpha 1]
Max. file size16 EiB[2][lower-alpha 1]
Max. number of files264[lower-alpha 2][3]
Max. filename length255 ASCII characters (fewer for multibyte character encodings such as Unicode)
Allowed characters in filenamesAll except '/' and NUL ('\0')
Features
Dates recordedCreation (otime),[4] modification (mtime), attribute modification (ctime), and access (atime)
Date range64-bit signed int offset from 1970-01-01T00:00:00Z[5]
Date resolutionNanosecond
AttributesPOSIX and extended attributes
File system permissionsUnix permissions, POSIX ACLs
Transparent compressionYes (zlib, LZO[6] and (since 4.14) ZSTD[7])
Transparent encryptionPlanned[8]
Data deduplicationYes[9]
Copy-on-writeYes
Other
Supported operating systemsLinux, ReactOS[10]

बीटीआरएफएस (उत्तम एफ एस के रूप में उच्चारण किया जाता है,[8] बटर एफ एस,[11][12] बी-ट्री एफ एस ,[12] या बस इसे वर्तनी द्वारा) कंप्यूटर स्टोरेज प्रारूप है जो कॉपी-ऑन-राइट कंप्यूटर स्टोरेज में कॉपी-ऑन-राइट (COW) सिद्धांत के आधार पर फाइल सिस्टम को तार्किक मात्रा प्रबंधन के साथ जोड़ता है (भ्रमित नहीं होना चाहिए) लिनक्स का लॉजिकल वॉल्यूम मैनेजर (लिनक्स)), साथ विकसित हुआ। इसे प्रारंभ में लिनक्स में उपयोग के लिए 2007 में Oracle Corporation में डिज़ाइन किया गया था, और नवंबर 2013 से, फ़ाइल सिस्टम के ऑन-डिस्क प्रारूप को Linux कर्नेल में स्थिर घोषित किया गया है।[13] Btrfs का उद्देश्य Linux फ़ाइल सिस्टम में फैले पूल (कंप्यूटर विज्ञान), स्नैपशॉट (कंप्यूटर भंडारण) , अंततः, और इंटीग्रल मल्टी-डिवाइस की कमी को दूर करना है।[8]Btrfs के प्रमुख लेखक क्रिस मेसन ने कहा कि इसका लक्ष्य उपलब्ध होने वाले स्टोरेज के लिए [लिनक्स] स्केल देना था। स्केलिंग केवल स्टोरेज को संबोधित करने के बारे में नहीं है, जबकि इसका तात्पर्य यह भी है कि इसे साफ इंटरफ़ेस के साथ प्रशासित और प्रबंधित करने में सक्षम होना चाहिए जो लोगों को यह देखने देता है कि क्या उपयोग किया जा रहा है और इसे और अधिक विश्वसनीय बनाता है।[14]

इतिहास

Btrfs फ़ाइल सिस्टम के उपयोग की जानकारी का स्क्रीनशॉट

Btrfs की मुख्य डेटा संरचना‍—‌कॉपी-ऑन-राइट बी-वृक्ष ‍—‌मूल रूप से IBM के शोधकर्ता ओहद रोदेह द्वारा USENIX 2007 में प्रस्तुति में प्रस्तावित किया गया था।[15]क्रिस मेसन, उस समय SUSE लाइनेक्स के लिए ReiserFS पर काम कर रहे इंजीनियर, उस वर्ष बाद में Oracle में सम्मिलित हो गए और इन B-ट्रीज़ पर आधारित नई फाइल सिस्टम पर काम करना प्रारंभ किया।[16]

2008 में, ext3 और ext4 फ़ाइल सिस्टम के प्रमुख विकासकर्ता थिओडोर त्सो ने कहा कि हालांकि ext4 में उन्नत विशेषताएं हैं, यह कोई बड़ी प्रगति नहीं है; यह पुरानी तकनीक का उपयोग करता है और स्टॉप-गैप है। Ts'o ने कहा कि Btrfs बेहतर दिशा है क्योंकि यह मापनीयता, विश्वसनीयता और प्रबंधन में आसानी में सुधार प्रदान करता है।[17] Btrfs के पास भी वही डिज़ाइन विचार हैं जो ReiserFS/Reiser4 के पास थे।[18] Btrfs 1.0, अंतिम रूप से ऑन-डिस्क प्रारूप के साथ, मूल रूप से 2008 के अंत में रिलीज़ के लिए निर्धारित किया गया था,[19] और अंततः 2009 में लिनक्स कर्नेल मेनलाइन में स्वीकार कर लिया गया।[20] कई Linux वितरणों ने Btrfs को संस्थापन के दौरान रूट फाइल सिस्टम के प्रायोगिक विकल्प के रूप में प्रस्तुत करना प्रारंभ किया।[21][22][23] जुलाई 2011 में, Btrfs स्वचालित defragmentation और डेटा स्क्रबिंग सुविधाओं को Linux कर्नेल मेनलाइन के संस्करण 3.0 में मिला दिया गया था।[24]Oracle में मेसन के अतिरिक्त, Fujitsu में Miao Xie ने प्रदर्शन सुधार में योगदान दिया।[25] जून 2012 में, क्रिस मेसन ने फ्यूजन-कब के लिए ओरेकल छोड़ दिया, जिसे उन्होंने साल बाद जोसेफ बेसिक के साथ फेसबुक में सम्मिलित होने के लिए छोड़ दिया। दोनों कंपनियों में रहते हुए, मेसन ने Btrfs पर अपना काम जारी रखा।[26][16]

2012 में, दो Linux वितरणों ने Btrfs को प्रयोगात्मक से उत्पादन या समर्थित स्थिति में स्थानांतरित कर दिया: मार्च में Oracle Linux,[27] इसके बाद अगस्त में एसयूएसई लिनक्स एंटरप्राइज आया।[28] 2015 में, Btrfs को SUSE Linux Enterprise Server (SLE) 12 के लिए डिफ़ॉल्ट फ़ाइल सिस्टम के रूप में अपनाया गया था।[29] अगस्त 2017 में, Red Hat ने Red Hat Enterprise Linux (RHEL) 7.4 के लिए रिलीज़ नोट्स में घोषणा की कि वह अब Btrfs को पूरी तरह से समर्थित सुविधा में स्थानांतरित करने की योजना नहीं बना रहा है (इसे RHEL 6 बीटा के बाद से तकनीकी पूर्वावलोकन के रूप में सम्मिलित किया गया है) यह देखते हुए कि यह होगा RHEL 7 रिलीज़ सीरीज़ में उपलब्ध रहें।[30] Btrfs को मई 2019 में RHEL 8 से हटा दिया गया था।[31] RHEL RHEL 6 में ext4 से RHEL 7 में XFS में चला गया।[32] 2020 में, Btrfs को डेस्कटॉप वेरिएंट के लिए Fedora Linux 33 के लिए डिफ़ॉल्ट फ़ाइल सिस्टम के रूप में चुना गया था।[33]

विशेषताएं

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

कार्यान्वित

Linux कर्नेल के संस्करण 5.0 के अनुसार, Btrfs निम्नलिखित विशेषताओं को लागू करता है:[34][35]

  • कॉपी-ऑन-राइट की प्रकृति के कारण कुछ विन्यासों में अधिकतर स्व-उपचार
  • ऑनलाइन डीफ़्रेग्मेंटेशन और ऑटोडिफ़्रेग माउंट विकल्प[24]* ऑनलाइन मात्रा में वृद्धि और सिकुड़न
  • ऑनलाइन ब्लॉक डिवाइस को जोड़ना और हटाना
  • ऑनलाइन संतुलन (लोड को संतुलित करने के लिए ब्लॉक उपकरणों के मध्य वस्तुओं की आवाजाही)
  • ऑफलाइन एफएसके[36]
  • त्रुटियों को खोजने और अनावश्यक प्रतियों वाली फ़ाइलों के लिए उन्हें स्वचालित रूप से ठीक करने के लिए ऑनलाइन डेटा स्क्रबिंग
  • RAID 0, RAID 1 और RAID 10[37]
  • सबवॉल्यूम्स (प्रत्येक डिस्क विभाजन के भीतर या अधिक अलग से माउंट करने योग्य रूट निर्देशिका)
  • zlib, Lempel-Ziv-Oberhumer के माध्यम से पारदर्शी डेटा संपीड़न[6]और (4.14 से) Zमानक,[7]फ़ाइल या मात्रा प्रति विन्यास योग्य[38][39]
  • परमाणु लिखने योग्य (कॉपी-ऑन-राइट के माध्यम से) या केवल पढ़ने के लिए[40] उपखंडों का स्नैपशॉट (कंप्यूटर भंडारण)।
  • फाइल क्लोनिंग (रीफ्लिंक, कॉपी-ऑन-राइट) cp --reflink <source file> <destination file> के जरिए[41]
  • डेटा और मेटाडेटा पर चेकसम (CRC-32C[42]). 5.5 से नए हैश फ़ंक्शन लागू किए गए हैं:[43] xxHash, SHA256, BLAKE (हैश फंक्शन)।
  • ext3/4 से Btrfs (रोलबैक के साथ) में इन-प्लेस रूपांतरण। यह सुविधा btrfs-progs संस्करण 4.0 के आसपास वापस आ गई, 4.6 में खरोंच से फिर से लिखी गई।[44]
  • रीड-ओनली स्टोरेज की संघ पर्वत िंग, जिसे फाइल सिस्टम सीडिंग के रूप में जाना जाता है (रीड-ओनली स्टोरेज को लिखने योग्य Btrfs के लिए कॉपी-ऑन-राइट बैकिंग के रूप में उपयोग किया जाता है)[45]
  • ब्लॉक डिस्कार्ड (कुछ हार्डवेयर वर्चुअलाइजेशन सेटअप पर स्थान को पुनः प्राप्त करता है और ट्रिम (कंप्यूटिंग) के साथ ठोस राज्य ड्राइव पर समतलन पुराना होना में सुधार करता है)
  • भेजें/प्राप्त करें (बाइनरी स्ट्रीम में स्नैपशॉट के मध्य अंतर सहेजना)[46]* वृध्दिशील बैकअप[47]
  • आउट-ऑफ-बैंड डेटा डुप्लिकेशन (यूजरस्पेस टूल्स की आवश्यकता है)[9]* फ़ाइल की अदला - बदली करें ों और स्वैप विभाजन को संभालने की क्षमता

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

नियोजित लेकिन अभी तक लागू नहीं

  • इन-बैंड डेटा डुप्लिकेशन[34]* ऑनलाइन एफएसके[52]* RAID 5 और RAID 6 की विश्वसनीयता को पार करते हुए छह समता उपकरणों के साथ RAID[53]
  • वस्तु (कंप्यूटर विज्ञान)-स्तर RAID 0, RAID 1, और RAID 10
  • कूटलेखन[8][54][55]* लगातार पढ़ने और लिखने का कैश (ZFS#Caching Mechanism|L2ARC + ZIL, dm-cache, आदि)

2009 में, Btrfs से सन माइक्रोसिस्टम्स द्वारा विकसित Oracle ZFS के तुलनीय फीचर सेट की प्रस्तुतकश करने की उम्मीद थी।[56]2009 में Oracle द्वारा Sun के अधिग्रहण के बाद, मेसन और Oracle ने Btrfs के विकास को जारी रखने का निर्णय लिया।[57]

क्लोनिंग

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

क्लोनिंग को कठिन कड़ियाँ के साथ भ्रमित नहीं होना चाहिए, जो निर्देशिका प्रविष्टियाँ हैं जो ही फ़ाइल के साथ कई फ़ाइल नामों को जोड़ती हैं। जबकि हार्ड लिंक को ही फ़ाइल के लिए अलग-अलग नामों से लिया जा सकता है, Btrfs में क्लोनिंग स्वतंत्र फ़ाइलें प्रदान करती है जो प्रारंभ में अपने सभी डिस्क ब्लॉक साझा करती हैं।[61][62] इस Btrfs विशेषता के लिए समर्थन कोरुटिल्स के संस्करण 7.5 में --reflink के लिए विकल्प cp आज्ञा।[63][64] डेटा क्लोनिंग के अतिरिक्त (FICLONE), Btrfs द्वारा आउट-ऑफ़-बैंड डुप्लीकेशन का भी समर्थन करता है FIDEDUPERANGE. यह कार्यक्षमता दो फ़ाइलों को (आंशिक रूप से भी) समान डेटा के साथ भंडारण साझा करने की अनुमति देती है।[65][9]

उपखंड और स्नैपशॉट

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

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

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

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

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

Btrfs की कॉपी-ऑन-राइट (CoW) प्रकृति का तात्पर्य है कि स्नैपशॉट जल्दी बन जाते हैं, जबकि शुरुआत में बहुत कम डिस्क स्थान लेते हैं। चूंकि स्नैपशॉट सबवोल्यूम है, नेस्टेड स्नैपशॉट बनाना भी संभव है। सबवोल्यूम का स्नैपशॉट लेना पुनरावर्ती प्रक्रिया नहीं है; इस प्रकार, यदि सबवोल्यूम का स्नैपशॉट बनाया जाता है, तो प्रत्येक सबवॉल्यूम या स्नैपशॉट जिसमें सबवोल्यूम पहले से ही सम्मिलित है, स्नैपशॉट के अंदर उसी नाम की खाली निर्देशिका में मैप किया जाता है।[66][67]

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

Btrfs में सबवॉल्यूम पारंपरिक लॉजिकल वॉल्यूम मैनेजर (LVM) लॉजिकल वॉल्यूम से काफी अलग है। LVM के साथ, लॉजिकल वॉल्यूम अलग ब्लॉक डिवाइस है, जबकि Btrfs सबवोल्यूम नहीं है और इसे इस तरह से ट्रीट या इस्तेमाल नहीं किया जा सकता है।[66]btrfs के dd या LVM स्नैपशॉट बनाने से डेटा हानि होती है यदि या तो मूल या प्रतिलिपि माउंट की जाती है जबकि दोनों ही कंप्यूटर पर हैं।[68]

भेजें–प्राप्त करें

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

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

कोटा समूह

Btrfs कोटा समूहों का उदाहरण

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

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

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

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

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

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

ReiserFS से इन-प्लेस रूपांतरण सितंबर 2017 में कर्नेल 4.13 के साथ प्रस्तुत किया गया था।[71]

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

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

एन्क्रिप्शन

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

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

जांच और वसूली

यूनिक्स सिस्टम परंपरागत रूप से फाइल सिस्टम की जांच और मरम्मत के लिए fsck प्रोग्राम पर भरोसा करते हैं। यह कार्यक्षमता के माध्यम से कार्यान्वित की जाती है btrfs check कार्यक्रम। संस्करण 4.0 के बाद से यह कार्यक्षमता अपेक्षाकृत स्थिर मानी जाती है। हालाँकि, दिसंबर 2022 तक, btrfs प्रलेखन से पता चलता है कि इसका --repair विकल्प का उपयोग केवल तभी किया जाना चाहिए जब आपको किसी डेवलपर या अनुभवी उपयोगकर्ता द्वारा सलाह दी गई हो।[76]अगस्त 2022 तक, एसएलई प्रलेखन लाइव सीडी का उपयोग करने, बैकअप करने और केवल अंतिम उपाय के रूप में मरम्मत विकल्प का उपयोग करने की सिफारिश करता है।[77] और टूल है, जिसका नाम है btrfs-restore, जिसका उपयोग टूटे हुए फ़ाइल सिस्टम को संशोधित किए बिना (अर्थात , गैर-विनाशकारी रूप से) बिना किसी अनमाउंट फ़ाइल सिस्टम से फ़ाइलों को पुनर्प्राप्त करने के लिए किया जा सकता है।[78][79] सामान्य उपयोग में, Btrfs ज्यादातर स्व-चिकित्सा है और माउंट समय पर टूटे हुए जड़ वाले पेड़ों से पुनर्प्राप्त कर सकता है, आवधिक डेटा को स्थायी भंडारण के लिए फ़्लश करने के लिए धन्यवाद, डिफ़ॉल्ट रूप से हर 30 सेकंड में। इस प्रकार, अलग-अलग त्रुटियों के कारण अधिकतम 30 सेकंड के फ़ाइल सिस्टम परिवर्तन अगले माउंट पर गुम हो जाएंगे।[80] इस अवधि को वांछित मान (सेकंड में) निर्दिष्ट करके बदला जा सकता है commit माउंट विकल्प।[81][82]

डिजाइन

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

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

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

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

फाइल सिस्टम ट्री

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

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

विस्तार

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

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

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

विस्तार आवंटन पेड़

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

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

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

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

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

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

See also: Silent data corruption

CRC-32C चेकसम की गणना डेटा और मेटाडेटा दोनों के लिए की जाती है और चेकसम ट्री में चेकसम आइटम के रूप में संग्रहीत की जाती है। मेटाडेटा चेकसम के 256 बिट्स और डेटा चेकसम के लिए पूर्ण नोड तक (लगभग 4 KB या अधिक) के लिए जगह है। Btrfs में फाइल सिस्टम के भविष्य के संस्करणों में जोड़े जाने वाले अतिरिक्त चेकसम एल्गोरिदम के प्रावधान हैं।[34][89] आवंटित ब्लॉकों के प्रति सन्निहित रन में चेकसम आइटम है, जिसमें आइटम डेटा में एंड-टू-एंड पैक किए गए प्रति-ब्लॉक चेकसम हैं। यदि फिट होने से अधिक चेकसम हैं, तो वे नए पत्ते में दूसरे चेकसम आइटम में फैल जाते हैं। यदि फ़ाइल सिस्टम किसी ब्लॉक को पढ़ते समय चेकसम बेमेल का पता लगाता है, तो वह पहले इस ब्लॉक की अच्छी प्रति किसी अन्य डिवाइस से प्राप्त करने (या बनाने) का प्रयास करता है। – यदि आंतरिक मिररिंग या RAID तकनीकें उपयोग में हैं।[90][91] Btrfs फ़ाइल सिस्टम स्क्रब जॉब को ट्रिगर करके पूरे फ़ाइल सिस्टम की ऑनलाइन जाँच प्रारंभ कर सकता है जो बैकग्राउंड में किया जाता है। स्क्रब जॉब पूरे फाइल सिस्टम को अखंडता के लिए स्कैन करता है और स्वचालित रूप से रास्ते में मिलने वाले किसी भी खराब ब्लॉक की रिपोर्ट करने और मरम्मत करने का प्रयास करता है।[90][92]

लॉग पेड़

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

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

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

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

सिंगल
1 लॉजिकल से 1 फिजिकल चंक
dup
1 ब्लॉक डिवाइस पर 1 लॉजिकल चंक से 2 फिजिकल चंक
Raid0
N≥2 ब्लॉक डिवाइसेस में N≥2 फिजिकल चंक्स के लिए N लॉजिकल चंक्स
Raid1
N≥2 ब्लॉक उपकरणों में से 2 में 1 तार्किक हिस्सा से 2 भौतिक हिस्सा,[94] पारंपरिक मानक RAID स्तरों के विपरीत #RAID 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 चयनित मिररिंग/मैपिंग के लिए पर्याप्त बड़ा नहीं है, तो फाइल सिस्टम प्रभावी रूप से अंतरिक्ष से बाहर है।

पुनर्स्थापन पेड़

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

सुपरब्लॉक

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

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

समर्थित

  • Oracle Linux संस्करण 7 से[98][99]
  • संस्करण 12 से एसयूएसई लिनक्स एंटरप्राइज़ सर्वर[100][101]
  • Synology DiskStation Manager (DSM) संस्करण 6.0 से[102]

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

  • Btrfs को Red Hat Enterprise Linux 6 और 7 में तकनीकी पूर्वावलोकन के रूप में सम्मिलित किया गया था;[21][30]इसे 2018 में Red Hat Enterprise Linux में हटा दिया गया था।[31][103][104]
  • Btrfs को 2013 के आसपास नेटगियर रेडीएनएएस आर्म-आधारित 1xx और इंटेल-आधारित 3xx में mdadm-raid सरणियों पर स्तरित किया गया था (शायद अभी भी अस्थिर btrfs-raid कार्यात्मकताओं से बचने के लिए btrfs चेकसम और स्नैपशॉट का फायदा उठाने के लिए)। डेबियन जेसी आधारित OS6 के अपडेट अभी भी 2022 के आसपास प्रस्तुत किए गए थे (शायद अभी भी समर्थित माना जाता है?)।

यह भी देखें

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

टिप्पणियाँ

  1. ↑ 1.0 1.1 This is the Btrfs' own on-disk size limit. The limit is reduced down to 8 EiB on 64-bit systems and 2 EiB on 32-bit systems due to Linux kernel's internal limits, unless kernel's CONFIG_LBD configuration option (available since the 2.6.x kernel series) is enabled to remove these kernel limits.[105][106]
  2. ↑ Every item in Btrfs has a 64-bit identifier, which means the most files one can have on a Btrfs filesystem is 264.


संदर्भ

  1. ↑ "Contributors at BTRFS documentation". kernel.org. 2022-06-15. Retrieved 2022-12-05.
  2. ↑ 2.0 2.1 "Suse Documentation: Storage Administration Guide – Large File Support in Linux". SUSE. Retrieved 2015-08-12.
  3. ↑ 3.0 3.1 3.2 3.3 Mason, Chris. "Btrfs design". Btrfs wiki. Retrieved 8 November 2011.
  4. ↑ Jonathan Corbet (2010-07-26). "File creation times". LWN.net. Retrieved 2015-08-15.
  5. ↑ "On-disk Format - btrfs Wiki". btrfs.wiki.kernel.org.
  6. ↑ 6.0 6.1 "btrfs Wiki". kernel.org. Retrieved 19 April 2015.
  7. ↑ 7.0 7.1 "Linux_4.14 - Linux Kernel Newbies". kernelnewbies.org.
  8. ↑ 8.0 8.1 8.2 8.3 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.
  9. ↑ 9.0 9.1 9.2 "Deduplication". kernel.org. Retrieved 19 April 2015.
  10. ↑ "ReactOS 0.4.1 Released". reactos.org. Retrieved 11 August 2016.
  11. ↑ "संग्रहीत प्रति". Event occurs at 1m 15s. Archived from the original on 18 August 2016. Retrieved 6 February 2016.
  12. ↑ 12.0 12.1 Henson, Valerie (31 January 2008). Chunkfs: Fast file system check and repair. Melbourne, Australia. Event occurs at 18m 49s. Retrieved 2008-02-05. इसे बटर एफएस या बी-ट्री एफएस कहा जाता है, लेकिन सभी अच्छे बच्चे बटर एफएस कहते हैं
  13. ↑ "Linux kernel commit changing stability status in fs/btrfs/Kconfig". Retrieved 2019-02-08.
  14. ↑ 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.
  15. ↑ 15.0 15.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.
  16. ↑ 16.0 16.1 "Lead Btrfs File-System Developers Join Facebook". phoronix.com. Retrieved 19 April 2015.
  17. ↑ 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)
  18. ↑ Ts'o, Theodore (1 August 2008). "Re: reiser4 for 2.6.27-rc1". linux-kernel (Mailing list). Retrieved 2010-12-31.
  19. ↑ "विकास समयरेखा". Btrfs wiki. 11 December 2008. Archived from the original on 20 December 2008. Retrieved 5 November 2011.
  20. ↑ Wuelfing, Britta (12 January 2009). "Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem". Linux Magazine. Retrieved 5 November 2011.
  21. ↑ 21.0 21.1 "Red Hat Enterprise Linux 6 documentation: Technology Previews". Archived from the original on 28 May 2011. Retrieved 21 January 2011.
  22. ↑ "Fedora Weekly News Issue 276". 25 May 2011.
  23. ↑ "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...
  24. ↑ 24.0 24.1 "Linux kernel 3.0, Section 1.1. Btrfs: Automatic defragmentation, scrubbing, performance improvements". kernelnewbies.org. 2011-07-21. Retrieved 2016-04-05.
  25. ↑ Leemhuis, Thorsten (21 June 2011). "Kernel Log: Coming in 3.0 (Part 2) - Filesystems". The H Open. Retrieved 8 November 2011.
  26. ↑ Varghese, Sam. "iTwire". ITWire.com. Retrieved 19 April 2015.
  27. ↑ "Unbreakable Enterprise Kernel Release 2 has been released". Retrieved 2019-05-08.
  28. ↑ "SLES 11 SP2 Release Notes". 21 August 2012. Retrieved 2012-08-29.
  29. ↑ "SUSE Linux Enterprise Server 12 Release Notes". 2015-11-05. Retrieved 2016-01-20.
  30. ↑ 30.0 30.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.
  31. ↑ 31.0 31.1 "Considerations in adopting RHEL 8". Product Documentation for Red Hat Enterprise Linux 8. Red Hat. Retrieved 2019-05-09.
  32. ↑ "How to Choose Your Red Hat Enterprise Linux File System". Retrieved 2022-01-03.
  33. ↑ "Btrfs Coming to Fedora 33". Fedora Magazine. 2020-08-24. Retrieved 2020-08-25.
  34. ↑ 34.0 34.1 34.2 "Btrfs Wiki: Features". btrfs.wiki.kernel.org. 2013-11-27. Retrieved 2013-11-27.
  35. ↑ "Btrfs Wiki: Changelog". btrfs.wiki.kernel.org. 2019-05-29. Retrieved 2013-11-27.
  36. ↑ "Manpage btrfs-check".
  37. ↑ "Using Btrfs with Multiple Devices". kernel.org. 2013-11-07. Retrieved 2013-11-20.
  38. ↑ "Compression". kernel.org. 2013-06-25. Retrieved 2014-04-01.
  39. ↑ "Btrfs: add support for inode properties". kernel.org. 2014-01-28. Retrieved 2014-04-01.
  40. ↑ "btrfs: Readonly snapshots". Retrieved 2011-12-12.
  41. ↑ "Save disk space on Linux by cloning files on Btrfs and OCFS2". Retrieved 2017-08-01.
  42. ↑ "Wiki FAQ: What checksum function does Btrfs use?". Btrfs wiki. Retrieved 2009-06-15.
  43. ↑ "Btrfs hilights in 5.5: new hashes". Retrieved 2020-08-29.
  44. ↑ 44.0 44.1 "Btrfs progs release 4.6". Retrieved 2017-08-01.
  45. ↑ Mason, Chris (12 January 2009). "Btrfs चेंजलॉग". Archived from the original on 29 February 2012. Retrieved 2012-02-12.
  46. ↑ 46.0 46.1 46.2 Corbet, Jonathan (2012-07-11), Btrfs send/receive, LWN.net, retrieved 2012-11-14
  47. ↑ "Btrfs Wiki: Incremental Backup". 2013-05-27. Retrieved 2013-11-27.
  48. ↑ 48.0 48.1 Jansen, Arne (2011), Btrfs Subvolume Quota Groups (PDF), Strato AG, retrieved 2012-11-14
  49. ↑ btrfs (2016-07-16). "RAID 5/6". kernel.org. Retrieved 2016-10-01.
  50. ↑ Zygo Blaxell. "How to use btrfs raid5 successfully(ish)". lore.kernel.org. Retrieved 2022-06-26.
  51. ↑ Zygo Blaxell. "Current bugs with operational impact on btrfs raid5". lore.kernel.org. Retrieved 2022-06-26.
  52. ↑ Corbet, Jonathan (2 November 2011). "A btrfs update at LinuxCon Europe". Retrieved 12 February 2012.
  53. ↑ Mazzoleni, Andrea. "btrfs: lib: raid: New RAID library supporting up to six parities". Retrieved 2014-03-16.
  54. ↑ "Btrfs Project ideas". 21 February 2013. Retrieved 21 February 2013.
  55. ↑ Dorminy, Sweet Tea (13 July 2022). "btrfs: add fscrypt integration". Retrieved 2022-08-01.
  56. ↑ 56.0 56.1 56.2 56.3 Aurora, Valerie (22 July 2009). "A short history of btrfs". LWN.net. Retrieved 5 November 2011.
  57. ↑ Hilzinger, Marcel (22 April 2009). "Btrfs का भविष्य सुरक्षित". Linux Magazine. Retrieved 5 November 2011.
  58. ↑ Corbet, Jonathan (2009-05-05). "The two sides of reflink()". LWN.net. Retrieved 2013-10-17.
  59. ↑ 59.0 59.1 "UseCases – btrfs documentation". kernel.org. Retrieved 2013-11-04.
  60. ↑ "btrfs: allow cross-subvolume file clone". github.com. Retrieved 2013-11-04.
  61. ↑ "Symlinks reference names, hardlinks reference meta-data and reflinks reference data". pixelbeat.org. 2010-10-27. Retrieved 2013-10-17.
  62. ↑ Meyering, Jim (20 August 2009). "GNU coreutils NEWS: Noteworthy changes in release 7.5". savannah.gnu.org. Retrieved 2009-08-30.
  63. ↑ Scrivano, Giuseppe (1 August 2009). "cp: accept the --reflink option". savannah.gnu.org. Retrieved 2009-11-02.
  64. ↑ ioctl_fideduperange(2) – Linux Programmer's Manual – System Calls
  65. ↑ 66.0 66.1 66.2 66.3 "SysadminGuide – Btrfs documentation". kernel.org. Retrieved 2013-10-31.
  66. ↑ 67.0 67.1 67.2 "5.6 Creating Subvolumes and Snapshots [needs update]". oracle.com. 2013. Retrieved 2013-10-31.
  67. ↑ "Gotchas - btrfs विकी". btrfs.wiki.kernel.org.
  68. ↑ 69.0 69.1 "5.7 Using the Send/Receive Feature". oracle.com. 2013. Retrieved 2013-10-31.
  69. ↑ 70.0 70.1 70.2 70.3 Mason, Chris (2015-06-25). "Conversion from Ext3 (Btrfs documentation)". kernel.org. Retrieved 2016-04-22.
  70. ↑ "btrfs-convert(8) — BTRFS Documentation". Retrieved 2022-10-16.
  71. ↑ "बीज यंत्र". Archived from the original on 12 June 2017. Retrieved 1 August 2017.
  72. ↑ Mason, Chris (2012-04-05), Btrfs Filesystem: Status and New Features, Linux Foundation, retrieved 2012-11-16[permanent dead link]
  73. ↑ 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, डुप्लीकेशन, एन्क्रिप्शन और अन्य सुविधाओं को जोड़ने की योजना बना रहे हैं जो लंबे समय से व्यवस्थापक इच्छा सूची में हैं।
  74. ↑ Sterba, David. "authenticated file systems using HMAC(SHA256)". Lore.Kernel.org. Retrieved 25 April 2020.
  75. ↑ "btrfs-check(8)". btrfs.readthedocs.io.
  76. ↑ "How to recover from BTRFS errors | Support | SUSE". www.suse.com. Retrieved 2023-01-28.
  77. ↑ "पुनर्स्थापित करें - btrfs विकी". btrfs.wiki.kernel.org.
  78. ↑ "btrfs-restore(8) - Linux manual page". man7.org. Retrieved 2023-01-28.
  79. ↑ "समस्या अक्सर पूछे जाने वाले प्रश्न - btrfs विकी". kernel.org. 2013-07-31. Retrieved 2014-01-16.
  80. ↑ "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.
  81. ↑ "Mount options - btrfs Wiki". kernel.org. 2013-11-12. Retrieved 2014-01-16.
  82. ↑ Reiser, Hans (2001-12-07). "Re: Ext2 directory index: ALS paper and benchmarks". ReiserFS developers mailing list. Retrieved 2009-08-28.
  83. ↑ Mason, Chris. "एसीपी". Oracle personal web page. Retrieved 2011-11-05.
  84. ↑ Fasheh, Mark (2012-10-09). "btrfs: extended inode refs". Archived from the original on 2013-04-15. Retrieved 2012-11-07.
  85. ↑ Torvalds, Linus (2012-10-10). "क्रिस मेसन से btrfs अद्यतन प्राप्त करें". git.kernel.org. Archived from the original on 2013-04-15. Retrieved 2012-11-07.
  86. ↑ Larabel, Michael (2010-12-24). "Btrfs स्पेस कैश विकल्प के बेंचमार्क". Phoronix. Retrieved 2012-11-16.
  87. ↑ "FAQ - btrfs Wiki: What checksum function does Btrfs use?". The btrfs Project. Retrieved 2020-11-22.
  88. ↑ 90.0 90.1 Bierman, Margaret; Grimmer, Lenz (August 2012). "How I Use the Advanced Capabilities of Btrfs". Retrieved 2013-09-20.
  89. ↑ Salter, Jim (15 January 2014). "Bitrot and Atomic COWs: Inside "Next-Gen" Filesystems". Ars Technica. Retrieved 15 January 2014.
  90. ↑ Coekaerts, Wim (2011-09-28). "Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!". Retrieved 2013-09-20.
  91. ↑ "शब्दकोष". Btrfs Wiki. Retrieved 2021-07-31.
  92. ↑ "Manpage/mkfs.btrfs". Btrfs Wiki. Profiles. Retrieved 2021-07-31.
  93. ↑ Mason, Chris; Rodeh, Ohad; Bacik, Josef (2012-07-09), BTRFS: The Linux B-tree Filesystem (PDF), IBM Research, retrieved 2012-11-12
  94. ↑ Mason, Chris (30 April 2008). "मल्टीपल डिवाइस सपोर्ट". Btrfs wiki. Archived from the original on 20 July 2011. Retrieved 5 November 2011.
  95. ↑ Bartell, Sean (2010-04-20). "Re: Restoring BTRFS partition". linux-btrfs (Mailing list).
  96. ↑ "Oracle Now Supports Btrfs RAID5/6 on Their Unbreakable Enterprise Kernel - Phoronix". Phoronix.com.
  97. ↑ "Managing Btrfs in Oracle Linux 8". docs.oracle.com. Retrieved 6 June 2020.[dead link]
  98. ↑ "SUSE ने Btrfs के लिए समर्थन की फिर से पुष्टि की". LWN.net.
  99. ↑ "SUSE Linux Enterprise Server 12 Release Notes". SUSE.com. Retrieved 2021-02-28.
  100. ↑ "क्लाउड स्टेशन श्वेत पत्र" (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
  101. ↑ "Btrfs has been deprecated in RHEL | Hacker News". News.YCombinator.com.
  102. ↑ "ऐसा प्रतीत होता है कि Red Hat अपनी Btrfs आशाओं का परित्याग कर रहा है - Phoronix". Phoronix.com.
  103. ↑ Andreas Jaeger (2005-02-15). "Large File Support in Linux". users.suse.com. Retrieved 2015-08-12.
  104. ↑ "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.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=बीटीआरएफएस&oldid=193754’