跳至內容

Btrfs

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
Btrfs
開發者SUSE、Meta、威騰電子、甲骨文公司、富士通、Red Hat
全稱Btrfs
發佈穩定版本：6.4，2023年6月
不穩定版本：6.4，2023年6月 (Linux)
結構
目錄內容B樹
檔案分配extents
限制
最大檔案尺寸16 EiB[1]
最大檔案數量264（每個子卷）
最長檔名255位元組
最大卷容量16 EiB[1]
檔案名字符集除'/'和NUL（'\0'）以外的所有字元
功能
日期記錄內容更改時間（mtime）[2]，屬性更改時間（ctime），訪問時間（atime）
日期解像度納秒
屬性POSIX，擴充檔案屬性
檔案系統權限POSIX，存取控制列表
透明壓縮是
透明加密否（計劃支援）
單一實例儲存（SIS）是（計劃支援，通過修補程式支援）
作業系統支援Linux , ReactOS[3]

Btrfs（B-tree檔案系統，通常念成Butter FS，Better FS或B-tree FS），一種支援寫入時複製（COW）的檔案系統，運行在Linux作業系統，採用GPL授權。Oracle於2007年對外宣佈這項計劃，並釋出原始碼，在2014年8月釋出穩定版。目標是取代當時在Linux上廣泛使用的ext3檔案系統，改善檔案系統的限制，增加單個檔案大小上限支援，總檔案系統大小支援以及檔案檢查支援。Btrfs還加入了可寫快照（writable snapshots）、快照的快照（snapshots of snapshots）、內建磁碟陣列（RAID），以及子卷（subvolumes）等進階檔案系統功能。在宣傳上，Btrfs的特點是「容錯、修復及易於管理」。[4]

歷史

[編輯]

Btrfs的核心數據結構——寫時複製B樹——最初是由IBM研究員Ohad Rodeh在2007年USENIX會議上提出的。Chris Mason當時是SUSE公司的ReiserFS工程師，後來加入了Oracle，並開始開發一種基於B樹的新檔案系統。

2008年，ext3和ext4檔案系統的主要開發者曹子德表示，雖然ext4有改進的功能，但它不是一個重大的進步；它使用了舊技術，是一個權宜之計。曹子德說，Btrfs是一個更好的方向，因為「它在可延伸性、可靠性和易管理性方面提供了改進」。Btrfs也有「一些與reiser3/4相同的設計思想」。

Btrfs 1.0版本具有最終確定的磁碟格式，於2008年底發佈，並於2009年被接受進入Linux內核主線。幾個Linux發行版開始在安裝過程中提供Btrfs作為根檔案系統的實驗性選擇。

2011年7月，Btrfs自動碎片整理和擦除功能被合併到Linux內核主線的3.0版本中。除了Oracle的Mason外，富士通的Miao Xie也貢獻了效能改進。2012年6月，Chris Mason離開Oracle加入Fusion-io，一年後又與Josef Bacik一起加入Facebook。在這兩家公司工作期間，Mason繼續他對Btrfs的工作。

2012年，兩個Linux發行版將Btrfs從實驗性狀態轉變為生產或支援狀態：3月份的Oracle Linux ，8月份的SUSE Linux Enterprise 。

2015年，Btrfs被採用為SUSE Linux Enterprise Server（SLE）12的預設檔案系統。

2017年8月，紅帽公司在Red Hat Enterprise Linux（RHEL）7.4的發佈說明中宣佈，不再計劃將Btrfs轉變為一個完全支援的功能（它自RHEL 6 beta以來一直作為「技術預覽」包含在內），並指出它將在RHEL 7發佈系列中保持可用。2019年5月，Btrfs從RHEL 8中移除。RHEL從RHEL 6中的ext4轉移到RHEL 7中的XFS。

2020年，Btrfs被選為Fedora 33桌面變體的預設檔案系統。

特性

[編輯]

特性列表

[編輯]

已實現

