具有“冒泡”目錄大小的文件系統
這只是我對如何記憶體或以其他方式加速“du”摘要的評論？制定為自己的問題：
是否有任何關於創建文件系統的擴展討論，其中每個目錄的總大小（想想
du）被保存並“冒泡”（即，在樹中向上傳播，以便所有父目錄大小也是正確的），例如由於寫入文件，刪除等，所以那du會是即時的嗎？從我上面連結的答案中，很明顯 I/O 性能會因為這樣做而受到影響，我只是想知道會有多少。它會減少幾個數量級還是只減少幾個（幾十個）百分比？
與此密切相關的是以相同方式“冒泡” mtime 的概念，以便每個目錄的 mtime 反映其整個子樹中的最新更改。例如，這兩個功能一起可以大大加快具有許多深度嵌套文件的樹
rsync的--update模式。
現代文件系統，例如 zfs / btrfs / bcachefs 實際上是朝著相反的方向發展，並允許/鼓勵文件之間共享範圍。這樣，“目錄佔用多少數據”的概念就變得不那麼明確了（儘管由於硬連結，這在某種程度上已經是正確的）：使用 reflinks，可以創建一個顯然包含更多數據的目錄甚至不適合文件系統（至少就簡單的磁碟分析工具喜歡
du或ncdu可以理解它而言）。重新表述這個問題的一種方法是“如果刪除此目錄，將釋放多少可用空間”，這不那麼模棱兩可，但並不是那麼有用，因為一旦您創建快照，我也遇到過這樣的問題：
- 很難理解允許數據共享的文件系統上的空間使用情況
- 分析大型文件系統的空間使用情況需要太多時間 (I/O)
出於這個原因，我創建了btdu，一個採樣磁碟使用分析器，它為 btrfs 解決了這些問題。
至於一般的“冒泡”概念：我不確定其他文件系統，但這確實類似於 btrfs 內部的工作方式，其中有一個主根 (b-) 樹遞歸地引用其他樹。當任何樹（許多層深）被更新時，一個新副本被寫入磁碟上的其他地方（因此 btrfs 的 COW 方面）並且父節點被更新以指向新副本，這反過來又導致其父節點在以同樣的方式，依此類推，直到根樹。（在實踐中，實現採用了許多優化來保留其不變數，但保持性能合理。）