UnionFS有什么用？AUFS的一些特性

AUFS是一種Union File System，所謂UnionFS就是把不同物理位置的目錄合并mount到同一個(gè)目錄中。UnionFS的一個(gè)最主要的應(yīng)用是，把一張CD/DVD和一個(gè)硬盤(pán)目錄給聯(lián)合 mount在一起，然后，你就可以對(duì)這個(gè)只讀的CD/DVD上的文件進(jìn)行修改（當(dāng)然，修改的文件存于硬盤(pán)上的目錄里）。

AUFS又叫Another UnionFS，后來(lái)叫Alternative UnionFS，后來(lái)可能覺(jué)得不夠霸氣，叫成Advance UnionFS。是個(gè)叫Junjiro Okajima（岡島順治郎）在2006年開(kāi)發(fā)的，AUFS完全重寫(xiě)了早期的UnionFS 1.x，其主要目的是為了可靠性和性能，并且引入了一些新的功能，比如可寫(xiě)分支的負(fù)載均衡。AUFS在使用上全兼容UnionFS，而且比之前的UnionFS在穩(wěn)定性和性能上都要好很多，后來(lái)的UnionFS 2.x開(kāi)始抄AUFS中的功能。但是他居然沒(méi)有進(jìn)到Linux主干里，就是因?yàn)長(zhǎng)inus不讓?zhuān)旧鲜且驗(yàn)榇a量比較多，而且寫(xiě)得爛（相對(duì)于只有3000行的union mount和10000行的UnionFS，以及其它平均下來(lái)只有6000行代碼左右的VFS，AUFS居然有30000行代碼），所以，岡島不斷地改進(jìn)代碼質(zhì)量，不斷地提交，不斷地被Linus拒掉，所以，到今天AUFS都還進(jìn)不了Linux主干（今天你可以看到AUFS的代碼其實(shí)還好了，比起OpenSSL好N倍，要么就是Linus對(duì)代碼的質(zhì)量要求非常高，要么就是Linus就是不喜歡AUFS）。

不過(guò)，好在有很多發(fā)行版都用了AUFS，比如：Ubuntu 10.04，Debian6.0, Gentoo Live CD支持AUFS，所以，也OK了。

好了，扯完這些閑話，我們還是看一個(gè)示例吧（環(huán)境：Ubuntu 14.04）

首先，我們建上兩個(gè)目錄（水果和蔬菜），并在這兩個(gè)目錄中放上一些文件，水果中有蘋(píng)果和蕃茄，蔬菜有胡蘿卜和蕃茄。

然后，我們輸入以下命令：

我們可以看到在./mnt目錄下有三個(gè)文件，蘋(píng)果apple、胡蘿卜carrots和蕃茄tomato。水果和蔬菜的目錄被union到了./mnt目錄下了。

我們來(lái)修改一下其中的文件內(nèi)容：

上面的示例，我們可以看到./mnt/apple的內(nèi)容改了，./fruits/apple的內(nèi)容也改了。

上面的示例，我們可以看到，我們修改了./mnt/carrots的文件內(nèi)容，./vegetables/carrots并沒(méi)有變化，反而是./fruits/carrots的目錄中出現(xiàn)了carrots文件，其內(nèi)容是我們?cè)?/mnt/carrots里的內(nèi)容。

也就是說(shuō)，我們?cè)趍ount aufs命令中，我們沒(méi)有指它vegetables和fruits的目錄權(quán)限，默認(rèn)上來(lái)說(shuō)，命令行上第一個(gè)（最左邊）的目錄是可讀可寫(xiě)的，后面的全都是只讀的。（一般來(lái)說(shuō)，最前面的目錄應(yīng)該是可寫(xiě)的，而后面的都應(yīng)該是只讀的）

所以，如果我們像下面這樣指定權(quán)限來(lái)mount aufs，你就會(huì)發(fā)現(xiàn)有不一樣的效果（記得先把上面./fruits/carrots的文件刪除了）：

現(xiàn)在，在這情況下，如果我們要修改./mnt/tomato這個(gè)文件，那么究竟是哪個(gè)文件會(huì)被改寫(xiě)？

可見(jiàn)，如果有重復(fù)的文件名，在mount命令行上，越往前的就優(yōu)先級(jí)越高。

你可以用這個(gè)例子做一些各種各樣的試驗(yàn)，我這里主要是給大家一個(gè)感性認(rèn)識(shí)，就不展開(kāi)試驗(yàn)下去了。

那么，這種UnionFS有什么用？

