LWN: 是否應該增加一個splice()的reverse版本？

Toward a reverse splice()

By Jonathan Corbet,  May 1, 2019, LSFMM

splice()系統呼叫實質上是實現了一個寫操作，主要是希望通過zero-copy的方式來把從pipe（管道）來的page寫入檔案。在2019 Linux Storage, Filesystem, and Memory-Management Summit峰會上，Miklos Szeredi介紹了一個新近提出的主意，來實現一個rsplice() API，也就是“reverse splice" （反向splice）系統呼叫。

這次會議上的討論並沒有得出非常明確的結論，但是非常明確的是：rsplice()需要一個更好的描述（也需要提供一些程式碼來介紹），然後Linux community才能更好的理解它，以及review它。

splice()的執行中會用到data的最新buffer，也就是說它會把從其他來源獲取的data page搬過來。而reverse-splice操作就是反過來操作，它會對一個empty buffer進行填充，寫入一些其他來自其他地方的資料。換句話說，它其實是一個read操作，而不是write操作。例如，可以利用它來從file buffer獲取資料，然後填到pipe裡面去。一個常見的應用場景是在使用者態檔案系統環境（user-space filessytem）裡，可以用這個API來把檔案資料提取後送給kernel（或者其他地方），而根本不用copy這個資料。他覺得這個idea是“implementable”（可以實現的），也想聽聽與會者會怎麼說。

Rik van Riel擔心那些page的ifecycle問題，把一個page的資料搬到page cache裡面去（這是rsplice()的一種可能實現方式）在這個page沒有其他使用者的情況下是很容易的，但是如果其他程序早就已經在page table裡面引用了這個page呢？Szeredi回答說rsplice()可以只對那些尚未activated的page來進行操作，這樣就不會有其他人引用這個page了。

Matthew Wilcox提到一個應用場景，是他在Microsoft的時候瞭解到的。這就是從remote server（遠端伺服器）獲取data page的場景。如果能有高效的方法能把data放到page cache裡去，這會很有價值的。不過者需要類似kernel內部已經實現的sendpage()方法來增加一個類似的recvpage()。他很希望Microsoft這邊今後能有人多介紹一下這個應用場景。

Hugh Dickins卻想起Linus Torvalds之前提到過他很後悔在Linux裡面最初加入splice()。Torvalds當時覺得splice()是個好主意，但是splice()實現之後，很少有人真正利用了它。他說，如果只是增加一個API卻沒有什麼人用它，那實際上只是增加了kernel受到攻擊的風險點。很少有人真正知道splice()怎麼用，過去這麼多年，已經有好多次糾正大家對它的錯誤認識了。如果加了rsplice()，又會需要重新走過這個認知流程，才能讓開發人員信任這個API。

然後這個討論就開始發散開了。有一些人覺得zero-copy的interface沒有什麼必要。不過它確實還是能對有高頻寬的介面和huge page的系統會有些好處。也有不少聽眾還是沒有理解rsplice()和splice()的區別，可能也是因為確實此前就沒有多少人知道splice()這個API。不過，大家還是都認為需要先拿出一個定義好的use case（應用場景），然後再更深入的理解它。希望不久之後能看到一個實現版本出來，這樣大家能更深入的針對性討論。