Can you summarize the following document?
        
  XFS的開發始於1993年,在1994年被首次部署在IRIX 5.3上。2000年5月,XFS在GNU通用公共許可證下發布,並被移植到Linux上。2001年XFS首次被Linux發行版所支援,現在所有的Linux發行版上都可以使用XFS。  XFS最初被合併到Linux 2.4主線中,這使得XFS幾乎可以被用在任何一個Linux系統上。Arch, Debian, Fedora, openSUSE, Gentoo, Kate OS, Mandriva, Slackware, Ubuntu, VectorLinux和Zenwalk的安裝程式中都可選擇XFS作為檔案系統,但由於預設的啟動管理器GRUB中存在bug,以上發行版中只有少數幾個允許使用者在 /boot 掛載點(引導目錄)上使用XFS檔案系統。  FreeBSD在2005年12月獲得了對XFS的只讀支援,並在次年6月引入了試驗性的寫入支援。不過這些只是為了方便使用者從Linux上遷移到FreeBSD上,並不是為了把XFS作為主打檔案系統使用。Red Hat Enterprise Linux 5.4 64位版的核心完整支援XFS,但未包含建立和使用XFS的命令列工具(CentOS正在進行這方面的嘗試),原因是這些軟體包還不夠穩定。Red Hat Enterprise Linux 7/CentOS預設使用XFS檔案系統。

  

  XFS是一個64位檔案系統,最大支援8exbibytes減1位元組的單個檔案系統,實際部署時取決於宿主作業系統的最大塊限制。對於一個32位Linux系統,檔案和檔案系統的大小會被限制在16tebibytes。

  日誌檔案系統是一種即使在斷電或者是作業系統崩潰的情況下保證檔案系統一致性的途徑。XFS對檔案系統後設資料提供了日誌支援。當檔案系統更新時,後設資料會在實際的磁碟塊被更新之前順序寫入日誌。XFS的日誌被儲存在磁碟塊的迴圈緩衝區上,不會被正常的檔案系統操作影響。XFS日誌大小的上限是64k個塊和128MB中的較大值,下限取決於已存在的檔案系統和目錄的塊的大小。在外接裝置上部署日誌會浪費超過最大日誌大小的空間。XFS日誌也可以被存在檔案系統的資料區(稱為內建日誌),或者一個額外的裝置上(以減少磁碟操作)。  XFS的日誌所儲存的是“邏輯”條目,以人類更加容易理解的方式來描述當前正在進行的操作(“物理”日誌與其相反,儲存的是每次操作中被修改的塊)。日誌的更新以非同步的方式進行,避免影響整體效能。  如果發生系統崩潰,可以根據日誌中的記錄來重做並完成崩潰的前一時刻發生的系統操作。崩潰之後首次掛載檔案系統時,會自動進行恢復。恢復的速度不受檔案系統大小的影響,取決於需要重做的系統操作的數量。  對於最近被修改但未完全寫入磁碟的資料,XFS保證在重啟時清零所有未被寫入的資料塊,以防止任何有可能的、由剩餘資料導致的安全隱患(因為雖然從檔案系統介面無法訪問這些資料,但不排除裸裝置或裸硬體被直接讀取的可能性)。

  XFS檔案系統內部被分為多個“分配組”,它們是檔案系統中的等長線性儲存區。每個分配組各自管理自己的inode和剩餘空間。檔案和資料夾可以跨越分配組。這一機制為XFS提供了可伸縮性和並行特性——多個執行緒和程序可以同時在同一個檔案系統上執行I/O操作。這種由分配組帶來的內部分割槽機制在一個檔案系統跨越多個物理裝置時特別有用,使得優化對底層儲存部件的吞吐量利用率成為可能。

  在條帶化RAID陣列上建立XFS檔案系統時,可以指定一個“條帶化資料單元”。這可以保證資料分配、inode分配、以及內部日誌被對齊到該條帶單元上,以此最大化吞吐量。

  XFS檔案系統中的檔案用到的塊由變長Extent管理,每一個Extent描述了一個或多個連續的塊。與那些把檔案所有塊都單獨列出來的檔案系統相比,extent大幅縮短了列表。<br> 有些檔案系統用一個或多個面向塊的點陣圖管理空間分配——在XFS中這種結構被由一對B+樹組成的、面向Extent的結構替代了;每個檔案系統分配組(AG)包含這樣的一個結構。其中,一個B+樹用於索引未被使用的Extent的長度,另一個索引這些Extent的起始塊。這種雙索引策略使得檔案系統在定位剩餘空間中的Extent時十分高效。

  塊是檔案系統中的最小可分配單元。XFS允許在建立檔案系統時指定塊的大小,從512位元組到64KB,以適應專門的用途。比如,對於有很多小檔案的應用,較小的塊尺寸可以最大化磁碟利用率;但對於一個主要處理大檔案的系統,較大的塊尺寸能提供更好的效能。...

  XFS在檔案分配上使用了惰性計算技術。當一個檔案被寫入快取時,XFS僅在記憶體中對該檔案保留適當數量的塊,並不立即給資料分配Extent。實際的塊分配僅在這段資料被沖刷到磁碟時才發生。這一機制提高了將該檔案寫入一組連續塊中的機會,減少碎片的同時提升了效能。

  XFS對每個檔案提供了一個64位的稀疏地址空間,使得大檔案中的“洞”(空白資料區)不被實際分配到磁碟上。因為檔案系統對每個檔案使用一個Extent表,檔案分配表就可以保持一個較小的體積。對於太大以至於無法儲存在inode中的分配表,這張表會被移動到B+樹中,繼續保持對該目標檔案在64位地址空間中任意位置的資料的高效訪問。

  XFS通過實現擴充套件檔案屬性給檔案提供了多個資料流,使檔案可以被附加多個名/值對。檔名是一個最大長度為256位元組的、以NULL字元結尾的可列印字串,其它的關聯值則可包含多達64KB的二進位制資料。這些資料被進一步分入兩個名字空間中,codice_1和codice_2。儲存在root名字空間中的擴充套件屬性只能被超級使用者修改,user名字空間中的可以被任何對該檔案擁有寫許可權的使用者修改。擴充套件屬性可以被新增到任意一種 XFS inode上,包括符號連結、裝置節點、目錄,等等。可以使用codice_3這個命令列程式操作這些擴充套件屬性。codice_4和codice_5工具在進行備份和恢復時會一同操作擴充套件屬性,而其它的大多數備份系統則會忽略擴充套件屬性。

  對於需要高吞吐量的應用,XFS實現了直接的I/O,允許未快取的I/O操作直接應用到使用者空間。資料在應用程式的緩衝區和磁碟間利用DMA進行傳輸,以此提供底層磁碟裝置全部的I/O頻寬。

  XFS確定速率I/O系統給應用程式提供了預留檔案系統頻寬的API。XFS會動態計算底層儲存裝置能提供的效能,並在給定的時間內預留足夠的頻寬以滿足所要求的效能。此項特性是XFS所獨有的。確定方式可以是硬性的或軟性的,前者提供了更高效能,而後者相對更加可靠。不過只要底層儲存裝置支援硬性速率確定,XFS就只允許硬性模式。這一機制最常被用在實時應用中,比如視訊流。

  XFS實現了資料管理應用程式介面(DMAPI)以支援高階儲存管理(HSM)。到2010年10月為止,Linux上的XFS實現已經支援DMAPI所要求的的磁碟後設資料規範,但有報告稱核心支援仍處於不穩定狀態。此前SGI曾提供了一個包含DMAPI鉤子的核心原始碼樹,但這個支援未被合併進主程式碼樹。不過現在核心開發者們已經注意到了它並對其做了更新。

  XFS並不直接提供對檔案系統快照的支援,因為XFS認為快照可在卷管理器中實現。對一個XFS檔案系統做快照需要呼叫codice_6工具凍結檔案系統的I/O,然後等待卷管理器完成實際的快照建立,再解凍I/O,繼續正常的操作。之後這個快照可以被當作備份,以只讀方式掛載。在IRIX上釋出的XFS包含了一個整合的卷管理器,叫XLV。這個卷管理器無法被移植到Linux上,不過XFS可以和Linux上標準的LVM正常工作。在最近釋出的Linux核心中,codice_6的功能被實現在了VFS層,當卷管理器的快照功能被喚醒時將自動啟動codice_6。相對於無法掛起,卷管理器也無法對其建立“熱”快照的ext3檔案系統,XFS的快照功能具有很大優勢。幸運的是,現在這種情況已經改觀。從Linux 2.6.29核心開始,ext3, ext4, gfs2和jfs檔案系統也獲得了凍結檔案系統的特性。

  雖然XFS基於Extent的特徵和延遲分配策略顯著提高了檔案系統對碎片問題的抵抗力,XFS還是提供了一個檔案系統碎片整理工具,codice_9(XFS filesystem reorganizer的簡稱)。這個工具可以對一個已被掛載、正在使用中的XFS檔案系統進行碎片整理。

  XFS提供了codice_10工具,可以線上調整XFS檔案系統的大小。XFS檔案系統可以向儲存當前檔案系統的裝置上的未分配空間延伸。這個特性常與卷管理功能結合使用,因為後者可以把多個裝置合併進一個邏輯卷組,而使用硬碟分割槽儲存XFS檔案系統時,每個分割槽需要分別擴容。到2010年8月為止,XFS分割槽不可以原位收縮,不過有一些方法可以變相處理這個問題。

  XFS提供了codice_4和codice_5工具協助備份XFS檔案系統中的資料。codice_4按inode順序備份一個XFS檔案系統。與傳統的UNIX檔案系統不同,XFS不需要在dump前被解除安裝;對使用中的XFS檔案系統做dump就可以保證映象的一致性。這與XFS對快照的實現不同,XFS的dump和restore的過程是可以被中斷然後繼續的,無須凍結檔案系統。codice_4甚至提供了高效能的多執行緒備份操作——它把一次dump拆分成多個資料流,每個資料流可以被髮往不同的目的地。不過到目前為止,Linux尚未完成對多資料流dump功能的完整移植。

  XFS的磁碟配額在檔案系統被初次掛載時啟用。這解決了一個在其它大多數檔案系統中存在的一個競爭問題:要求先掛載檔案系統,但直到呼叫quotaon (8)之前配額不會生效。

  

  XFS檔案系統預設在掛載時啟用“寫入屏障”的支援。該特性會一個合適的時間沖刷底層儲存裝置的回寫快取,特別是在XFS做日誌寫入操作的時候。這個特性的初衷是保證檔案系統的一致性,具體實現卻因裝置而異——不是所有的底層硬體都支援快取沖刷請求。在帶有電池供電快取的硬體RAID控制器提供的邏輯裝置上部署XFS檔案系統時,這項特性可能導致明顯的效能退化,因為檔案系統的程式碼無法得知這種快取是非易失性的。如果該控制器又實現了沖刷請求,資料將被不必要地頻繁寫入物理磁碟。為了防止這種問題,對於能夠在斷電或發生其它主機故障時保護快取中資料的裝置,應該以codice_15選項掛載XFS檔案系統。

  XFS檔案系統建立時預設使用內建日誌,把日誌和檔案系統資料放置在同一個塊裝置上。由於在所有的檔案系統寫入發生前都要更新日誌中的後設資料,內建日誌可能導致磁碟競爭。在大多數負載下,這種等級的競爭非常低以至於對效能沒有影響。但對於沉重的隨機寫入負載,比如在忙碌的資料塊伺服器上,XFS可能因為這種 I/O競爭無法獲得最佳效能。另一個可能提高這個問題的嚴重性的因素是,日誌寫入被要求以同步方式提交——它們必須被完全寫入,之後對應實際資料的寫入操作才能開始。  如果確實需要最佳的檔案系統效能,XFS提供了一個選項,允許把日誌放置在一個分離的物理裝置上。這只需要很小的物理空間。分離的裝置有自己的I/O路徑,如果該裝置能對同步寫入提供低延遲的路徑,那麼它將給整個檔案系統的操作帶來顯著的效能提升。SSD,或帶有寫回快取的RAID系統是日誌裝置的合適候選,它們能滿足這種效能要求。不過後者在遭遇斷電時可能降低資料的安全性。要啟用外部日誌,只須以codice_16選項掛載檔案系統,並指定一個合適的日誌裝置即可。
XFS,一種高效能的日誌檔案系統,最早於1993年,由Silicon Graphics為他們的IRIX作業系統而開發,是IRIX 5.3版的預設檔案系統。2000年5月,Silicon Graphics以GNU通用公共許可證釋出這套系統的原始碼,之後被移植到Linux核心上。XFS特別擅長處理大檔案,同時提供平滑的資料傳輸。目前CentOS 7也將XFS+LVM作為預設的檔案系統。