戳藍字“CSDN云計算”關注我們哦！

技術頭條：干貨、簡潔、多維全面。更多云計算精華知識盡在眼前，get要點、solve難題，統統不在話下！

隨著Docker 容器技術的不斷發展和業內對Docker 的使用不斷深入，大家已經不再滿足于對Docker 的基本使用。?把玩Docker 多年的老司機應該或多或少都會遇到過一些Docker 存儲方面的問題，比如因為宿主機文件系統和Docker存儲類型不兼容引起的問題，或者使用AUFS 出現文件復制慢等問題，存儲問題每次遇到都要心里一緊。

?

Docker 存儲類的問題在排查上往往比較復雜，有過Docker 存儲類問題排查經驗的同學應該都有體會。每當遇到此類的問題筆都有一股想找Docker 公司理論的沖動，不是說好的?” build once run anywhere” 嗎？

?

筆者自己所在的團隊也曾數次遇到關于Docker 存儲的問題，每次團隊內的成員基本都是避之不及，生怕會由自己處理(怕掉坑里)。為此筆者專門理了一下Docker 存儲類的問題的復雜點，發現這里面很大一部分其實是因為問題處理人員對Docker 的存儲類型、存儲原理不了解造成的，為此我們專門整理了一份Docker 選型方面的避坑指南，供大家參考，希望可以幫助到大家。

?

Docker 存儲概述

?

我們知道，每個Docker?容器里面都有一個自己的文件系統，Docker 在運行容器時需要進行文件系統的創建，這樣rootfs?才能進行掛載。

?

Bootfs 也稱引導文件系統，位于Docker?鏡像和Docker 容器的最底層。bootfs 中主要包含兩個部分：bootloader和kernel，bootloader 用于引導加載內核，當內核加載到內存中后bootfs 的使命就完成了，接下來bootfs會被卸載掉。rootfs?中包含了一些linux中標準的目錄和文件，包括：/dev/設備文件目錄、/proc/進程信息目錄、/bin/二進制文件目錄、/etc/配置文件目錄等。

?

眾所周知，Docker 存儲的核心是鏡像的分層機制，鏡像分層的一大好處是鏡像之間可以進行繼承，也正是因為這個特性我們可以借助基鏡像定制化的構建我們需要的應用鏡像。

?

?

Docker官方在版本1.10 時引入一個新的可尋址的存儲模型，了解過Docker 存儲這方面的同學應該知道在Docker1.10之前Docker 鏡像的管理是使用的隨機的UUID管理，Docker1.10之后已經使用安全內容hash取代了隨機UUID進行鏡像的管理。同時，考慮到已經有很多用戶在使用UUID的鏡像管理方式，Docker 官方專門針對這個改動提供了遷移工具，幫助大家將已經存在的鏡像遷移到新的模型之上。

?

我們知道，一個有眾多版本的鏡像的所有鏡像占據的空間可能比單個版本的鏡像占用的空間多不了多少(比如一個nginx鏡像有500MB，根據配置的不同我們保存了10個版本，10個版本占用的空間一般和一個nginx鏡像占用的空間接近，遠低于10個鏡像空間的總和)。多個版本占用的空間之所以沒有明顯增加是由于Docker 容器、鏡像可以共享底層的基礎文件系統層，雖然鏡像的個數很多，但是他們占據的共享鏡像層在磁盤中只存在一份，每個容器只需要在自己的最上層加上一個自己獨有的可讀可寫層就可以正常使用了，因為這種存儲機制的存在大大提高了Docker 鏡像存儲的效率。這種模式的主要機制就是分層模型將不同的目錄掛載到了同一個虛擬文件系統之上，通過下面這個圖可以很好的理解這種模式。

?

?

?

上文中我們提到docker 的鏡像是分層的，但我們沒有說這部分的功能具體是由哪一部分實現的。其實不僅分層鏡像，包括每個Docker 容器的可讀寫層都是由Docker 的存儲方式負責管理的。

?

接觸容器比較早的同學可能還記得，Docker 在最初的時候只能在支持AUFS的文件系統的操作系統上運行，而當時在眾多操作系統中Ubuntu 已經率先提供了對AUFS的支持，因此最開始玩Docker 的同學使用的linux發行版都是Ubuntu系列的發行版。

?

但是由于AUFS 未能加入Linux 內核，成為linux發行版的標配，因此為了尋求兼容性和擴展性，Docker?在內部通過graphdriver 這樣一種機制以一種可以擴展的方式實現了對不同文件的系統的兼容(實際使用中可能發現有些版本還是會存在一些兼容性的問題)。

