LWN：關(guān)閉文件系統(tǒng)extent的一個(gè)優(yōu)化！

關(guān)注了就能看到更多這么棒的文章哦～

Disabling an extent optimization

By Jake Edge
June 21, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/898029/

在 2022 年 Linux 存儲(chǔ)、文件系統(tǒng)、內(nèi)存管理和 BPF 峰會(huì)（LSFMM）的最后一場文件系統(tǒng)會(huì)議上，David Howells 主持討論了文件系統(tǒng)中一個(gè)當(dāng)前引出了一些問題的優(yōu)化。那些 Extent-based 文件系統(tǒng)中包含了一些有時(shí)不能反映文件中存在的空洞（hole）的數(shù)據(jù)結(jié)構(gòu)。如果對稀疏文件（sparse file, 也就是有空洞的文件）的空洞區(qū)域中進(jìn)行 read 時(shí)，返回的數(shù)據(jù)必須是零，但除此之外，文件系統(tǒng)并沒有責(zé)任去真正意識(shí)到這里是有個(gè)空洞的，這就導(dǎo)致了下面要講述的問題。

Howells 首先介紹了一下這個(gè)問題，他第一次遇到的是在使用 FS-Cache 來緩存文件內(nèi)容的時(shí)候，但他后來發(fā)現(xiàn)這個(gè)問題實(shí)際上是個(gè)更普遍的問題。如果某個(gè) extent-based 文件系統(tǒng)（如 Ext4、XFS 和 Linux 的 Btrfs）上有一個(gè)文件，在兩個(gè) extent 之間有一個(gè)小空缺時(shí)，文件系統(tǒng)有時(shí)就會(huì)把兩個(gè) extent 合并起來，并且用 0 來填補(bǔ)空缺區(qū)域。這樣做的目的是為了減少文件的 extent list 數(shù)量，盡管這樣做會(huì)增加磁盤上的存儲(chǔ)空間的占用量。同時(shí)也會(huì)有一些相反的情況發(fā)生，如果文件系統(tǒng)看到文件中有一個(gè)文件中有很多 block 都是全 0 的時(shí)候，它可以通過創(chuàng)建成兩個(gè) extent 把中間作為空洞，從而節(jié)省磁盤空間，不過這一點(diǎn)這對 Howells 來說似乎不是一個(gè)問題。

[David Howells]

困難在于，由于 extent list 可以隨時(shí)改變，因此各種操作如 lseek() 用 SEEK_HOLE 和 SEEK_DATA 來尋找空洞區(qū)域的話，都會(huì)出現(xiàn)假陽性或者假陰性的結(jié)果。FS-Cache 是用本地緩存文件中的空洞來代表尚未從服務(wù)器上獲取的數(shù)據(jù)的，所以不應(yīng)該直接想當(dāng)然地填充這部分區(qū)域。如果加密不是在文件系統(tǒng)內(nèi)進(jìn)行的，那么這種 merging 和 filling 操作也會(huì)對帶有空洞的文件的內(nèi)容的加密操作造成負(fù)面影響。他說，當(dāng)內(nèi)容加密是單獨(dú)進(jìn)行的時(shí)候，加密文件中的空洞主要是為了表明明文文件中包含 0，而不是加密文件里面包含 0；所以在加密文件中填入很多 0 的話會(huì)破壞這個(gè)文件。

對于 ext4 上的 fscrypt，他認(rèn)為是沒有問題的，因?yàn)樗窃?ext4 內(nèi)完成加密的，ext4 不允許在加密文件中出現(xiàn)空洞；ext4 會(huì)用適當(dāng)?shù)募用軆?nèi)容來填補(bǔ)這些空洞。Ted Ts'o 證實(shí)了這一點(diǎn)。Howells 希望能夠?qū)θ魏挝募到y(tǒng)的內(nèi)容都支持加密，但不需要浪費(fèi)磁盤空間來加密明文文件中的空洞。他想知道是不是應(yīng)該允許其他用例來對底層文件系統(tǒng)提出要求不要進(jìn)行這些優(yōu)化。

