बीटीआरएफएस

From Vigyanwiki
Revision as of 11:33, 10 June 2023 by alpha>Indicwiki (Created page with "{{short description|File system for Linux}} {{Use dmy dates|date=September 2021}} {{Infobox filesystem | full_name = B-tree file system | name...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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; 16 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]

Btrfs (बेहतर F S के रूप में उच्चारण किया जाता है,[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]


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

Error creating thumbnail:
स्नैपर के साथ प्रबंधित 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]


कोटा समूह

File:Btrfs qgroup screenshot.png
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]) विशेष विस्तार के रूप में जो चेकसमिंग और कॉपी-ऑन-राइट से छूट प्राप्त हैं।

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

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. 15 June 2022. Retrieved 5 December 2022.
  2. 2.0 2.1 "Suse Documentation: Storage Administration Guide – Large File Support in Linux". SUSE. Retrieved 12 August 2015.
  3. 3.0 3.1 3.2 3.3 Mason, Chris. "Btrfs design". Btrfs wiki. Retrieved 8 November 2011.
  4. Jonathan Corbet (26 July 2010). "File creation times". LWN.net. Retrieved 15 August 2015.
  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 1 September 2009.
  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 5 February 2008. इसे बटर एफएस या बी-ट्री एफएस कहा जाता है, लेकिन सभी अच्छे बच्चे बटर एफएस कहते हैं
  13. "Linux kernel commit changing stability status in fs/btrfs/Kconfig". Retrieved 8 February 2019.
  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 22 August 2009. {{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 31 December 2010.
  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 8 February 2011. 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. 21 July 2011. Retrieved 5 April 2016.
  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 8 May 2019.
  28. "SLES 11 SP2 Release Notes". 21 August 2012. Retrieved 29 August 2012.
  29. "SUSE Linux Enterprise Server 12 Release Notes". 5 November 2015. Retrieved 20 January 2016.
  30. 30.0 30.1 "Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality". 1 August 2017. Archived from the original on 8 August 2017. Retrieved 15 August 2017.
  31. 31.0 31.1 "Considerations in adopting RHEL 8". Product Documentation for Red Hat Enterprise Linux 8. Red Hat. Retrieved 9 May 2019.
  32. "How to Choose Your Red Hat Enterprise Linux File System". Retrieved 3 January 2022.
  33. "Btrfs Coming to Fedora 33". Fedora Magazine. 24 August 2020. Retrieved 25 August 2020.
  34. 34.0 34.1 34.2 "Btrfs Wiki: Features". btrfs.wiki.kernel.org. 27 November 2013. Retrieved 27 November 2013.
  35. "Btrfs Wiki: Changelog". btrfs.wiki.kernel.org. 29 May 2019. Retrieved 27 November 2013.
  36. "Manpage btrfs-check".
  37. "Using Btrfs with Multiple Devices". kernel.org. 7 November 2013. Retrieved 20 November 2013.
  38. "Compression". kernel.org. 25 June 2013. Retrieved 1 April 2014.
  39. "Btrfs: add support for inode properties". kernel.org. 28 January 2014. Retrieved 1 April 2014.
  40. "btrfs: Readonly snapshots". Retrieved 12 December 2011.
  41. "Save disk space on Linux by cloning files on Btrfs and OCFS2". Retrieved 1 August 2017.
  42. "Wiki FAQ: What checksum function does Btrfs use?". Btrfs wiki. Retrieved 15 June 2009.
  43. "Btrfs hilights in 5.5: new hashes". Retrieved 29 August 2020.
  44. 44.0 44.1 "Btrfs progs release 4.6". Retrieved 1 August 2017.
  45. Mason, Chris (12 January 2009). "Btrfs चेंजलॉग". Archived from the original on 29 February 2012. Retrieved 12 February 2012.
  46. 46.0 46.1 46.2 Corbet, Jonathan (11 July 2012), Btrfs send/receive, LWN.net, retrieved 14 November 2012
  47. "Btrfs Wiki: Incremental Backup". 27 May 2013. Retrieved 27 November 2013.
  48. 48.0 48.1 Jansen, Arne (2011), Btrfs Subvolume Quota Groups (PDF), Strato AG, retrieved 14 November 2012
  49. btrfs (16 July 2016). "RAID 5/6". kernel.org. Retrieved 1 October 2016.
  50. Zygo Blaxell. "How to use btrfs raid5 successfully(ish)". lore.kernel.org. Retrieved 26 June 2022.
  51. Zygo Blaxell. "Current bugs with operational impact on btrfs raid5". lore.kernel.org. Retrieved 26 June 2022.
  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 16 March 2014.
  54. "Btrfs Project ideas". 21 February 2013. Retrieved 21 February 2013.
  55. Dorminy, Sweet Tea (13 July 2022). "btrfs: add fscrypt integration". Retrieved 1 August 2022.
  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 (5 May 2009). "The two sides of reflink()". LWN.net. Retrieved 17 October 2013.
  59. 59.0 59.1 "UseCases – btrfs documentation". kernel.org. Retrieved 4 November 2013.
  60. "btrfs: allow cross-subvolume file clone". github.com. Retrieved 4 November 2013.
  61. "Symlinks reference names, hardlinks reference meta-data and reflinks reference data". pixelbeat.org. 27 October 2010. Retrieved 17 October 2013.
  62. Meyering, Jim (20 August 2009). "GNU coreutils NEWS: Noteworthy changes in release 7.5". savannah.gnu.org. Retrieved 30 August 2009.
  63. Scrivano, Giuseppe (1 August 2009). "cp: accept the --reflink option". savannah.gnu.org. Retrieved 2 November 2009.
  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 31 October 2013.
  66. 67.0 67.1 67.2 "5.6 Creating Subvolumes and Snapshots [needs update]". oracle.com. 2013. Retrieved 31 October 2013.
  67. "Gotchas - btrfs विकी". btrfs.wiki.kernel.org.
  68. 69.0 69.1 "5.7 Using the Send/Receive Feature". oracle.com. 2013. Retrieved 31 October 2013.
  69. 70.0 70.1 70.2 70.3 Mason, Chris (25 June 2015). "Conversion from Ext3 (Btrfs documentation)". kernel.org. Retrieved 22 April 2016.
  70. "btrfs-convert(8) — BTRFS Documentation". Retrieved 16 October 2022.
  71. "बीज यंत्र". Archived from the original on 12 June 2017. Retrieved 1 August 2017.
  72. Mason, Chris (5 April 2012), Btrfs Filesystem: Status and New Features, Linux Foundation, retrieved 16 November 2012[permanent dead link]
  73. 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 9 October 2014. भविष्य के रिलीज में हम ऑनलाइन 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 28 January 2023.
  77. "पुनर्स्थापित करें - btrfs विकी". btrfs.wiki.kernel.org.
  78. "btrfs-restore(8) - Linux manual page". man7.org. Retrieved 28 January 2023.
  79. "समस्या अक्सर पूछे जाने वाले प्रश्न - btrfs विकी". kernel.org. 31 July 2013. Retrieved 16 January 2014.
  80. "kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree)". kernel.org. 21 November 2013. Retrieved 6 February 2014.
  81. "Mount options - btrfs Wiki". kernel.org. 12 November 2013. Retrieved 16 January 2014.
  82. Reiser, Hans (7 December 2001). "Re: Ext2 directory index: ALS paper and benchmarks". ReiserFS developers mailing list. Retrieved 28 August 2009.
  83. Mason, Chris. "एसीपी". Oracle personal web page. Retrieved 5 November 2011.
  84. Fasheh, Mark (9 October 2012). "btrfs: extended inode refs". Archived from the original on 15 April 2013. Retrieved 7 November 2012.
  85. Torvalds, Linus (10 October 2012). "क्रिस मेसन से btrfs अद्यतन प्राप्त करें". git.kernel.org. Archived from the original on 15 April 2013. Retrieved 7 November 2012.
  86. Larabel, Michael (24 December 2010). "Btrfs स्पेस कैश विकल्प के बेंचमार्क". Phoronix. Retrieved 16 November 2012.
  87. "FAQ - btrfs Wiki: What checksum function does Btrfs use?". The btrfs Project. Retrieved 22 November 2020.
  88. 90.0 90.1 Bierman, Margaret; Grimmer, Lenz (August 2012). "How I Use the Advanced Capabilities of Btrfs". Retrieved 20 September 2013.
  89. Salter, Jim (15 January 2014). "Bitrot and Atomic COWs: Inside "Next-Gen" Filesystems". Ars Technica. Retrieved 15 January 2014.
  90. Coekaerts, Wim (28 September 2011). "Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!". Retrieved 20 September 2013.
  91. "शब्दकोष". Btrfs Wiki. Retrieved 31 July 2021.
  92. "Manpage/mkfs.btrfs". Btrfs Wiki. Profiles. Retrieved 31 July 2021.
  93. Mason, Chris; Rodeh, Ohad; Bacik, Josef (9 July 2012), BTRFS: The Linux B-tree Filesystem (PDF), IBM Research, retrieved 12 November 2012
  94. Mason, Chris (30 April 2008). "मल्टीपल डिवाइस सपोर्ट". Btrfs wiki. Archived from the original on 20 July 2011. Retrieved 5 November 2011.
  95. Bartell, Sean (20 April 2010). "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 28 February 2021.
  100. "क्लाउड स्टेशन श्वेत पत्र" (PDF). Synology.com. Synology. p. 11. Archived from the original (PDF) on 11 November 2020. Retrieved 2 April 2021. 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 (15 February 2005). "Large File Support in Linux". users.suse.com. Retrieved 12 August 2015.
  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 12 August 2015.


बाहरी संबंध