?

Docker 目前支持的驅動類型包括：AUFS、Device mapper、Btrfs、OverlayFS和ZFS(較新)，這些驅動存在一個共同點，那就是都使用了寫時復制技術。下面我們逐個看下這種存儲驅動的特性以及在使用中可能會遇到的問題。

?

AUFS?存儲驅動

?

1.?Union File System

?

UnionFS(Union File System簡稱)是一種為Linux、FreeBSD?等操作系統而設計的，可以把其他文件系統聯合到一個掛載點的文件系統服務。

簡單說來聯合文件系統就是將不同的目錄掛載到同一個虛擬機文件系統下的文件系統。這種文件系統的一大特點就是可以一層層的疊加修改文件，除了最上面的一層之外無論底下有多少層都是只讀的，只有最上層的文件系統是可以寫的。

UnionFS 使用分支(branch)對不同文件系統的文件(包含目錄)進行覆蓋，從而最終形成一個單一的文件系統，也就是我們直接操縱的文件系統。UnionFS 使用的這些分支要么是只讀的，要么是讀寫的，分支的這種特性決定了當我們對虛擬后的聯合文件系統中寫入數據的時候，數據被寫到了一個新的文件中。這樣看來我們似乎可以操作這個虛擬文件系統中的任何的文件，但其實我們并未改變原來的文件，導致這種情況出現的原因是UnionFS使用了寫時復制(copy-on-write)這樣一種資源管理技術。

寫時復制也稱隱式共享(此名稱可能較少見)，寫時復制是一種可以對可修改資源實現高效復制的資源管理技術。它的核心的設計思想是，如果一個數據資源是重復的，沒有做過任何的修改，這個時候不需要創建新的資源，而是讓新舊實例都去共享這僅有一份的資源。當需要對資源進行數據的增加或者修改的時候才會進行新資源的創建。從上面的寫時復制的原理中我們即可看出，通過這種資源共享的方式我們可以省掉對未修改資源的復制，從而為我們帶來效率的提升。

?

2.?AUFS

?

AUFS 全稱為Advanced Multi-Layered Unification Filesystem，是一種聯合文件系統，是一種文件級的存儲驅動，出于對可靠性和性能的考慮，AUFS 對UnionFS1.x 進行了整個的重寫，并且在重寫過程中還引入了一些新的功能特性，比如對于可寫的分支添加了負載均衡的功能。不僅僅是AUFS借鑒UnionFS，UnionFS也會去借鑒AUFS，比如UnionFS 2.x中借鑒了AUFS的一些實現。

?

有些同學可能會問，存儲驅動類型這么多，為什么Docker 最開始選擇AUFS作為自己的存儲驅動？ 筆者個人認為是因為AUFS具備的以下幾個優勢：快速啟動容器、高效利用存儲、高效利用內存。

?

當我們需要對一個文件進行修改時，AUFS 會為目的文件創建一個文件副本，具體是從包含該文件的只讀層使用寫時復制技術將文件復制到最上面的可寫層。需要注意的是，當我們修改完文件之后修改后的文件是保存在最上層的可寫層的，下面的只讀層的文件并未被修改。

?

3.?Docker 對AUFS的使用

?

在Docker 體系中，我們熟知的最上層的讀寫層就是容器，除最上層之外的下面的那些層就是鏡像。

?

?

?

4.?AUFS 避坑

?

了解AUFS 存儲驅動的優勢和劣勢可以幫助我們更好的對存儲驅動進行選型，同時也可在很大程度上幫助我們排查AUFS 存儲驅動方面相關的問題。

?

好，我們先看下AUFS 作為Docker 存儲驅動的優勢，以便選擇更合適的使用場景：

?

(1)?得益于AUFS 高效的目錄掛載機制，Docker 可以很快的創建容器。AUFS 的讀寫效率很高，和直接在Docker 容器所在宿主機上的讀寫接近。和虛擬服務器相比，AUFS讀寫性能優于KVM，包括順序讀寫和隨機讀寫兩個方面。除此磁盤的高效使用之外，Docker的AUFS存儲驅動也可以對內存進行非常高效的使用。

?

(2)?相比一些出現較晚的Docker 存儲驅動，Docker AUFS存儲驅動性能相對比較穩定，并且AUFS目前已經有很多的生產部署實踐，另外AUFS 在社區生態方面也得到大量的支持。