Ts'o 說，這個(gè)問題的核心是一個(gè)哲學(xué)問題。一些文件系統(tǒng)把稀疏文件當(dāng)作簡單的優(yōu)化，他們不管這里是否有空洞，只保證說這些空洞中會(huì)返回 0。但是，F(xiàn)S-Cache 把這些空洞事實(shí)上作為一個(gè)數(shù)據(jù)通道（data channel）來使用了；它需要確保那些它專門放在文件中的空洞需要一直保持空洞狀態(tài)。如果用戶空間期望 SEEK_HOLE 和 SEEK_DATA 也是按這種方式工作的話，就可能跟文件系統(tǒng)的看法不一致了，畢竟文件系統(tǒng)認(rèn)為空洞只是一種優(yōu)化，他說。

幾位與會(huì)者整理了一下當(dāng)前的情況，其中 Btrfs 不會(huì)做這種 "optimistic filling"，也就是說不會(huì)把這些小空隙填充掉從而不再當(dāng)作一個(gè)空洞，所以這個(gè)問題只存在于 ext4 和 XFS 中。不過，這里的終極問題是文件系統(tǒng)是否有義務(wù)維護(hù)稀疏文件以及磁盤上全 0 的 block 的文件之間的語義差異，Ts'o 說。他介紹說最初的理由是，比如說有一個(gè) 32KB 的空洞，那么在磁盤里直接寫入 32KB 的 0 數(shù)據(jù)，比起使用兩個(gè) extent 所必需的 seeking 以及 extent-tree 的操作要更快。

一位遠(yuǎn)程參與者指出，歐洲原子核研究中心（CERN）幾年前就因?yàn)檫@種行為而對 AFS 報(bào)告了一些 bug。CERN 當(dāng)時(shí)正在使用一個(gè)大小為 2PB 的稀疏文件，并期望其中的空洞要能夠一直保持。后來其中一個(gè) 12 字節(jié)的空洞消失了，從而破壞了整個(gè)文件。AFS 的開發(fā)者解釋說，CERN 所依靠的是一個(gè)文件系統(tǒng)無法保證的行為，但這是一個(gè)與加密（或緩存）無關(guān)的例子，表明用戶確實(shí)有可能希望能禁用 hole filling 動(dòng)作。

Josef Bacik 建議說可以提供一個(gè) per-file 的 flag 來禁用這個(gè)優(yōu)化。Ts'o 說，Ext4 有一個(gè)文件系統(tǒng)范圍的解決方法，就是使用一個(gè)可調(diào)整的參數(shù)來設(shè)置文件系統(tǒng)中會(huì)被填充的 hole 的最大 size。默認(rèn)是 8 個(gè)文件系統(tǒng) block，但將其設(shè)置為 0 就可以禁用該功能。他認(rèn)為 per-file flag 確實(shí)更加好；他不介意替沒能參加 LSFMM 的 XFS 的開發(fā)人員來提供意見，不過畢竟無法代表他們。然而，如果受影響的文件系統(tǒng)都達(dá)成一致應(yīng)該如何設(shè)置這個(gè) flag，那就是最好的方案了。

Bacik 說他想在 Btrfs 中加入這個(gè)優(yōu)化，所以也想實(shí)現(xiàn)禁用此優(yōu)化的機(jī)制。Chris Mason 說他不確定這些 "bridgeable(意思就是填充兩個(gè)區(qū)域之間的空隙)" 的空洞出現(xiàn)得有多頻繁，但對于 Btrfs 來說，創(chuàng)建一個(gè) 4KB 的 hole 絕對是得不償失的。Ts'o 說，在 ext4 中填補(bǔ)小空隙的最初需求是來自 libbfd，它會(huì)創(chuàng)建有很多空隙的文件，然后最終用真正的數(shù)據(jù)填補(bǔ)這些空隙；不這樣做的話會(huì)影響 "一些愚蠢的性能測試場景，比如說內(nèi)核編譯就是一個(gè)例子"。

Amir Goldstein 說，XFS 已經(jīng)有了一個(gè)類似的 API，但跟人們想要的并不完全相同，也許它可以被擴(kuò)展一下來滿足這個(gè)需求。遠(yuǎn)程接入會(huì)議的 Jan Kara 說，那個(gè) API 是基于 ioctl()的，主要目的之一是用來設(shè)置 project ID，并且跟 ext4 公用。這個(gè) API 可以擴(kuò)展一下來設(shè)置一個(gè) inode flag，存放在 inode 里的 chattr flags 中，禁用這個(gè) hole filling 行為，只要那里還有可用空間的話。Bacik 說，他認(rèn)為還是有空間的，Howells 也同意，因此這似乎會(huì)是今后的實(shí)現(xiàn)方向了。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～