歷史上，有一個(gè)叫Knoppix的Linux發(fā)行版，其主要用于Linux演示、光盤(pán)教學(xué)、系統(tǒng)急救，以及商業(yè)產(chǎn)品的演示，不需要硬盤(pán)安裝，直接把CD/DVD上的image運(yùn)行在一個(gè)可寫(xiě)的存儲(chǔ)設(shè)備上（比如一個(gè)U盤(pán)上），其實(shí)，也就是把CD/DVD這個(gè)文件系統(tǒng)和USB這個(gè)可寫(xiě)的系統(tǒng)給聯(lián)合mount起來(lái)，這樣你對(duì)CD/DVD上的image做的任何改動(dòng)都會(huì)在被應(yīng)用在U盤(pán)上，于是乎，你可以對(duì)CD/DVD上的內(nèi)容進(jìn)行任意的修改，因?yàn)楦膭?dòng)都在U盤(pán)上，所以你改不壞原來(lái)的東西。

我們可以再發(fā)揮一下想像力，你也可以把一個(gè)目錄，比如你的源代碼，作為一個(gè)只讀的template，和另一個(gè)你的working directory給union在一起，然后你就可以做各種修改而不用害怕會(huì)把源代碼改壞了。有點(diǎn)像一個(gè)ad hoc snapshot。

Docker把UnionFS的想像力發(fā)揮到了容器的鏡像。你是否還記得我在介紹Linux Namespace上篇中用mount namespace和chroot山寨了一鏡像?，F(xiàn)在當(dāng)你看過(guò)了這個(gè)UnionFS的技術(shù)后，你是不是就明白了，你完全可以用UnionFS這樣的技術(shù)做出分層的鏡像來(lái)。

下圖來(lái)自Docker的官方文檔Layer，其很好的展示了Docker用UnionFS搭建的分層鏡像。

關(guān)于docker的分層鏡像，除了aufs，docker還支持btrfs, devicemapper和vfs，你可以使用 -s 或 –storage-driver= 選項(xiàng)來(lái)指定相關(guān)的鏡像存儲(chǔ)。在Ubuntu 14.04下，docker默認(rèn)Ubuntu的 aufs（在CentOS7下，用的是devicemapper，關(guān)于devicemapper，我會(huì)以以后的文章中講解）你可以在下面的目錄中查看相關(guān)的每個(gè)層的鏡像：

在docker執(zhí)行起來(lái)后（比如：docker run -it ubuntu /bin/bash ），你可以從/sys/fs/aufs/si_[id]目錄下查看aufs的mount的情況，下面是個(gè)示例：

你會(huì)看到只有最頂上的層（branch）是rw權(quán)限，其它的都是ro+wh權(quán)限只讀的。

關(guān)于docker的aufs的配置，你可以在/var/lib/docker/repositories-aufs這個(gè)文件中看到。

AUFS的一些特性

AUFS有所有Union FS的特性，把多個(gè)目錄，合并成同一個(gè)目錄，并可以為每個(gè)需要合并的目錄指定相應(yīng)的權(quán)限，實(shí)時(shí)的添加、刪除、修改已經(jīng)被mount好的目錄。而且，他還能在多個(gè)可寫(xiě)的branch/dir間進(jìn)行負(fù)載均衡。

上面的例子，我們已經(jīng)看到AUFS的mount的示例了。下面我們來(lái)看一看被union的目錄（分支）的相關(guān)權(quán)限：

rw表示可寫(xiě)可讀read-write。

ro表示read-only，如果你不指權(quán)限，那么除了第一個(gè)外ro是默認(rèn)值，對(duì)于ro分支，其永遠(yuǎn)不會(huì)收到寫(xiě)操作，也不會(huì)收到查找whiteout的操作。

rr表示real-read-only，與read-only不同的是，rr標(biāo)記的是天生就是只讀的分支，這樣，AUFS可以提高性能，比如不再設(shè)置inotify來(lái)檢查文件變動(dòng)通知。

權(quán)限中，我們看到了一個(gè)術(shù)語(yǔ)：whiteout，下面我來(lái)解釋一下這個(gè)術(shù)語(yǔ)。

一般來(lái)說(shuō)ro的分支都會(huì)有wh的屬性，比如 “[dir]=ro+wh”。所謂whiteout的意思，如果在union中刪除的某個(gè)文件，實(shí)際上是位于一個(gè)readonly的分支（目錄）上，那么，在mount的union這個(gè)目錄中你將看不到這個(gè)文件，但是read-only這個(gè)層上我們無(wú)法做任何的修改，所以，我們就需要對(duì)這個(gè)readonly目錄里的文件作whiteout。AUFS的whiteout的實(shí)現(xiàn)是通過(guò)在上層的可寫(xiě)的目錄下建立對(duì)應(yīng)的whiteout隱藏文件來(lái)實(shí)現(xiàn)的。

看個(gè)例子：

假設(shè)我們有三個(gè)目錄和文件如下所示（test是個(gè)空目錄）：

我們?nèi)缦耺ount：

現(xiàn)在我們?cè)跈?quán)限為rw的test目錄下建個(gè)whiteout的隱藏文件.wh.apple，你就會(huì)發(fā)現(xiàn)./mnt/apple這個(gè)文件就消失了:

上面這個(gè)操作和 rm ./mnt/apple是一樣的。

相關(guān)術(shù)語(yǔ)