?

下面我們再看下AUFS 作為Docker 存儲驅動存在的坑：

?

(1)?AUFS 是Docker 第一個支持的存儲驅動，但AUFS 目前仍未加入linux系統的內核主線，比如RedHat系列(包括CentOS)目前還無法直接使用AUFS。

?

(2)?AUFS 目前不支持重命名的系統調用，這個會導致我們在執行拷貝和解除連接時失敗。

?

(3)?我們知道AUFS 文件系統中每個源目錄都會對應一個分支文件的掛載過程其實就是對不同分支的一個聯合操作，當出現相同內容的不同分支時會進行上下層的覆蓋。但是當我們寫入大文件的時候，比如大的存儲日志信息的文件或者存儲數據庫數據庫的文件，動態掛載多個路徑的存在會使分支越來越多，進而會導致文件查找的性能越來越差，尤其是當文件存在于較低的層時，問題會更加嚴重。

小結：AUFS 存儲驅動建議在大并發但少I/O的場景下進行使用。

?

Device mapper

?

1.?Device Mapper 原理

?

部署Docker 環境的時候一般都會要求Linux 內核版本最低為3.10，似乎Docker 運行需要的存儲驅動是從linux 內核3.10 這個版本才進行引入的，但實際早在linux 內核版本2.6的時候DeviceMapper就已經被引入。

?

DeviceMapper 作為內核的一部分主要提供了邏輯卷管理和通用設備映射的功能，為了實現系統中的塊設備管理提供了一個高度模塊化的內核的架構。

?

在深入了解DeviceMapper 之前我們需要先了解下DeviceMapper 中三個比較重要的概念：Mapped Device、Mapping Table和Target Device。

?

Mapped Device 并不是一個實際的設備，并沒有實際的物理硬件和它一一對應，相反Mapped?Device?是一個邏輯上的抽象設備，簡單說來，可以將其理解成為內核向外提供的邏輯設備。Mapped?Device 通過另一個對象Mapping Table 和Target Device 建立映射關系。

?

Mapping Table 中包含Mapped Device 邏輯的起始地址、地址范圍以及Target Device 代表的物理設備的地址偏移量和Target 的類型信息，需要注意的是地址和偏移量單位為扇區，即512字節。

?

????????????

?

Target?Device 簡單說來就是Mapped Device 這個邏輯設備所映射到的一個物理設備。

?

Device Mapper 是塊級別的存儲驅動，所有的操作都是對存儲塊進行直接的操作，這方面和上文中講的AUFS不同(AUFS 是文件級的存儲，所有的操作都是對文件進行直接的操作)。

?

在使用Device Mapper 時，Device Mapper 會先在塊設備上創建一個資源池，然后接下來會在新建的資源池上添加一個沒有文件系統的基本設備，我們所有的容器鏡像都是這個設備的快照，我們的Docker容器是鏡像的快照。因此我們在Docker 容器中看到的文件系統系統其實是Device Mapper 資源池上基本設備上的文件系統的快照，實際上并沒有為我們的Docker 容器進行空間的分配。

?

理解Device Mapper 的工作機制，還需要明白用時分配。用時分配是指，當我們需要寫入一個文件時，我們需要為新文件分配新的存儲塊并，分配好存儲塊后才能進行數據的寫入。

?

當我們需要去修改容器中已經存在的文件時，這個時候Device Mapper 借助寫時復制技術為容器分配存儲塊空間，然后Device Mapper 將需要修改的數據拷貝到容器快照中前面新建的塊里面，之后才會對文件中的數據進行修改。

??

值得一提的是，Device Mapper 存儲驅動默認會創建一個100GB 文件，包含Docker 容器和Docker 鏡像，需要注意的默認情況下每個容器的大小都被限制在10GB的卷以內，但可以進行自定義的設置，具體結構如下圖：

?

?

?

另外Docker 存儲驅動的信息可以通過命令docker info 或者dmsetup ls 進行查看：

?

[root@localhost ~]#?docker info

Containers: 11

?Running: 0

?Paused: 0

?Stopped: 11

Images: 6

Server Version: 1.10.3

Storage Driver: devicemapper

?Pool Name: docker-8:3-404820673-pool

?Pool Blocksize: 65.54 kB

?Base Device Size: 10.74 GB

?Backing Filesystem: xfs

?Data file: /dev/loop0

?Metadata file: /dev/loop1

?Data Space Used: 12.51 GB

?Data Space Total: 107.4 GB