[編輯]
  • 連線碎片整理
  • 連線卷生長和收縮
  • 連線塊裝置增加和刪除
  • 連線負載均衡（塊裝置間的對象移動以達到平衡）
  • 檔案系統級的鏡像（類RAID-1）、條帶（類RAID-0）
  • 子卷（一個或多個單獨可掛載基於每個物流分區）
  • 透明壓縮（目前支援zlib、LZO和ZSTD (從 4.14 開始支援)）
  • 快照（唯讀和可寫，寫複製，子卷複製）
  • 檔案克隆
  • 數據和元數據的校驗和（目前是CRC-32C）
  • 就地轉換（帶轉返）ext3/4與ReiserFS
  • 唯讀儲存的聯合掛載，稱為檔案系統播種（唯讀儲存用作可寫 Btrfs 的寫時複製支援）
  • 用戶定義的事務
  • 塊丟棄支援
  • 傳送/接收（將快照之間的差異儲存為二進制流）
  • 帶外數據去重（需要用戶空間工具）
  • 能夠處理交換檔案和交換分區

已實現但不建議在生產環境中使用

[編輯]
  • 分層的每個子卷配額
  • RAID 5，RAID 6

計劃但尚未實現

[編輯]
  • 帶內數據去重
  • 線上檔案系統檢查
  • 最多六個奇偶校驗裝置的 RAID，超越了 RAID 5 和 RAID 6 的可靠性
  • 對象級 RAID 0，RAID 1 和 RAID 10
  • 透明加密
  • 持久讀寫快取（ L2ARC + ZIL，lvmcache 等）

克隆

[編輯]

Btrfs 提供了一個克隆操作，可以原子地建立一個檔案的寫時複製快照。這樣的克隆檔案有時被稱為 reflinks，因為它們與擬議的相關 Linux 內核系統呼叫有關。

在克隆時，檔案系統不會建立一個指向現有 inode 的新連結；相反，它會建立一個新的 inode，最初與原始檔案共用相同的磁碟塊。因此，克隆只能在同一個 Btrfs 檔案系統的邊界內工作，但是在某些情況下，自 Linux 內核 3.6 版本起，它可能會跨越子卷的邊界。實際的數據塊不會被複製；同時，由於 Btrfs 的寫時複製（CoW）特性，對任何克隆檔案的修改都不會在原始檔案中可見，反之亦然。

克隆不應與硬連結混淆，硬連結是將多個檔名與單個檔案關聯的目錄項。雖然硬連結可以被認為是同一檔案的不同名稱，但 Btrfs 中的克隆提供了最初共用所有磁碟塊的獨立檔案。

GNU coreutils 自 7.5 版本支援了這個 Btrfs 特性，通過 cp 命令的 --reflink 選項可以使用克隆功能。

除了數據克隆（ FICLONE ），Btrfs 還支援通過 FIDEDUPERANGE 進行帶外去重。這個功能允許兩個具有（甚至部分）相同數據的檔案共用儲存空間。

子卷和快照

[編輯]
Btrfs檔案系統的快照範例，由snapper管理

Btrfs子卷可視為一個單獨的POSIX檔案命名空間，向mount命令傳遞subvol或subvolid選項能夠單獨掛載相對應的子卷。其他子卷也可以通過掛載頂層子捲來訪問，此時其他子卷作為頂層子卷的子目錄供用戶訪問。[5]

子卷可以在檔案系統階層中的任何位置建立，也可以巢狀。巢狀的子卷在其父子卷中顯示為子目錄，類似於頂層子卷將其他子卷顯示為子目錄的方式。刪除一個子卷前，需要確保該子卷內不存在巢狀的子卷；因此，不能刪除頂層子卷。[6]

Btrfs檔案系統有一個預設子卷，最初設置為頂層子卷，在傳遞子卷選擇選項時預設掛載。預設子卷可以根據需要更改。[6]

Btrfs快照是一個與其他子卷共用數據（和元數據）的子卷，使用Btrfs的寫時複製實現，對快照的修改在原始子卷中不可見。可寫的快照可以視為原始檔案系統的一個副本。例如，要轉返到一個快照，可以解除安裝修改過的原始子卷，並將快照掛載到它的位置來實現。此時，也可以刪除原始子卷。[5]

Btrfs的寫時複製（CoW）特性意味着快照可以快速建立，同時剛剛建立時僅消耗很少的磁碟空間。由於快照是一個子卷，因此也可以建立巢狀的快照。對一個子卷進行快照不是一個遞歸的過程；因此，如果建立了一個子卷的快照，該子卷包含的每個巢狀子卷都會對映到同名的空目錄中。[5][6]

