Linux有好多種件系統(tǒng)，但往往最受關(guān)注的是其中兩種：ext4和btrfs。XFS開(kāi)發(fā)者Dave Chinner近日聲稱，他認(rèn)為更多的用戶應(yīng)當(dāng)考慮XFS。他談到了為了解決XFS中最嚴(yán)重的可擴(kuò)展性問(wèn)題所做的工作，還談到了他認(rèn)為將來(lái)的發(fā)展走向。如果他說(shuō)的一點(diǎn)都沒(méi)錯(cuò)，接下來(lái)幾年我們?cè)赬FS方面有望看到更多的動(dòng)靜。
XFS經(jīng)常被認(rèn)為是適合擁有海量數(shù)據(jù)的用戶的文件系統(tǒng)。Dave表示，XFS非常適合扮演這個(gè)角色；它對(duì)許多工作負(fù)載而言向來(lái)表現(xiàn)不俗。以前往往問(wèn)題出在元數(shù)據(jù)寫(xiě)入方面；對(duì)生成大量元數(shù)據(jù)寫(xiě)入操作的工作負(fù)載缺少有力的支持歷來(lái)是該文件系統(tǒng)的薄弱環(huán)節(jié)。簡(jiǎn)而言之，元數(shù)據(jù)寫(xiě)入速度很慢，擴(kuò)展性欠佳，甚至只能適用于單個(gè)處理器。
速度到底有多慢？Dave制作了幾張幻燈片，顯示XFS與ext4相比的fs-mark結(jié)果。哪怕在單個(gè)處理器上，XFS的表現(xiàn)也要差得多（速度只有ext4的一半）；如果線程數(shù)量多達(dá)8個(gè)，情況完全變得更糟；但線程數(shù)量超過(guò)8個(gè)后，ext4也遇到了瓶頸，速度慢下來(lái)。就元數(shù)據(jù)頻繁變化的輸入/輸出密集型工作負(fù)載（解開(kāi)tarball文件就是個(gè)例子）而言，Dave表示ext4的速度可能比XFS快20倍至50倍。速度這么慢足以表明XFS確實(shí)存在嚴(yán)重問(wèn)題。
延遲的日志
結(jié)果表明問(wèn)題其實(shí)出在日志的輸入/輸出上。針對(duì)元數(shù)據(jù)的變化，XFS會(huì)生成大量的日志流量。在最糟糕的情況下，幾乎所有的實(shí)際輸入/輸出流量都用于日志——而不是用于用戶試圖想要寫(xiě)入的數(shù)據(jù)。多年來(lái)人們?cè)噲D采用多種辦法來(lái)解決這個(gè)問(wèn)題，比如對(duì)算法進(jìn)行重大改變，另外進(jìn)行許多重大的優(yōu)化和調(diào)整。不需要的一點(diǎn)是任何一種磁盤上格式變化，不過(guò)這在將來(lái)可能由于其他原因而在籌劃之中。
元數(shù)據(jù)密集型的工作負(fù)載最后可能會(huì)在很短的時(shí)間內(nèi)多次改變同一個(gè)目錄塊；那些改變每一次都會(huì)生成一個(gè)記錄，記錄必須寫(xiě)入到日志中。這正是導(dǎo)致巨大日志流量的根源。解決這個(gè)問(wèn)題的辦法從概念上來(lái)說(shuō)很簡(jiǎn)單：延遲日志更新，并且將針對(duì)同一目錄塊的變更合并到一個(gè)條目中。這些年來(lái)，以一種可擴(kuò)展的方式實(shí)際落實(shí)這個(gè)概念頗費(fèi)周折，但是現(xiàn)在取得了進(jìn)展；延遲的日志（delayed logging）將是3.3內(nèi)核中唯一得到支持的XFS日志模式。
實(shí)際的延遲日志技術(shù)主要由ext3文件系統(tǒng)借鑒而來(lái)。由于這種算法已知切實(shí)可行，證明它同樣適用于XFS所需的時(shí)間則短得多。除了性能上的優(yōu)點(diǎn)外，這一變化最終促使代碼數(shù)量減少。有誰(shuí)想詳細(xì)了解其工作原理，應(yīng)該會(huì)在內(nèi)核文檔樹(shù)中的filesystems/xfs-delayed-logging.txt找到所需內(nèi)容。
延遲日志是一大變化，但絕不是唯一的變化。日志空間預(yù)留快速路徑是XFS中非常熱門的路徑；現(xiàn)在它是無(wú)鎖的，不過(guò)慢速路徑現(xiàn)階段仍需要全局鎖。異步元數(shù)據(jù)寫(xiě)回代碼形成了非常分散的輸入/輸出，結(jié)果大幅降低了性能。現(xiàn)在，元數(shù)據(jù)寫(xiě)回在寫(xiě)出之前已被延遲和分類。用Dave的話來(lái)說(shuō)，這意味著文件系統(tǒng)在做輸入/輸出調(diào)度程序的工作。但是輸入/輸出調(diào)度程序處理的請(qǐng)求序列通常限制在128個(gè)條目，而XFS的延遲元數(shù)據(jù)寫(xiě)回序列可以有數(shù)千個(gè)條目，所以有必要在輸入/輸出提交之前在文件系統(tǒng)中完成分類操作。“活動(dòng)日志項(xiàng)”（Active log item）這種機(jī)制可以累計(jì)變化，并批量運(yùn)用變化，以此改進(jìn)（龐大的）分類日志項(xiàng)列表的性能。元數(shù)據(jù)緩存也被移到了頁(yè)面緩存器的外面，頁(yè)面緩存器往往會(huì)在不合適的時(shí)間收回頁(yè)面。等等。
諸文件系統(tǒng)相比如何？
那么，現(xiàn)在XFS的擴(kuò)展性如何？如果是一兩個(gè)線程，XFS的速度仍比ext4慢一點(diǎn)，但是它可以線性擴(kuò)展，支持多達(dá)8個(gè)線程，而ext4的情況比較糟，btrfs的情況要糟得多。對(duì)XFS來(lái)說(shuō)擴(kuò)展性方面的局限性如今出現(xiàn)在虛擬文件系統(tǒng)層核心中的鎖定上，根本不是出現(xiàn)在針對(duì)特定文件系統(tǒng)的代碼上。現(xiàn)在即使對(duì)一個(gè)線程來(lái)說(shuō)，目錄遍歷速度也更快，對(duì)8個(gè)線程來(lái)說(shuō)，速度快得多。他表示，這些并不是btrfs開(kāi)發(fā)人員可能展示給人的那種結(jié)果。
現(xiàn)在空間分配方面的可擴(kuò)展性要比ext4快“幾個(gè)數(shù)量級(jí)”。這是由于3.2內(nèi)核中添加了“bigalloc”特性而引起的變化，如果使用了足夠大的塊，這項(xiàng)特性可以將ext4在空間分配方面的可擴(kuò)展性提高兩個(gè)數(shù)量級(jí)。遺憾的是，該特性還將小文件的空間使用量增加了同樣數(shù)量，以至于需要160GB來(lái)存放內(nèi)核樹(shù)。bigalloc并不是很適合ext4的另外一些選項(xiàng)，而且需要管理員回答復(fù)雜的配置問(wèn)題；在創(chuàng)建文件系統(tǒng)時(shí)，管理員必須考慮文件系統(tǒng)在整個(gè)使用壽命期間將如何使用。Dave表示，ext4存在架構(gòu)方面的不足——尤其是使用位圖來(lái)用于跟蹤空間，這是上世紀(jì)80年代的文件系統(tǒng)存在的典型問(wèn)題。它根本無(wú)法擴(kuò)展，成為真正超大的文件系統(tǒng)。
btrfs中的空間分配甚至比ext4還要來(lái)得慢。Dave表示，問(wèn)題主要出在閑置空間緩存的走查，目前這是處理器密集型的操作。這不是btrfs中的架構(gòu)問(wèn)題，所以它應(yīng)該有望得到解決，但需要做一番優(yōu)化工作。
Linux文件系統(tǒng)的未來(lái)
這方面有何進(jìn)展？現(xiàn)階段，XFS中的元數(shù)據(jù)性能和可擴(kuò)展性可以被認(rèn)為是已得到解決的問(wèn)題。現(xiàn)在性能瓶頸出現(xiàn)在虛擬文件系統(tǒng)（VFS）層，所以需要在這方面開(kāi)展下一輪工作。但是未來(lái)面臨的一大挑戰(zhàn)在于可靠性方面；這可能需要XFS文件系統(tǒng)作出一些相當(dāng)大的變化。
可靠性不僅僅是不丟失數(shù)據(jù)這么簡(jiǎn)單——但愿XFS在這方面已經(jīng)做得很到位，這在將來(lái)其實(shí)是個(gè)可擴(kuò)展性問(wèn)題。讓數(shù)千兆兆字節(jié)（PT）的文件系統(tǒng)下線、運(yùn)行一款文件系統(tǒng)檢查和修復(fù)工具，這根本不切實(shí)際；將來(lái)，這項(xiàng)工作其實(shí)需要在線進(jìn)行。這就需要把成熟可靠的故障檢測(cè)機(jī)制融入到文件系統(tǒng)當(dāng)中，以便可以實(shí)時(shí)驗(yàn)證元數(shù)據(jù)正確無(wú)誤。其他一些文件系統(tǒng)也在實(shí)施驗(yàn)證數(shù)據(jù)的機(jī)制，但是這似乎超出了XFS的范圍。Dave表示，數(shù)據(jù)驗(yàn)證工作最好是在存儲(chǔ)陣列層面或應(yīng)用程序?qū)用嫱瓿伞?/p>
“元數(shù)據(jù)驗(yàn)證”意味著，讓元數(shù)據(jù)自我描述，保護(hù)文件系統(tǒng)，防范被存儲(chǔ)層指錯(cuò)方向的寫(xiě)入。添加校驗(yàn)和技術(shù)還不夠——核驗(yàn)和只能證明現(xiàn)有的是被寫(xiě)入的。以適當(dāng)方式自我描述的元數(shù)據(jù)能夠檢測(cè)寫(xiě)入到錯(cuò)誤地方的塊，并且?guī)椭匦陆M裝完全壞掉的文件系統(tǒng)。它還能防止“"reiserfs問(wèn)題”，即文件系統(tǒng)的修復(fù)工具被過(guò)時(shí)的元數(shù)據(jù)或存儲(chǔ)在待修復(fù)的文件系統(tǒng)中的文件系統(tǒng)映像里面的元數(shù)據(jù)搞糊涂。
讓元數(shù)據(jù)可以自我描述需要作出許多變化。每個(gè)元數(shù)據(jù)塊將包含文件系統(tǒng)的UUID；每個(gè)塊中還有塊和索引節(jié)點(diǎn)（inode）的編號(hào)，那樣文件系統(tǒng)就能驗(yàn)證元數(shù)據(jù)來(lái)自預(yù)期的地方。將來(lái)會(huì)有檢驗(yàn)和機(jī)制，用來(lái)檢測(cè)受到損壞的元數(shù)據(jù)塊，還會(huì)有所有者標(biāo)識(shí)符，用來(lái)將元數(shù)據(jù)與歸屬的索引節(jié)點(diǎn)或目錄關(guān)聯(lián)起來(lái)。反向映射分配樹(shù)將讓文件系統(tǒng)可以迅速確認(rèn)任何某個(gè)塊屬于哪個(gè)文件。
不用說(shuō)，目前的XFS磁盤上格式并不提供存儲(chǔ)所有這些額外數(shù)據(jù)的機(jī)制。這意味著磁盤上格式會(huì)有變化。據(jù)Dave聲稱，不打算提供任何形式的向前或向后格式兼容；格式變化將是真正重大的變化。開(kāi)展這項(xiàng)工作是為了便于完全自由地設(shè)計(jì)一種長(zhǎng)期服務(wù)于XFS用戶的新格式。雖然正在改變格式來(lái)添加上述的可靠性功能，但是開(kāi)發(fā)人員也會(huì)為目錄結(jié)構(gòu)中的d_type、NFSv4版本計(jì)數(shù)器、索引節(jié)點(diǎn)創(chuàng)建時(shí)間以及可能更多對(duì)象添加空間。最大的目錄大小（目前只有區(qū)區(qū)32GB）也會(huì)得到提高。
這一切將帶來(lái)許多優(yōu)點(diǎn)：主動(dòng)檢測(cè)文件系統(tǒng)受損情況、定位和更換缺乏聯(lián)系的塊以及更好的在線文件系統(tǒng)修復(fù)。Dave表示，這意味著在將來(lái)很長(zhǎng)一段時(shí)間，對(duì)Linux環(huán)境下的大數(shù)據(jù)應(yīng)用程序而言，XFS仍將是最出色的文件系統(tǒng)。
從btrfs的角度來(lái)看，這一切又意味著什么呢？Dave表示，btrfs顯然不是針對(duì)處理元數(shù)據(jù)密集型工作負(fù)載的文件系統(tǒng)而優(yōu)化；有一些嚴(yán)重的可擴(kuò)展性問(wèn)題成為了攔路虎。對(duì)于處于早期開(kāi)發(fā)階段的一款文件系統(tǒng)來(lái)說(shuō)，這完全在意料之中。其中一些問(wèn)題需要借以時(shí)日才能克服，但可能存在這種情況：其中一些問(wèn)題可能無(wú)法得到解決。另一方面，btrfs中的可靠性功能開(kāi)發(fā)得很完善，這款文件系統(tǒng)完全能夠提供在接下來(lái)幾年預(yù)期的存儲(chǔ)功能。
而ext4存在架構(gòu)可擴(kuò)展性問(wèn)題。據(jù)Dave的結(jié)果顯示，它不再是速度最快的文件系統(tǒng)。有幾個(gè)方案可用來(lái)改進(jìn)可靠性，其磁盤上格式顯露了老態(tài)。ext4支持在不遠(yuǎn)將來(lái)的存儲(chǔ)需求有難度。
考慮到這點(diǎn)，Dave在最后拋出了一個(gè)問(wèn)題。由于其豐富功能，btrfs不日將取代ext4，成為許多Linux發(fā)行版中的默認(rèn)文件系統(tǒng)。與此同時(shí)，ext4在處理大多數(shù)工作負(fù)載方面性能不如XFS，包括它在傳統(tǒng)上表現(xiàn)更強(qiáng)勁的應(yīng)用領(lǐng)域。一些可擴(kuò)展性問(wèn)題甚至出現(xiàn)在了更小的服務(wù)器系統(tǒng)上。“匯聚半完成的項(xiàng)目”并不總是能取得很好的效果；Dave表示，ext4并不如人們想象的那么穩(wěn)定或久經(jīng)測(cè)試。于是他問(wèn)道：為什么我們?nèi)孕枰猠xt4？
有人可能認(rèn)為，ext4開(kāi)發(fā)人員會(huì)想出很好的辦法來(lái)回答這個(gè)問(wèn)題，但是目前還沒(méi)有人回答得了。
英文原文鏈接：http://lwn.net/Articles/476263/
原文鏈接：http://os.51cto.com/art/201202/315553.htm