?Data Space Available: 82.06 GB

?Metadata Space Used: 10.18 MB

?Metadata Space Total: 2.147 GB

?Metadata Space Available: 2.137 GB

?Udev Sync Supported: true

?Deferred Removal Enabled: false

?Deferred Deletion Enabled: false

?Deferred Deleted Device Count: 0

?Data loop file: /var/lib/docker/devicemapper/devicemapper/data

?WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.

?Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata

?Library Version: 1.02.107-RHEL7 (2016-06-09)

Execution Driver: native-0.2

Logging Driver: journald

Plugins:

?Volume: local

?Network: null host bridge

Kernel Version: 3.10.0-327.36.1.el7.x86_64

Operating System: CentOS Linux 7 (Core)

OSType: linux

Architecture: x86_64

Number of Docker Hooks: 2

CPUs: 4

Total Memory: 1.781 GiB

Name: localhost.localdomain

ID: V7HM:XRBY:P6ZU:SGWK:J52L:VYOY:UK6L:TR45:YJRC:SZBS:DQRF:CFP5

WARNING: bridge-nf-call-iptables is disabled

WARNING: bridge-nf-call-ip6tables is disabled

Registries: docker.io (secure)

[root@localhost ~]# dmsetup ls

docker-8:3-404820673-pool(253:0)

?

2.?Device Mapper 避坑

?

(1)?Device Mapper 優勢

Device Mapper 的寫時復制機制的最小操作單元為64KB，塊級無論是大文件還是小文件都只需要復制需要修改的塊，并不復制整個文件，相比aufs存儲驅動和overlay存儲驅動的整個文件復制Device Mapper 的效率更高。

相比上文中我們說過的AUFS存儲驅動，Device Mapper 在文件系統兼容性方面較好，另外DeviceMapper存儲驅動只需要一個文件進行存儲，基本不會占用文件系統的inode。

?

(2)?Device Mapper 避坑

在內存使用方面，以Device?Mapper?作為存儲驅動時，啟動多少個容器就需要復制多少份文件到內存中，因為Device Mapper 不支持共享存儲，當有多個容器需要讀同一個文件的內容時，需要生成多個該文件的副本，在較多的容器進行啟動、停止的時候可能會出現磁盤溢出的情況。因此如果是容器密度高的業務場景下盡量不要部署到單臺主機上。?

每個容器每次在寫數據時都需要占用一個新的塊，由于每個存儲塊都需要借助存儲池進行分配，且寫的文件比較稀疏，盡管Device Mapper 的I/O利用率很高，但由于額外增加了VFS 開銷導致性能不好。在選擇存儲類型時需要著重注意下這一點，強烈建議根據自己的業務場景進行壓測后再進行選擇。

在實際使用中，如果我們為每個容器都進行塊設備的分配，當啟動多個容器時數據會從磁盤被多次加載到內存中，因此在這種場景下時內存消耗較大，在選型時需要注意。

當選用的宿主機為RHEL系列(包含CentOS)時，需要注意Device Mapper 是RHEL系列下的默認的存儲驅動，配置方式分為兩種模式：loop-lvm和direct-lvm。其中loop-lvm是默認的模式，loop-lvm 使用操作系統的層面的離散文件來構建精簡池。一般情況下生產環境推薦使用direct-lvm 模式，不建議使用默認的loop-lvm模式，經實際測試loop-lvm 的性能很難達到生產環境的要求

小結：Device Mapper 存儲驅動更適合在I/O密集的場景下進行使用。

?

OverlayFS 文件系統

?

1.?Overlay 原理

?

Overlay 存儲驅動的設計和AUFS 非常相似，也是一種聯合文件系統，同時也是一種文件級別的存儲驅動，但和AUFS不同的是Overlay 只有兩層(一個是upperdir，另一個是lowerdir，從二者的名字也可看出，upperdir 代表的是我們的容器層，lowerdir層代表的是我們的鏡像層)，而AUFS 有多層。相比AUFS Overlay 存儲驅動進入linux較晚(Linux 內核3.18之后才進行支持)。

?

當需要對文件進行修改時，需要借助寫時復制從只讀的lowerdir?層復制到可讀寫的upper dir層，然后再在upperdir?層中對文件進行修改，修改完成后的文件最終也是保存在組上面的upper層中。

?

?

2.?Ovrelay 避坑

?

在說Overlay 使用之前我們先看下它的優點，看下它適合的業務場景都有哪些。

?