不能對一個目錄進行快照，只有子卷才能有快照。然而，有一種涉及跨越子卷的reflinks的解決方案：建立一個新的子卷，包含指向目標目錄內容的跨越子卷的reflinks。有了這個，就可以建立這個新卷的快照。[7][8]

Btrfs中的子卷與傳統的LVM邏輯卷非常不同。在LVM中，邏輯卷是一個單獨的塊裝置，而Btrfs子卷更類似於POSIX命名空間。[5]原始或副本中的任何一個在同一台電腦上掛載時，對btrfs進行dd或LVM快照會導致數據遺失。[9]

子卷發送與接收

[編輯]

給定任意一對子卷（或快照），Btrfs可以在它們之間生成二進制差異（通過使用btrfs send命令），稍後可以重放（通過使用btrfs receive），可以接收到另一個Btrfs檔案系統上。傳送-接收功能實際上建立（並應用）了將一個子卷轉換為另一個子卷所需的一組數據修改。[10][11]

傳送/接收功能可以與定期安排的快照一起使用，用於實現檔案系統複製的簡單形式，或用於執行增量備份。[10][11]

配額組

[編輯]
Btrfs配額組的範例

配額組可以對一個子卷或快照可能消耗的空間設定上限。新的快照最初不消耗配額，因為它的數據與其父卷共用，但之後會因為新檔案和對現有檔案的寫時複製操作而產生空間上的開銷。當配額功能啟用時，每個新的子卷或快照都會自動建立一個配額組。這些初始的配額組是可以分組（使用btrfs qgroup命令）成階層來實現配額池的構建塊。[12]

配額組只適用於子卷和快照，而不能對單個子目錄、用戶或用戶組強制執行配額。然而，可以通過使用不同的子捲來實現所有需要強制執行配額的用戶或用戶組。

原地轉換ext2/3/4和ReiserFS

[編輯]

由於在固定位置的元數據非常少，Btrfs可以適應後端儲存裝置的各種的空間佈局。btrfs-convert工具可以通過在其未分配空間中巢狀等效的Btrfs元數據——同時保留原始檔案系統的未修改副本，即原地轉換一個ext2/3/4或ReiserFS檔案系統。[13]

轉換需要建立整個ext2/3/4元數據的副本，而Btrfs檔案只是指向與ext2/3/4檔案使用的相同的塊。這使得在不可逆轉換之前，兩個檔案系統共用大部分塊。由於Btrfs的寫時複製特性，在所有檔案修改過程中，原始版本的檔案數據塊都保持不變。在不可逆轉換之前，只有在ext2/3/4中標記為空閒的塊才用於儲存新的Btrfs修改，這意味着轉換可以隨時復原轉換（但復原轉換會擦除在轉換為Btrfs後所做的任何更改）。[13]

所有轉換後的檔案都在Btrfs的預設子卷中。轉換工具會在一個單獨的子卷中建立包含對原始ext2/3/4檔案系統所有參照的稀疏檔案；這一檔案可以作為一個唯讀磁碟映像單獨掛載，允許同時訪問原始檔案系統和轉換後的檔案系統。刪除這個稀疏檔案會釋放原有檔案系統額外佔用的空間，並使轉換變得不可逆。[13]

在主線Linux內核的4.x版本中，就地ext3/4缺乏使用與測試，不能保證穩定性。[13]然而，該功能在2016年的btrfs-progs 4.6從頭重寫。Btrfs的就地檔案系統轉換功能自此宣佈穩定。

就地從ReiserFS轉換在2017年9月引入到Linux 4.13內核中。[14]

聯合掛載/種子裝置

[編輯]

在建立一個新的Btrfs時，可以使用一個已存在的Btrfs作為一個唯讀的「種子」檔案系統。[15]新的檔案系統將作為種子上的一個寫時複製覆蓋層，作為一種聯合掛載的形式。種子可以稍後從Btrfs中分離，在此之前，重平衡器將簡單地複製任何仍然被新檔案系統參照的種子數據，然後分離。Btrfs的主要貢獻者Mason認為這可能對Live CD安裝程式有用，它可以從光碟上的一個唯讀Btrfs種子啟動，在用戶繼續工作的同時，在後台將自己重平衡到安裝磁碟上的目標分區，然後彈出光碟以完成安裝而不需要重新啟動。[16]

