在計算機世界中，未使用的資源代表著錯失的機會。這一理念促成了像 vramfs 這樣的工具的開發，它利用 FUSE（使用者空間檔案系統）庫將顯示卡中未使用的影片記憶體（VRAM）轉變為功能性檔案儲存。雖然這個專案本身並不新穎，但它仍然引發了關於替代儲存解決方案和硬體元件創新性重用的有趣討論。
效能限制和替代方案
vramfs 的當前實現達到了約 2.4 GB/s 的讀取速度和 2.0 GB/s 的寫入速度，一些社群成員指出這與現代 NVMe SSD 的效能相當，而非顯著更快。這些基準測試是在相對較舊的硬體上獲得的（Intel Core i5-2500K 配備 AMD R9 290 GPU），這引發了人們猜測，在配備 PCIe 4.0/5.0 和更新的 FUSE 實現的現代系統上，效能可能會大幅提升。
一些評論者建議，基於 FUSE 的方法引入了不必要的開銷。一個提議的替代方案是使用 phram 核心模組，它建立一個完全繞過 FUSE 的塊裝置。其他人則建議，利用 DRM（直接渲染管理器）子系統的適當 Linux 核心模組將提供更好的效能，具有適當的快取、直接 mmap 支援和可靠的併發檔案系統。
測試系統規格（來自原始 vramfs 基準測試）
- 作業系統：Ubuntu 14.04.01 LTS（64位）
- CPU：Intel Core i5-2500K @ 4.0 GHz
- 記憶體：8GB DDR3-1600
- 顯示卡：AMD R9 290 4GB（Sapphire Tri-X）
效能指標
- 讀取效能：約2.4 GB/s
- 寫入效能：約2.0 GB/s
- 最佳塊大小：128KiB（為了效能）或64KiB（為了降低空間開銷）
實現限制
- 大多數操作使用單一互斥鎖（有限的併發性）
- 所有資料傳輸必須透過PCIe匯流排
- 需要OpenCL 1.2支援
- 建議最大大小：可用視訊記憶體的50%
實現挑戰
當前的 vramfs 實現面臨幾個技術障礙。也許最顯著的是，該專案對大多數操作使用單一互斥鎖，這意味著一次只有一個執行緒可以修改檔案系統。這種設計選擇嚴重限制了併發性和整體效能。
另一個挑戰是 CPU 到 GPU 資料傳輸的固有瓶頸。由於所有的讀寫操作必須透過 PCIe 匯流排並經過 CPU，理論最大速度遠低於直接 GPU 到 VRAM 訪問所允許的速度。這一限制使一些人質疑，與簡單地增加系統記憶體（這已變得相對便宜）相比，這種方法的實用性。
「使用寶貴的 vram 來儲存檔案是一種特殊的幽默。尤其是因為有人真的實現了它。」
實用考慮和使用場景
社群討論揭示了將 VRAM 用作檔案系統的幾個實際問題。一個重要問題是電源管理 - 將 VRAM 用於儲存會阻止 GPU 進入低功耗狀態，可能增加系統功耗。雖然一些 GPU 可以在保持其他部分活躍的同時有選擇地為記憶體部分供電，但實現細節因硬體而異。
另一個問題與將 VRAM 用作交換空間有關。雖然技術上可行，但多位使用者報告在嘗試這樣做時系統凍結，因為 GPU 管理程序本身可能被換出，導致不可恢復的頁面錯誤。這突顯了任何依賴驅動程式的儲存介質上交換空間的更廣泛挑戰。
儘管存在這些挑戰，一些利基使用場景確實存在。對於記憶體有限但 GPU 不錯的系統，vramfs 可以提供額外的高速儲存。還有人推測，對於可以直接在儲存在 VRAM 檔案系統中的資料上操作的特定 GPU 加速工作負載，可能會帶來潛在的效能優勢。
然而，對於大多數使用者來說，共識似乎是增加更多系統記憶體代表著更實用和更具成本效益的解決方案。正如一位評論者所指出的，192GB 的系統記憶體成本約為 500 美元，而等效的 GPU VRAM 將花費約 40,000 美元 - 對於那些只是尋求更多高速儲存的人來說，這使選擇變得簡單明瞭。
雖然 vramfs 可能不會徹底改變儲存技術，但它代表了推動計算創新的那種創造性實驗。正如一位評論者恰當地指出的那樣，像這樣的專案體現了不要問為什麼，而要問為什麼不的理念，這種理念繼續推動著現有硬體可能性的邊界。
參考：vramfs