(1)?從性能上來看，Overlay 存儲驅動要比Device Mapper 更好，速度更快。在某些情況下Overlay 的速度也比Btrfs存儲驅動快。由于Overlay 只有兩層，AUFS有多層，因此Overlay在速度上也比AUFS要快，減少操作延時。

?

(2)?Overlay 支持頁緩存的共享，這樣在多個容器在訪問同一個文件時可以共享一個頁緩存，從而提高內存使用效率。

?

下面我們再看下Overlay 在使用時需要注意的問題，注意避坑。

?

(1)?Overlay 存儲驅動出現較晚，目前生產環境部署的經驗相對較少，實際使用中需要解決的問題可能較多。

?

(2)?由于Overlay存儲驅動是文件級的，因此在對文件進行第一次的操作時需要將目標文件拷貝至最上面的讀寫層。

?

(3)?和其他的存儲驅動相比，Overlay 消耗inode 較多(我們有個容器云曾經出現過此種情況)，尤其是當我們環境中鏡像和容器較多時可能會觸發這個問題。為了解決這個問題，一般的建議方式是將目錄/var/lib/docker直接掛到某個單獨的文件系統中，這樣在一定程度上可以減少其他的文件對inode的占用。

?

上面提到的解決方式只是最常用的一種，除了這種方式，我們還有其他的解決方式，如Overlay 版本更換為Overlay2，Overlay2中已經解決了這個問題，在我們不再詳細描述。

?

(4)?除了上面說到的這些問題，Overlay 還存在POSIX的標準問題。Overlay的部分操作目前還不符合POSIX的標準。

?

(5)?最后需要注意的是Overlay 不支持rename系統調用，因此如果涉及到”copy”、”unlink ”的操作會出現失敗的情況。

?

小結：Overlay 存儲適合大并發但少I/O的場景。

?

Btrfs 文件系統

?

1.?Btrfs 原理

Btrfs 文件系統也稱B-tree 文件系統或者B-tree FS，Btrfs 是一種支持寫入復制的文件系統，由著名公司Oracle 進行研發，第一個穩定版本于2014年進行發布。Btrfs 文件系統的目標是取代linux中的ext3文件系統。

Btrfs 被很多人稱為下一代的寫時復制文件系統，和Overlay 相似也是基于文件級別的存儲，目前Btrfs已經并入linux內核。

和前面我們講到的Device Mapper 類似，Btrfs 可以對底層的設備進行直接的操作。

Btrfs 中有兩個重要的概念：subvolumes和snapshots，Btrfs 利用subvolumes和snapshots 管理Docker鏡像和Docker 容器的分層。

Subvolumes 是指Btrfs文件系統的一部分配置，或者也可稱為Btrfs文件系統的子文件系統，借助subvlolumes我們可以將一個大的文件系統劃分成若干個子文件系統，這些子文件系統共享底層的設備空間，在需要磁盤空間時便從底層設備中進行獲取，整個過程類似malloc()分配內存空間的過程。我們在使用Btrfs文件系統時，通常為了比較方便的使用設備的空間，Btrfs會將磁盤空間劃分成多個塊，需要注意的是劃分的這些塊的空間分配策略可以是不同的，比如，實際使用中我們可能會將一部分的塊用來存儲元數據，將另一部分的塊用來存儲我們實際的業務數據。

Snapshots 是subvolumes 的一個實時讀寫拷貝，其分配單位稱為塊，一般每個塊的大小為1GB。

Btrfs 文件系統將一個文件系統當成一個資源池來進行看待，這個資源池中會有多個子文件系統，我們可以動態的往資源池中進行子文件系統的添加。

?

?

2.?Btrfs避坑

?

先看下Btrfs 的優勢和適合的業務場景。

相比我們經常使用的ext4文件系統，Btrfs 文件系統在很多方面都做了改進，比如大家熟知的支持子卷、支持快照，除了這些功能，Btrfs文件系統還內置了壓縮和RAID的支持等功能。

相比傳統的文件系統，雖然Btrfs?引入了很多非常棒的特性，但它存在的問題也同樣的突出。

?

(1)?Btrfs 文件系統未引入頁緩存共享的機制，這就導致Btrfs 文件系統不適合在容器密度比較高的場景下進行使用。因為沒有頁緩存共享，多個容器在訪問相同的文件時需要對文件緩存多次。

?

(2)?Btrfs 文件系統中使用的small write 功能導致整個文件系統存在性能瓶頸。

?