加密

[編輯]

在2009年的採訪中，Chris Mason表示計劃為Btrfs增加加密支援。[17]目前，將加密與Btrfs結合使用的一種解決方案是使用諸如dm-crypt / LUKS之類的全盤加密機制在底層裝置上，並在該層之上建立Btrfs檔案系統。

截至2020年 (2020-Missing required parameter 1=month!)開發人員正在努力添加類似HMAC（SHA256）的鍵控雜湊。[18]

檢查和恢復

[編輯]

Unix系統傳統上使用fsck程式來檢查和修復檔案系統。這個功能是通過btrfs check程式實現的。從4.0版本開始，這個功能被認為是相對穩定的。然而，截至2023年6月，btrfs文件建議只有在「開發者或經驗豐富的用戶」建議時才使用其–repair選項。[19]截至2023年6月，SLE文件建議使用一個Live CD，執行一個備份，並只在最後的手段時使用修複選項。[20]

還有另一個工具btrfs-restore，可以用於從一個不可掛載的檔案系統中恢復檔案，而不修改損壞的檔案系統本身。[21][22]

在正常使用中，Btrfs基本上是自我修復的，並且可以在掛載時從損壞的根樹結構中恢復，這是因為預設每30秒向永久儲存重新整理數據。因此，孤立的錯誤會導致下一次掛載時最多30秒的檔案系統更改遺失。[23]這個周期可以通過在commit掛載選項中指定所需的值來更改。（以秒為單位）[24][25]

設計

[編輯]

Ohad Rodeh在2007年的USENIX提出的原始方案指出，廣泛用作資料庫的磁碟數據結構的B+樹不能有效地實現基於寫時複製的快照，因為它的葉子節點是連接在一起的：如果一個葉子被寫時複製，它的兄弟節點和父節點也必須如此，以及它們遞歸的兄弟和父節點，直到整個樹被複製。他建議使用一個修改過的B樹（沒有葉子連結），並且每個樹節點都有一個參照計數，但是儲存在一個專門的自由對映結構中，並且對樹的平衡演算法進行了一定的放鬆，使它們對寫時複製友好。結果將是一個適合高效能對象儲存的數據結構，可以執行寫時複製快照，同時保持良好的並行性。[26]

同年，在Oracle工作的Chris Mason開始了一個能夠使用這種數據結構的快照能力檔案系統的工作，幾乎完全採用這種數據結構——不僅用於元數據和檔案數據，而且遞歸地用於跟蹤樹本身的空間分配。這允許所有遍歷和修改都通過同一份代碼，只需要實現一次諸如寫時複製、校驗和和鏡像等特性，就可以在整個檔案系統的各個地方使用。[27]

Btrfs包含樹組成的幾層結構，所有樹都使用相同的B樹實現。樹儲存了按照136位元鍵排序的通用項。鍵中最高的64位元是一個唯一的「對象id」。中間8位元是一個項類型欄位，用於寫死到代碼中作為樹尋找中的項過濾器。「對象」可以有多個類型的多個項。剩下的64位元以類型特定的方式使用。因此，同一對象的項會在樹中彼此相鄰，按類型分組。通過選擇某些鍵值，對象可以進一步按照類型排列。[27][28]

內部樹節點只是鍵-指標對的平面列表，其中指標是子節點的邏輯塊號。葉節點包含打包到節點前面的項鍵和打包到節點末尾的項數據，在葉填充時兩者向彼此增長。[27]

檔案系統樹

[編輯]

