Linux 開發者必須瞭解的常見檔案系統對比

wuyangchun發表於2017-02-28
Linux

本文將對Linux下常見的幾種檔案系統進行對比，包括ext2、ext3、ext4、XFS和Btrfs，希望能幫助大家更好的選擇合適的檔案系統。

內容來自於網上找的資料以及自己的一些經驗，能力有限，錯誤在所難免，僅供參考

歷史

檔案系統 建立者 建立時間 最開始支援的平臺
ext2 Rémy Card 1993 Linux,Hurd
XFS SGI 1994 IRIX, Linux, FreeBSD
ext3 Dr. Stephen C. Tweedie 1999 Linux
ZFS Sun 2004 Solaris
ext4 眾多開發者 2006 Linux
Btrfs Oracle 2007 Linux

從建立時間可以看出他們所處的不同時代，因為Btrfs的實現借鑑自ZFS，所以這裡也將ZFS列出來作為參考。

大小限制

檔案系統 最大檔名長度 最大檔案大小 最大分割槽大小
ext2 255 bytes 2 TB 16 TB
ext3 255 bytes 2 TB 16 TB
ext4 255 bytes 16 TB 1 EB
XFS 255 bytes 8 EB 8 EB
Btrfs 255 bytes 16 EB 16 EB

最大檔案和分割槽大小受格式化分割槽時所採用的塊大小（block size）所影響，塊越大，所支援的最大檔案和分割槽越大，也越可能浪費磁碟空間，上表列出的資料基於4K的塊大小。

程式碼規模

從程式碼規模可以看出檔案系統的功能豐富程度以及複雜度，下面列出的資料來自於kernel-4.1-rc8，只是簡單的用wc -l來統計，沒有過濾空行、註釋等。

檔案系統 原始檔(.c) 標頭檔案(.h)
ext2 8363 1016
ext3 16496 1567
ext4 44650 4522
XFS 89605 15091
Btrfs 105254 7933
  • Btrfs還在快速的開發過程中，程式碼行數可能還有比較大的變化
  • XFS和Btrfs都使用了B-tree

ext2

ext的優點是比較簡單，檔案比較少時效能較好，比較適合檔案少的場景，主要缺點如下

  • inode的數量是固定不變的，在格式化分割槽的時候可以指定inode和資料塊所佔空間的比例，但一旦格式化好，後續就沒法再改變了
  • 當塊大小為4K時，單個檔案大小不能超過2TB，分割槽大小不能超過16TB（目前硬碟大小一般都只有幾TB，所以也不是什麼大問題，）
  • 一個目錄下最多隻能有32000個子目錄
  • 由於目錄裡面儲存的檔案和子目錄都是以線性方式來組織的，所以遍歷目錄效率不高，尤其當目錄下檔案個數達到10K以上規模的時候，速度會明顯的變慢
  • 當底層的磁碟分割槽空間變大時（使用LVM時很常見），ext2沒法動態的擴充套件來使用增加的空間
  • 沒有日誌（Journal）功能，所以資料的安全性不高

ext3

ext3在ext2的基礎上實現了下面幾個功能，其它的都保持不變，即ext2的缺點ext3也有

  • 支援日誌（Journal）功能，資料的安全性較ext2有很大的提高
  • 當底層的分割槽空間變大時，ext3可以自動擴充套件來使用增加的空間
  • 使用HTree來組織目錄裡面的檔案和子目錄，使目錄下的檔案和子目錄數不再受效能限制（數量超過10K也不會有效能問題）

ext4

ext4借鑑了當前成熟的一些檔案系統技術，在ext3上增加了一些功能，並且對效能做了一些改進，主要變化如下

  • 當塊大小為4K時，支援的最大檔案和最大分割槽大小分別達到了16TB和1EB
  • 不再受32000個子目錄數的限制，支援不限數量的子目錄個數
  • 支援Extents，提高了大檔案的操作效能
  • 內部實現上支援一次分配多個資料塊，較ext3的效能有所提高
  • 支援延時分配（即支援fallocate函式）（fallocate是libc的函式，在不支援該功能的檔案系統上，libc會建立一個佔用磁碟空間檔案）
  • 支援線上快速掃描
  • 支援線上碎片整理（單個檔案或者整個分割槽）
  • 日誌（Journal）支援校驗碼（checksum），資料的安全性進一步提高
  • 支援無日誌（No Journaling）模式（ext3不支援該功能），這樣就和ext2一樣，消除了寫日誌對效能的影響
  • 支援納秒級的時間戳
  • 記錄了檔案的建立時間，由於相關的應用層工具還不支援，所以只能通過debug的方式看到檔案的建立時間

這裡是一個檢視檔案/etc/fstab建立時間的例子（檔案存在/dev/sda1分割槽上）：

