1樓：逸凌
NTFS的USN Journal 和通常的Journaling Filesystem的Journaling的是兩回事，通常意義上的Journaling是用來保證檔案完整的，在檔案被真正寫到磁碟上之前是被放進journal裡，檔案寫完之後這個記錄就被刪掉（標記為完成）了，如果系統down掉，重啟後在journal裡的記錄又沒有被Mark的就會重來一遍，這樣就保證了檔案操作的完整性，無論是EXT4 XFS 還是NTFS都這個機制的。而USN Journal 則是NTFS的乙個特殊機制——NTFS每一次的變動都被記錄下來，記入到乙個檔案, 也就是NTFS除了傳統的Journaling動作，還有個特殊動作就是USN journal。至於EXT4 之類的檔案系統是沒有這個動作的。
USN journal 是用來監測整個檔案系統（所有檔案）的，你說的Everything只要監測查詢那個特殊的日誌檔案就可以了，速度自然很快。有人提到了 Inotify 這個監測機制 ， 但是這個監測機制只能監測乙個目錄，而且不能監測整個檔案系統。 另外2.
6.36裡併入kernel的fanotify機制，看似更好其實也差不多，之前說好的 subtree監測也沒見個動靜。 所以無論是Inotfy還是fanotify都無法實現USN Journal的帶來的特性，因為這兩者都是VFS層實現，EXT4 也自然沒有這個功能。
2樓：
你看看你要找的是不是這個，https://forum.suse.org.cn/viewtopic.php?f=22&t=471
主頁應該是這個 redhatlinux10/quickquest · GitHub
3樓：北極
日誌檔案系統一般是指對檔案塊的操作有日誌儲存,一般是指元資料而非檔案索引本身。說NTFS是日誌檔案系統也主要是指NTFS能保證元資料正確性，而USN本身跟日誌檔案系統關係不大。ext是日誌檔案系統，是元資料的日誌。
我個人覺得掃瞄USN的過程本身就很費時，自建索引未必會慢多少。
主流檔案系統都支援B+樹索引，所以如果乙個資料夾只是檔案太多，其實用系統的原生API未必就慢。自建索引慢的原因可能是資料夾本身太多，因為open乙個資料夾的系統開銷還是不小的。
所以，結論就是，要在ext4上，只能自建索引。
4樓：kai yang
locale命令可實現部分功能，但他只能查到上次關機後已經存在的檔案。另外有乙個notification的機制，可實時感知檔案的狀態變化。兩者結合，應該可以達到everything的效果
5樓：
locate,whereis都是從日誌找檔案的，locate file 如果file是資料夾名的話，也會把資料夾下的子檔案絕對路徑列出，whereis找到的倒都是檔名。
這兩個命令速度和find比一下，感受非常明顯，find各種燒硬碟
弄錯了…前兩個命令是通過Linux的檔案資料庫找檔案的，不是通過日誌找檔案的
NTFS 是目前最先進的檔案系統嗎？
zhxw ntfs都存在了好多年了。ms的東西，一切為了相容性，先進性就不好弄了。關於路徑，使用Unicode版本的API，加 字首，就可以使用32,767個寬字元長度的路徑。 北極 先說一下之前回答有幾個不專業的地方 很多人把檔案系統本身和檔案系統實現混為一談 1 大部分檔案系統驅動都把星號 當做...
在固態硬碟時代，NTFS 這種檔案系統是不是已經很落後了？
NTFS在很多地方的設計還是很前衛的。比如 Alternative data streams，乙個在 Windows Vista 時期引入的功能，允許同乙個檔案存在多種資料流，後來成為了 Windows 10 的 WSL 可以在檔案系統上直接同時處理 Windows 和 Linux 的檔案的不同屬性...
分布式檔案系統，master和slave同步為什麼普遍採用checkpoint oplog的方式？
dastan 1 checkpoint 是某一時刻儲存系統 hadoop redis mongo 等等 的快照，特點是 相對小而緊湊，通常用於災備，比如每天 每週 每個月將映象檔案儲存到七牛或AWS，若非出現整個集群宕機，很難會用到它，因為集群自身往往有其它資料同步機制 宕機後能夠快速從上乙個備份點...