在每個目錄中，目錄條目以「目錄項」的形式出現，它們的鍵值的最低位是它們檔名的CRC32C雜湊。它們的數據是一個「位置鍵」，或者是它指向的inode項的鍵。目錄項一起可以作為路逕到inode尋找的索引，但不用於迭代，因為它們按照它們的雜湊排序，有效地隨機排列它們。這意味着在一個大目錄中迭代和打開檔案的用戶應用程式將產生更多的磁碟尋道，因此在非相鄰檔案之間尋道——這是其他檔案系統中具有雜湊排序目錄的顯著效能損耗，例如ReiserFS，[29] ext3（啟用了Htree索引[30]）和ext4，它們都有微型加密演算法雜湊過的檔名。為了避免這個問題，Btrfs每個目錄條目都有一個"目錄索引項"，其項的鍵值被設置為一個每個目錄遞增的計數器。因此，對這些索引項的迭代大致按照儲存在磁碟上的相同順序返回條目。

在多個目錄中具有硬連結的檔案有多個參照項，每個父目錄一個。在同一目錄中具有多個硬連結的檔案將所有連結的檔名打包到同一個參照項中。這是一個設計缺陷，它將同一目錄中的硬連結數量限制為多少個可以放入單個樹塊中。（在預設塊大小為4 KiB、平均檔名長度為8位元組和每個檔名頭部為4位元組的情況下，這將少於350個。）觀察到大量使用同一目錄中多個硬連結的應用程式，在這個限制下會失敗，例如git、GNUS、GMame和BackupPC。 [31]這個限制最終被移除[32]（截至2012年10月已經合併[33]等待在Linux 3.7中發佈）通過引入溢位的"擴充參照項"來儲存不適合的硬連結檔名。

區段

[編輯]

檔案數據儲存在樹外的「區段」中，它們是連續的磁碟數據塊。區段塊預設大小為4 KiB，沒有頭部，只包含（可能壓縮的）檔案數據。在壓縮的區段中，單個塊不是單獨壓縮的；相反，壓縮流跨越整個區段。

檔案有「區段數據項」來跟蹤儲存其內容的區段。項的鍵值是區段的起始位元組偏移量。這使得在具有多個區段的大檔案中進行有效的尋找，因為任何給定檔案偏移量的正確區段可以用一個樹尋找來計算。

快照和克隆檔案共用區段。當一個大的這樣的區段的一小部分被覆蓋時，結果的寫時複製可能建立三個新的區段：一個小的包含被覆蓋的數據，和兩個大的包含覆蓋兩邊未修改的數據。為了避免重寫未修改的數據，寫時複製可能會建立「書籤區段」，或者只是現有區段的切片。區段數據項允許這樣做，通過包含一個到它們正在跟蹤的區段的偏移量：書籤項是那些具有非零偏移量的項。[28]

區段分配樹

[編輯]

「區段分配樹」充當檔案系統的分配對映。與其他樹不同，這個樹中的項沒有對象id。它們表示空間區域：它們的鍵值儲存了它們所代表的區域的起始偏移量和長度。

檔案系統將其分配的空間劃分為「塊組」，它們是可變大小的分配區域，交替地偏好元數據區段（樹節點）和數據區段（檔案內容）。數據和元數據塊組的預設比例是1:2。它們旨在使用奧爾洛夫塊分配器的概念來分配相關檔案，並通過在組之間留下空閒空間來抵抗碎片化。（然而，Ext3塊組有固定的位置，是根據檔案系統的大小計算出來的，而Btrfs中的塊組是動態的，並根據需要建立）每個塊組都與一個「塊組項「相關聯。檔案系統樹中的inode項包含對它們當前塊組的參照。[28]

「區段項」包含一個到佔用該區段的樹節點或檔案的反向參照。如果區段在快照之間共用，可能有多個反向參照。如果有太多的反向參照不能適合於項中，它們會溢位到單獨的「區段數據參照項「中。反過來，樹節點也有對它們所包含的樹的反向參照。這使得通過對一對括住該區域的偏移量進行B樹範圍尋找，然後跟隨反向參照，可以找到任何空間區域中的哪些區段或樹節點。對於重新定位數據，這允許從重新定位的塊進行有效的向上遍歷，快速找到並修復對這些塊的所有向下參照，而不必掃描整個檔案系統。這反過來又允許檔案系統有效地線上縮小、遷移和碎片整理其儲存。

區段分配樹，與檔案系統中的所有其他樹一樣，是寫時複製的。寫入檔案系統可能會導致一個級聯，其中改變了樹節點和檔案數據導致新的區段被分配，導致區段樹本身發生變化。為了避免建立一個反饋迴路，仍然在主記憶體中但尚未提交到磁碟的區段樹節點可以就地更新，以反映新複製的寫時複製區段。

