बीटीआरएफएस

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

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

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

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

कार्यान्वित
Linux कर्नेल के संस्करण 5.0 के अनुसार, बीटीआरएफएस निम्नलिखित विशेषताओं को लागू करता है:
 * कॉपी-ऑन-राइट की प्रकृति के कारण कुछ विन्यासों में अधिकतर स्व-उपचार
 * ऑनलाइन डीफ़्रेग्मेंटेशन और ऑटोडिफ़्रेग माउंट विकल्प * ऑनलाइन मात्रा में वृद्धि और सिकुड़न
 * ऑनलाइन ब्लॉक डिवाइस को जोड़ना और हटाना
 * ऑनलाइन संतुलन (लोड को संतुलित करने के लिए ब्लॉक उपकरणों के मध्य वस्तुओं की आवाजाही)
 * ऑफलाइन एफएसके
 * त्रुटियों को खोजने और अनावश्यक प्रतियों वाली फ़ाइलों के लिए उन्हें स्वचालित रूप से ठीक करने के लिए ऑनलाइन डेटा स्क्रबिंग
 * RAID 0, RAID 1 और RAID 10
 * सबवॉल्यूम्स (प्रत्येक डिस्क विभाजन के भीतर या अधिक अलग से माउंट करने योग्य रूट निर्देशिका)
 * zlib, Lempel-Ziv-Oberhumer के माध्यम से पारदर्शी डेटा संपीड़न और (4.14 से) Zमानक, फ़ाइल या मात्रा प्रति विन्यास योग्य
 * परमाणु लिखने योग्य (कॉपी-ऑन-राइट के माध्यम से) या केवल पढ़ने के लिए उपखंडों का स्नैपशॉट (कंप्यूटर भंडारण)।
 * फाइल क्लोनिंग (रीफ्लिंक, कॉपी-ऑन-राइट)  के जरिए
 * डेटा और मेटाडेटा पर चेकसम (CRC-32C ). 5.5 से नए हैश फ़ंक्शन लागू किए गए हैं: xxHash, SHA256, BLAKE (हैश फंक्शन)।
 * ext3/4 से बीटीआरएफएस(रोलबैक के साथ) में इन-प्लेस रूपांतरण। यह सुविधा btrfs-progs संस्करण 4.0 के आसपास वापस आ गई, 4.6 में खरोंच से फिर से लिखी गई।
 * रीड-ओनली स्टोरेज की संघ पर्वत िंग, जिसे फाइल प्रणालीसीडिंग के रूप में जाना जाता है (रीड-ओनली स्टोरेज को लिखने योग्य बीटीआरएफएसके लिए कॉपी-ऑन-राइट बैकिंग के रूप में उपयोग किया जाता है)
 * ब्लॉक डिस्कार्ड (कुछ हार्डवेयर वर्चुअलाइजेशन सेटअप पर स्थान को पुनः प्राप्त करता है और ट्रिम (कंप्यूटिंग) के साथ ठोस राज्य ड्राइव पर समतलन पुराना होना में सुधार करता है)
 * भेजें/प्राप्त करें (बाइनरी स्ट्रीम में स्नैपशॉट के मध्य अंतर सहेजना) * वृध्दिशील बैकअप
 * आउट-ऑफ-बैंड डेटा डुप्लिकेशन (यूजरस्पेस टूल्स की आवश्यकता है) * फ़ाइल की अदला - बदली करें ों और स्वैप विभाजन को संभालने की क्षमता

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

 * श्रेणीबद्ध प्रति-सबवॉल्यूम कोटा * RAID 5, RAID 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

चंक ट्री प्रत्येक डिवाइस को डिवाइस आइटम के रूप में और लॉजिकल चंक्स को चंक मैप आइटम के रूप में संग्रहीत करके इसे ट्रैक करता है, जो तार्किक से भौतिक पतों तक फॉरवर्ड मैपिंग प्रदान करता है, जो कि उनकी कुंजी के कम से कम महत्वपूर्ण 64 बिट्स में संग्रहीत होता है। चंक नक्शा आइटम कई अलग-अलग प्रकारों में से हो सकते हैं: एन उन ब्लॉक उपकरणों की संख्या है जिनके पास अभी भी खाली स्थान है जब चंक आवंटित किया जाता है। यदि N चयनित मिररिंग/मैपिंग के लिए पर्याप्त बड़ा नहीं है, तो फाइल प्रणालीप्रभावी रूप से अंतरिक्ष से बाहर है।
 * सिंगल: 1 लॉजिकल से 1 फिजिकल चंक
 * dup : 1 ब्लॉक डिवाइस पर 1 लॉजिकल चंक से 2 फिजिकल चंक
 * Raid0 : N≥2 ब्लॉक डिवाइसेस में N≥2 फिजिकल चंक्स के लिए N लॉजिकल चंक्स
 * Raid1 : N≥2 ब्लॉक उपकरणों में से 2 में 1 तार्किक हिस्सा से 2 भौतिक हिस्सा, पारंपरिक मानक 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 फिजिकल चंक्स पैरिटी के रूप में उपयोग किए जाते हैं।

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

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

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

समर्थित

 * ओरेकल लिनक्स संस्करण 7 से
 * संस्करण 12 से एसयूएसई लिनक्स एंटरप्राइज़ सर्वर
 * सिनोलॉजी डिस्कस्टेशन मैनेजर (डीएसएम) संस्करण 6.0 से

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

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

यह भी देखें

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

बाहरी संबंध

 * – a conference presentation by Avi Miller, an ओरेकलengineer
 * Btrfs: Working with multiple devices – LWN.net, December 2013, by Jonathan Corbet
 * Marc's Linux बीटीआरएफएसposts – detailed insights into various बीटीआरएफएसfeatures
 * बीटीआरएफएसoverview, LinuxCon 2014, by Marc Merlin
 * , Linux Magazine, 14 July 2009, by Jeffrey B. Layton
 * , Linux Magazine, 14 July 2009, by Jeffrey B. Layton