?Branch– 就是各個(gè)要被union起來(lái)的目錄（就是我在上面使用的dirs的命令行參數(shù)）

?Branch根據(jù)被union的順序形成一個(gè)stack，一般來(lái)說(shuō)最上面的是可寫(xiě)的，下面的都是只讀的。

?Branch的stack可以在被mount后進(jìn)行修改，比如：修改順序，加入新的branch，或是刪除其中的branch，或是直接修改branch的權(quán)限

?Whiteout和Opaque

?如果UnionFS中的某個(gè)目錄被刪除了，那么就應(yīng)該不可見(jiàn)了，就算是在底層的branch中還有這個(gè)目錄，那也應(yīng)該不可見(jiàn)了。

?Whiteout就是某個(gè)上層目錄覆蓋了下層的相同名字的目錄。用于隱藏低層分支的文件，也用于阻止readdir進(jìn)入低層分支。

?Opaque的意思就是不允許任何下層的某個(gè)目錄顯示出來(lái)。

?在隱藏低層檔的情況下，whiteout的名字是’.wh.’。

?在阻止readdir的情況下，名字是’.wh..wh..opq’或者 ’.wh.__dir_opaque’。

相關(guān)問(wèn)題

看到上面這些，你一定會(huì)有幾個(gè)問(wèn)題：

其一、你可能會(huì)問(wèn)，要有文件在原來(lái)的地方被修改了會(huì)怎么樣？mount的目錄會(huì)一起改變嗎？答案是會(huì)的，也可以是不會(huì)的。因?yàn)槟憧梢灾付ㄒ粋€(gè)叫udba的參數(shù)（全稱(chēng)：User’s Direct Branch Access），這個(gè)參數(shù)有三個(gè)取值：

udba=none– 設(shè)置上這個(gè)參數(shù)后，AUFS會(huì)運(yùn)轉(zhuǎn)的更快，因?yàn)槟切┎辉趍ount目錄里發(fā)生的修改，aufs不會(huì)同步過(guò)來(lái)了，所以會(huì)有數(shù)據(jù)出錯(cuò)的問(wèn)題。

udba=reval– 設(shè)置上這個(gè)參數(shù)后，AUFS會(huì)去查文件有沒(méi)有被更新，如果有的話，就會(huì)把修改拉到mount目錄內(nèi)。

udba=notify– 這個(gè)參數(shù)會(huì)讓AUFS為所有的branch注冊(cè)inotify，這樣可以讓AUFS在更新文件修改的性能更高一些。

其二、如果有多個(gè)rw的branch（目錄）被union起來(lái)了，那么，當(dāng)我創(chuàng)建文件的時(shí)候，aufs會(huì)創(chuàng)建在哪里呢？aufs提供了一個(gè)叫create的參數(shù)可以供你來(lái)配置相當(dāng)?shù)膭?chuàng)建策略，下面有幾個(gè)例子。

create=rr | round?robin輪詢。下面的示例可以看到，新創(chuàng)建的文件輪流寫(xiě)到三個(gè)目錄中

reate=mfs[:second] | most?free?space[:second]選一個(gè)可用空間最好的分支?？梢灾付ㄒ粋€(gè)檢查可用磁盤(pán)空間的時(shí)間。

create=mfsrr:low[:second]選一個(gè)空間大于low的branch，如果空間小于low了，那么aufs會(huì)使用 round-robin 方式。

更多的關(guān)于AUFS的細(xì)節(jié)使用參數(shù)，大家可以直接在Ubuntu 14.04下通過(guò)man aufs來(lái)看一下其中的各種參數(shù)和命令。

AUFS的性能

AUFS的性能慢嗎？也慢也不慢。因?yàn)锳UFS會(huì)把所有的分支mount起來(lái)，所以，在查找文件上是比較慢了。因?yàn)樗闅v所有的branch。是個(gè)O(n)的算法（很明顯，這個(gè)算法有很大的改進(jìn)空間的）所以，branch越多，查找文件的性能也就越慢。但是，一旦AUFS找到了這個(gè)文件的inode，那后以后的讀寫(xiě)和操作原文件基本上是一樣的。

所以，如果你的程序跑在在AUFS下，open和stat操作會(huì)有明顯的性能下降，branch越多，性能越差，但是在write/read操作上，性能沒(méi)有什么變化。

IBM的研究中心對(duì)Docker的性能給了一份非常不錯(cuò)的性能報(bào)告（PDF）《An Updated Performance Comparison of Virtual Machinesand Linux Containers》

我截了兩張圖出來(lái)，第一張是順序讀寫(xiě)，第二張是隨機(jī)讀寫(xiě)?；緵](méi)有什么性能損失的問(wèn)題。而KVM在隨機(jī)讀寫(xiě)的情況也就有點(diǎn)慢了（但是，如果硬盤(pán)是SSD的呢？）

順序讀寫(xiě)

隨機(jī)讀寫(xiě)