(3)?Btrfs 文件系統寫數據的方式是journaling，接觸過的同學應該知道這種方式會在一定程度上影響順序寫的性能。

?

(4)?除上面的問題外，Btrfs 還存在一個很嚴重的問題：碎片化。如果不對碎片進行周期性的清理，碎片化會導致很嚴重的性能問題。幸運的是，在新版本的Btrfs中已經可以通過mount時指定autodefrag參數來解決這個問題了。

????

?小結：Btrfs 存儲不適合在容器密度高的平臺上進行使用。

?

下一代文件系統ZFS

?

1.?ZFS 原理

相比上文中我們說過的文件系統，ZFS 在很多方面做了革命性的改變，它從根本上改變了文件系統的管理機制。

ZFS 文件系統中已經不再使用卷管理，不再需要創建虛擬的卷，因此所有的設備都是直接放到統一的存儲池中進行管理的，即用存儲池的概念對物理存儲空間進行管理。

在容器環境中使用ZFS 文件系統時，會先從存儲池中為Docker鏡像的基礎層分配一個ZFS 文件系統，Docker 鏡像的其他層來自ZFS文件系統快照的克隆，當容器運行起來的時候會在Docker 鏡像的最頂層生成一個可寫層。

?

?

2.?ZFS 避坑

?

(1)?雖然ZFS 是下一代的文件系統，但由于相對較新，目前一般不推薦在生產環境中的Docker 使用ZFS存儲，可現在測試環境采坑積累經驗后再考慮上生產。

?

(2)?ZFS 最初并不是為普通的服務器設計的，而是為Sun Solaris服務器量身打造的，從實際經驗來看，如果需要部署在普通的服務器上，建議在正式使用前先壓測下內存的使用。

?

(3)?ZFS 有緩存的功能，但并不是適合每一種場景，一般只建議在高密度的場景下進行使用。

?

小結：ZFS 存儲適合PaaS服務密度較高的場景下使用。

?

?存儲總結

?

每種Docker 存儲驅動都有自己的適用場景，沒有好壞之分，只有合適之分。不同的存儲驅動在不同的應用場景下性能不同，例如，AUFS存儲驅動和Overlay存儲驅動工作在文件級別，因此在內存使用上比較高效，但是在進行大文件的讀寫時容器層所占據的空間會變的很大，這種場景下就更適合選用在高I/O負載下存在的優勢的存儲驅動，如Device Mapper、Btrfs、ZFS，對于容器層數較多，且寫小文件頻繁的場景下選擇Device Mapper 比選擇Overlay 作為存儲驅動更加合適。

因此建議結合自己的業務場景去選擇需要的存儲驅動，另外在選擇存儲驅動時需要結合自己宿主機的環境，注意避坑。

?

最后，為方便大家查詢不同操作系統發行版對應的推薦存儲驅動，筆者將Docker 官方給出的一個不同Linux 發行版的推薦表和不同存儲驅動對應所支持的文件系統表貼一下：

?

不同Linux 發行版推薦表：

?

Linux 發行版	推薦存儲驅動
Docker CE on Ubuntu	Aufs，devicemapper，overlay2(Ubuntu 14.04 或者更新的版本，Ubuntu 16.04 或者更高的版本)，overlay，zfs，vfs
Docker CE on Debian	Aufs、devicemapper，overlay2(限定版本Debian Stretch)，overlay，vfs
Docker CE on CentOS	Devicemapper，vfs
Docker CE on Fedora	Devicemapper，overlay2(Fedora 26 或者更新的版本，experimental)，overlay (experimental)，vfs

?不同存儲驅動支持文件系統對應表：

?

存儲驅動名稱	支持的文件系統
Overlay，overlay2	Ext4，xfs
aufs	Ext4，xfs
devicemapper	Direct-lvm
btrfs	Btrfs
zfs	zfs

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

推薦閱讀：

• 刷了一個半月算法題，我薪資終于Double了

• 掌聲送給TensorFlow 2.0！用Keras搭建一個CNN | 入門教程

• 中國AI開發者真實現狀：寫代碼這條路，會走多久？

• 520 這天，我突然意識到，她根本配不上我這么聰明的男人

• 厲害！女學生偷師男子學校，變身區塊鏈開發工程師

• 確實, 5G與物聯網離不開區塊鏈!

• Linux 之父：我就是覺得蘋果沒意思！| 人物志
  

真香，朕在看了！

總結

以上是生活随笔為你收集整理的Docker 存储选型，这些年我们遇到的坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。