從理論上講，由於區段分配樹充當了一個B樹版本的BSP樹，因此不需要傳統的可用空間點陣圖 。但實際上，為了加速分配，使用了頁大小點陣圖的紅黑樹。這些點陣圖被持久化到磁碟（從Linux 2.6.37開始，通過space_cache掛載選項[34]）作為特殊的區段，它們不受校驗和和寫時複製的影響。

校驗和樹和擦除

[編輯]
參見：靜默數據損壞

對數據和元數據都計算CRC-32C校驗和，並儲存為「校驗和樹」中的「校驗和項」。元數據校驗和有256位的空間，而數據校驗和最多可以有一個完整的節點（大約4 KB或更多）。Btrfs有為未來版本的檔案系統添加額外的校驗和演算法的計劃。[35][36]

每個連續的已分配塊都有一個校驗和項，每個塊的校驗和緊密地打包到項數據中。如果有太多的校驗和不能適合，它們會溢位到一個新葉子中的另一個校驗和項中。如果檔案系統在讀取一個塊時檢測到一個校驗和不匹配，在內部鏡像或RAID技術正在使用的情況下，它首先嘗試從另一個裝置 – 取得（或建立）這個塊的一個好的副本。 [37][38]

Btrfs可以通過觸發一個在後台執行的檔案系統擦除作業來啟動對整個檔案系統的線上檢查。擦除作業掃描整個檔案系統的完整性，並自動嘗試報告和修復它在沿途發現的任何壞塊。[37][39]

塊和裝置樹

[編輯]

塊裝置被劃分為1 GiB用於數據的物理塊，和256 MiB用於元數據的物理塊。[40]多個裝置上的物理塊可以鏡像或條帶化成一個單一的「邏輯塊」。這些邏輯塊被組合成一個單一的邏輯地址空間，供檔案系統的其餘部分使用。

「塊樹」通過將其中的每個裝置儲存為一個「裝置項」和邏輯塊作為「塊對映項」來跟蹤這一點，，提供了從邏輯到實體位址的正向對映。塊對映項可以是以下幾種類型之一：

single
1個邏輯到1個物理塊
dup
1個邏輯塊到1個塊裝置上的2個物理塊
raid0
N個邏輯塊到N≥2個裝置上的N≥2個物理塊
raid1
1個邏輯塊到N≥2個裝置中的2個物理塊，[41]與傳統的RAID 1不同，它有N個物理塊
raid1c3
1個邏輯塊到N≥3個裝置中的3個物理塊 ;

raid1c4 : 1個邏輯塊到N≥4個裝置中的4個物理塊 ; raid5 : N（對於N≥2）個邏輯塊到N+1個裝置上的N+1個物理塊，其中1個物理塊用作奇偶校驗 ; raid6 : N（對於N≥2）個邏輯塊到N+2個裝置上的N+2個物理塊，其中2個物理塊用作奇偶校驗 「N」是在分配塊時仍然有空閒空間的塊裝置的數量。如果N對於選擇的鏡像/對映不夠大，那麼檔案系統就有效地沒有空間了。

重定位樹

[編輯]

碎片整理、縮小和重新平衡操作需要重新定位區段。然而，對正在重新定位的區段進行簡單的寫時複製將破壞快照之間的共用並消耗磁碟空間。為了保持共用，使用一個更新和交換演算法，一個特殊的重定位樹作為受影響的元數據的臨時空間。首先將要重新定位的區段複製到它的目的地。然後，通過沿着受影響的子卷的檔案系統樹向上跟隨反向參照，逐漸更新指向舊區段的元數據，使其指向新的區段；任何新更新的項都儲存在重定位樹中。一旦更新完成，重定位樹中的項與受影響子卷中的對應項交換，然後丟棄重定位樹。[42]

超級塊

[編輯]

檔案系統中的所有樹——包括塊樹本身——都儲存在塊中，這會產生一個引導問題，當掛載檔案系統時。為了引導到一個掛載點，塊樹和根樹所屬的塊的實體位址列表儲存在超級塊中。[43]