dev@ubuntu:~$ ls -i /etc/fstab
10747906 /etc/fstab
dev@ubuntu:~$ sudo debugfs -R 'stat <10747906>' /dev/sda1
Inode: 10747906   Type: regular    Mode:  0644   Flags: 0x80000
Links: 1   Blockcount: 8
ctime: 0x5546dc54:6e6bc80c -- Sun May  3 22:41:24 2015
 atime: 0x55d1b014:8bcf7b44 -- Mon Aug 17 05:57:40 2015
 mtime: 0x5546dc54:6e6bc80c -- Sun May  3 22:41:24 2015
crtime: 0x5546dc54:6e6bc80c -- Sun May  3 22:41:24 2015
Size of extra inode fields: 28
EXTENTS: (0):46712815

Extents： 在最開始的ext2檔案系統中，資料塊都是一個一個單獨管理的，inode中存有指向資料塊的指標，檔案佔用了多少個資料塊，inode裡面就有多少個指標（多級），想象一下一個1G的檔案，4K的塊大小，那麼需要(1024 * 1024)/4=262144個資料塊，即需要262144個指標，建立檔案的時候需要初始化這些指標，刪除檔案的時候需要回收這些指標，影響效能。現代的檔案系統都支援Extents的功能，簡單點說，Extent就是資料塊的集合，以前一次分配一個資料塊，現在可以一次分配一個Extent，裡面包含很多資料塊，同時inode裡面只需要分配指向Extent的指標就可以了，從而大大減少了指標的數量和層級，提高了大檔案操作的效能。

inode數量固定： 在ext2/3/4系列的檔案系統中，inode的數量都是固定的，壞處是如果存很多小檔案的話，有可能造成inode被用光，但磁碟還有很多剩餘空間無法被使用的情況，不過它也有一個好處，就是一旦磁碟損壞，恢復起來要相對簡單些，因為資料在磁碟上佈局相對要固定簡單。

xfs

和ext4相比，xfs不支援下面這些功能

  • 不支援日誌（Journal）校驗碼
  • 不支援無日誌（No Journaling）模式
  • 不支援檔案建立時間
  • 不支援資料日誌（data journal），只有後設資料日誌（metadata journal）

但xfs有下面這些特性

  • 支援的最大檔案和分割槽都達到了8EB
  • inode動態分配，從而不受inode數量的限制，再也不用擔心儲存大量小檔案導致inode不夠用的問題了。
  • 更大的xattr(extended attributes)空間，ext2/3/4及btrfs都限制xattr的長度不能超過一個塊（一般是4K），而xfs可以達到64K
  • 內部採用Allocation groups機制，各個group之間沒有依賴，支援併發操作，在多核環境的某些場景下效能表現不錯
  • 提供了原生的dump和restore工具，並且支援線上dump

btrfs

btrfs是一個和ZFS類似的檔案系統，支援的功能非常多，據說將來會替換ext4成為Linux下的預設檔案系統。這裡列舉一些重要的功能

  • 支援的最大檔案和分割槽達到了16EB
  • 支援COW（copy on write）
  • 針對小檔案和SSD做了優化
  • inode動態分配
  • 支援子分割槽（Subvolumes），子分割槽可以單獨掛載
  • 支援後設資料和資料的校驗（crc32）
  • 支援壓縮，去重
  • 支援多個磁碟和分割槽，可動態擴充套件
  • 支援LVM,RAID的功能（有了btrfs，就不再需要lvm和軟raid了）
  • 增量備份和恢復
  • 支援快照
  • 將ext2/3/4轉換成btrfs（反過來不行）

btrfs最大的缺點就是由於其COW的實現方式，導致碎片化問題比較嚴重，不太適合頻繁寫的場景，比如資料庫、虛擬機器的磁碟檔案等。不過大部分場合不需要擔心，btrfs有線上的碎片整理工具。

如何選擇

下表僅供參考

檔案系統 適用場景 原因
ext2 U盤 U盤一般不會存很多檔案，且U盤的檔案在電腦上有備份，安全性要求沒那麼高，由於ext2不寫日誌（journal），所以寫U盤效能比較好。當然由於ext2的相容性沒有fat好，目前大多數U盤格式還是用fat
ext3 對穩定性要求高的地方 有了ext4後，好像沒什麼原因還要用ext3，ext4現在的問題是出來時間不長，還需要一段時間變穩定
ext4 小檔案較少 ext系列的檔案系統都不支援inode動態分配，所以如果有大量小檔案需要儲存的話，不建議用ext4
xfs 小檔案多或者需要大的xttr空間，如openstack swift將資料檔案的後設資料放在了xttr裡面 xfs支援inode動態分配，所以不存在inode不夠的情況，並且xttr的最大長度可以達到64K
btrfs 沒有頻繁的寫操作，且需要btrfs的一些特性 btrfs雖然還不穩定，但支援眾多的功能，如果你需要這些功能，且不會頻繁的寫檔案，那麼選擇btrfs

另外，ext系列檔案系統內部結構相對簡單一些，出問題後恢復相對容易。

結束語

本篇沒有比較它們的效能，在通常情況下，他們之間沒有太大的效能差別，只有在特定的場景下，才能看出區別，如果對效能比較敏感，建議根據自己的使用場景來測試不同的檔案系統，然後根據結果來選擇。

相關文章