बीटीआरएफएस

From Vigyanwiki
Revision as of 10:04, 16 June 2023 by alpha>Artiverma
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 में ओरेकल Corporation में डिज़ाइन किया गया था, और नवंबर 2013 से, फ़ाइल प्रणालीके ऑन-डिस्क प्रारूप को Linux कर्नेल में स्थिर घोषित किया गया है।[13] बीटीआरएफएसका उद्देश्य Linux फ़ाइल प्रणाली में फैले पूल (कंप्यूटर विज्ञान), स्नैपशॉट (कंप्यूटर भंडारण) , अंततः, और इंटीग्रल मल्टी-डिवाइस की कमी को दूर करना है।[8] बीटीआरएफएस के प्रमुख लेखक क्रिस मेसन ने कहा कि इसका लक्ष्य उपलब्ध होने वाले स्टोरेज के लिए [लिनक्स] स्केल देना था। स्केलिंग केवल स्टोरेज को संबोधित करने के बारे में नहीं है, जबकि इसका तात्पर्य यह भी है कि इसे साफ इंटरफ़ेस के साथ प्रशासित और प्रबंधित करने में सक्षम होना चाहिए जो लोगों को यह देखने देता है कि क्या उपयोग किया जा रहा है और इसे और अधिक विश्वसनीय बनाता है।[14]

इतिहास

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

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

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

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

विशेषताएं

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

कार्यान्वित

Linux कर्नेल के संस्करण 5.0 के अनुसार, बीटीआरएफएस निम्नलिखित विशेषताओं को लागू करता है:[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-progs संस्करण 4.0 के आसपास वापस आ गई, 4.6 में खरोंच से फिर से लिखी गई।[44]
  • रीड-ओनली स्टोरेज की संघ पर्वत िंग, जिसे फाइल प्रणालीसीडिंग के रूप में जाना जाता है (रीड-ओनली स्टोरेज को लिखने योग्य बीटीआरएफएसके लिए कॉपी-ऑन-राइट बैकिंग के रूप में उपयोग किया जाता है)[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 में, बीटीआरएफएससे सन माइक्रोसिस्टम्स द्वारा विकसित ओरेकलZFS के तुलनीय फीचर सेट की प्रस्तुतकश करने की उम्मीद थी।[56]2009 में ओरेकलद्वारा Sun के अधिग्रहण के बाद, मेसन और ओरेकलने बीटीआरएफएसके विकास को जारी रखने का निर्णय लिया।[57]

क्लोनिंग

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कोटा समूह

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

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

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

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

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

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

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

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

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

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

एन्क्रिप्शन

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

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

जांच और वसूली

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

डिजाइन

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

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

बीटीआरएफएसको ऐसे ट्रीों की कई परतों के रूप में संरचित किया गया है, सभी ही 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 ब्लॉक समूह, चूँकि, फ़ाइल प्रणाली के आकार से गणना किए गए निश्चित स्थान हैं, जबकि बीटीआरएफएस में वे गतिशील हैं और आवश्यकतानुसार बनाए गए हैं।) प्रत्येक ब्लॉक समूह आइटम के साथ जुड़ा हुआ है। फ़ाइल प्रणाली ट्री में इनोड आइटम्स में उनके वर्तमान ब्लॉक समूह का संदर्भ सम्मिलित है।[3]

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

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

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

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

See also: साइलेंट डेटा करप्शन

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

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

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

लॉग ट्री

fsync अनुरोध संशोधित डेटा को शीघ्र स्थिर संग्रहण में भेजता है। fsync-भारी वर्कलोड (जैसे डेटाबेस या आभासी मशीन जिसका ओएस fsyncs बार-बार चल रहा है) फ़ाइल प्रणाली को बार-बार कॉपी-ऑन-राइट करने और ट्री के बार-बार संशोधित भागों को फ़्लश करने के लिए विवश करके अनावश्यक लेखन आइ/ओ का बड़ा सौदा उत्पन्न कर सकता है। इससे बचने के लिए, लिखने पर 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 पर अतिरिक्त प्रतियों के साथ होता है। जब सुपरब्लॉक मिरर को अपडेट किया जाता है, तो इसकी जनरेशन संख्या बढ़ जाती है। आरोह समय पर, उच्चतम पीढ़ी संख्या वाली प्रतिलिपि का उपयोग किया जाता है। एसएसडी मोड को त्यागकर सभी सुपरब्लॉक मिरर को अग्रानुक्रम में अपडेट किया जाता है, जो कुछ वियर लेवलिंग प्रदान करने के लिए मिरर के मध्य अपडेट को वैकल्पिक करता है।

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

समर्थित

  • ओरेकल लिनक्स संस्करण 7 से[98][99]
  • संस्करण 12 से एसयूएसई लिनक्स एंटरप्राइज़ सर्वर[100][101]
  • सिनोलॉजी डिस्कस्टेशन मैनेजर (डीएसएम) संस्करण 6.0 से[102]

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

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

यह भी देखें

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

टिप्पणियाँ

  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=193765’