超級塊鏡像儲存在固定位置：[44]每個塊裝置64 KiB處，以及64 MiB、256 GiB和1 PiB處的額外副本。當更新一個超級塊鏡像時，它的生成號遞增。在掛載時，使用生成號最高的副本。除了SSD模式，所有超級塊鏡像都同時更新；而在SSD模式下，為了提供一定程度的磨損平衡，超級塊鏡像之間交替更新。

參考資料

[編輯]
  1. ^ 1.0 1.1 Suse Documentation: Storage Administration Guide – Large File Support in Linux. SUSE. [2015-08-12]. （原始內容存檔於2016-03-04）. 
  2. ^ Jonathan Corbet. File creation times. LWN.net. 2010-07-26 [2015-08-15]. （原始內容存檔於2015-09-05）. 
  3. ^ ReactOS 0.4.1 Released. reactos.org. [11 August 2016]. （原始內容存檔於2016-08-17）. 
  4. ^ Introduction — BTRFS documentation. btrfs.readthedocs.io. [2023-11-30]. （原始內容存檔於2024-05-20）. 
  5. ^ 5.0 5.1 5.2 5.3 SysadminGuide – Btrfs documentation. kernel.org. [2013-10-31]. （原始內容存檔於2013-11-01）. 
  6. ^ 6.0 6.1 6.2 5.6 Creating Subvolumes and Snapshots [needs update]. oracle.com. 2013 [2013-10-31]. （原始內容存檔於2013-11-02）. 
  7. ^ UseCases – btrfs documentation. kernel.org. [2013-11-04]. （原始內容存檔於2018-02-05）. 
  8. ^ btrfs: allow cross-subvolume file clone. github.com. [2013-11-04]. （原始內容存檔於2021-02-13）. 
  9. ^ Gotchas - btrfs Wiki. btrfs.wiki.kernel.org. [2023-06-27]. （原始內容存檔於2017-06-14）. 
  10. ^ 10.0 10.1 Corbet, Jonathan, Btrfs send/receive, LWN.net, 2012-07-11 [2012-11-14], （原始內容存檔於2012-11-17） 
  11. ^ 11.0 11.1 5.7 Using the Send/Receive Feature. oracle.com. 2013 [2013-10-31]. （原始內容存檔於2013-11-02）. 
  12. ^ Jansen, Arne, Btrfs Subvolume Quota Groups (PDF), Strato AG, 2011 [2012-11-14], （原始內容存檔 (PDF)於2013-10-12） 
  13. ^ 13.0 13.1 13.2 13.3 Mason, Chris. Conversion from Ext3 (Btrfs documentation). kernel.org. 2015-06-25 [2016-04-22]. （原始內容存檔於2016-04-15）. 
  14. ^ btrfs-convert(8) — BTRFS Documentation. [2022-10-16]. （原始內容存檔於2023-10-31）. 
  15. ^ Seed device. [1 August 2017]. （原始內容存檔於12 June 2017）. 
  16. ^ Mason, Chris, Btrfs Filesystem: Status and New Features, Linux Foundation, 2012-04-05 [2012-11-16] [永久失效連結]
  17. ^ McPherson, Amanda. A Conversation with Chris Mason on BTRfs: the next generation file system for Linux. Linux Foundation. 2009-06-22 [2014-10-09]. （原始內容存檔於27 June 2012）. In future releases we plan to add online fsck, deduplication, encryption and other features that have been on admin wish lists for a long time. 
  18. ^ Sterba, David. authenticated file systems using HMAC(SHA256). Lore.Kernel.org. [25 April 2020]. （原始內容存檔於2023-09-20）. 
  19. ^ btrfs-check(8). btrfs.readthedocs.io. [2023-09-22]. （原始內容存檔於2022-01-21）. 
  20. ^ How to recover from BTRFS errors | Support | SUSE. www.suse.com. [2023-01-28]. （原始內容存檔於2023-10-12）. 
  21. ^ Restore - btrfs Wiki. btrfs.wiki.kernel.org. [2023-06-27]. （原始內容存檔於2023-03-09）. 
  22. ^ btrfs-restore(8) - Linux manual page. man7.org. [2023-01-28]. （原始內容存檔於2023-05-11）. 
  23. ^ Problem FAQ - btrfs Wiki. kernel.org. 2013-07-31 [2014-01-16]. （原始內容存檔於2023-03-09）. 
  24. ^ kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree). kernel.org. 2013-11-21 [2014-02-06]. 
  25. ^ Mount options - btrfs Wiki. kernel.org. 2013-11-12 [2014-01-16]. （原始內容存檔於2023-10-31）. 
  26. ^ Rodeh, Ohad. B-trees, shadowing, and clones (PDF). USENIX Linux Storage & Filesystem Workshop. 2007 [2023-09-22]. （原始內容存檔 (PDF)於2023-08-27）.  Also Rodeh, Ohad. B-trees, shadowing, and clones. ACM Transactions on Storage. 2008, 3 (4): 1–27. S2CID 207166167. doi:10.1145/1326542.1326544. 
  27. ^ 27.0 27.1 27.2 Aurora, Valerie. A short history of btrfs. LWN.net. 22 July 2009 [5 November 2011]. （原始內容存檔於2011-11-13）. 
  28. ^ 28.0 28.1 28.2 Mason, Chris. Btrfs design. Btrfs wiki. [8 November 2011]. （原始內容存檔於2012-04-25）. 
  29. ^ Reiser, Hans. Re: Ext2 directory index: ALS paper and benchmarks. ReiserFS developers mailing list. 2001-12-07 [2009-08-28]. （原始內容存檔於2023-06-27）. 
  30. ^ Mason, Chris. Acp. Oracle personal web page. [2011-11-05]. （原始內容存檔於2021-05-16）. 
  31. ^ Fasheh, Mark. btrfs: extended inode refs. 2012-10-09 [2012-11-07]. （原始內容存檔於2013-04-15）. 
  32. ^ Torvalds, Linus. Pull btrfs update from Chris Mason. git.kernel.org. 2012-10-10 [2012-11-07]. （原始內容存檔於2013-04-15）. 
  33. ^ Larabel, Michael. Benchmarks of the Btrfs Space Cache Option. Phoronix. 2010-12-24 [2012-11-16]. （原始內容存檔於2022-06-21）. 
  34. ^ Btrfs Wiki: Features. btrfs.wiki.kernel.org. 2013-11-27 [2013-11-27]. （原始內容存檔於2012-04-25）. 
  35. ^ FAQ - btrfs Wiki: Btrfs使用什么校验和函数？. The btrfs Project. [2020-11-22]. （原始內容存檔於2023-03-08）. 
  36. ^ 37.0 37.1 Bierman, Margaret; Grimmer, Lenz. How I Use the Advanced Capabilities of Btrfs. August 2012 [2013-09-20]. （原始內容存檔於2014-01-02）. 
  37. ^ Salter, Jim. Bitrot and Atomic COWs: Inside “Next-Gen” Filesystems. Ars Technica. 15 January 2014 [15 January 2014]. （原始內容存檔於2015-03-06）. 
  38. ^ Coekaerts, Wim. Btrfs Scrub – Go Fix Corruptions with Mirror Copies Please!. 2011-09-28 [2013-09-20]. （原始內容存檔於2013-09-21）. 
  39. ^ Glossary. Btrfs Wiki. [2021-07-31]. （原始內容存檔於2021-07-31）. 
  40. ^ Manpage/mkfs.btrfs. Btrfs Wiki. Profiles. [2021-07-31]. （原始內容存檔於2023-03-09）. 
  41. ^ Mason, Chris; Rodeh, Ohad; Bacik, Josef, BTRFS: The Linux B-tree Filesystem (PDF), IBM Research, 2012-07-09 [2012-11-12], （原始內容存檔 (PDF)於2020-02-03） 
  42. ^ Mason, Chris. Multiple device support. Btrfs wiki. 30 April 2008 [5 November 2011]. （原始內容存檔於20 July 2011）. 
  43. ^ Bartell, Sean. Re: Restoring BTRFS partition. linux-btrfs (郵寄清單). 2010-04-20 [2023-06-27]. （原始內容存檔於2012-06-27）. 

參見

[編輯]

外部連結

[編輯]

取自 "https://zh.wikipedia.org/w/index.php?title=Btrfs&oldid=82795852"