2015-09-07 24 views
1

一種可能的方式是,將給定的inode與該目錄中的inode列表進行比較。 inode的列表可以預先確定或可以計算運行時間,兩種方式都有自己的問題:在一個內核模塊中,如何知道inode是否屬於某個特定的目錄?

  • 預定列表:列表可以在此操作過程中被改變,即文件可以添加或刪除該目錄。

  • 運行時間列表:如果該目錄中文件太多,每次訪問系統中的任何文件都會產生太多開銷。

對此有任何有效的解決方案/辦法?我試圖通過比較文件路徑,這真的是一個壞主意。

+0

你爲什麼要這麼做?通常不鼓勵內核模塊與文件系統進行交互。 –

+0

@JohnKugelman,我只需要知道我的** foo **目錄中的任何文件是否被不需要的進程訪問。 'fanotify'也是一個很好的解決方案,但它不會遞歸地執行。 –

+0

爲什麼你想知道?爲什麼你的內核模塊完全知道目錄?參見[此LKML消息](http://lkml.iu.edu/hypermail/linux/kernel/0005.3/0061.html):「編寫一個內核模塊不像編碼的用戶模式程序時,您應該 從來不寫一個模塊需要讀取或寫入任何邏輯設備,內核是將I/O轉換爲邏輯I/O的內核,試圖在內核 中執行邏輯I/O實際上是向後退出....有可能在內核中執行文件I/O,但這樣做嚴重違反了標準慣例。「 –

回答

0

要麼,如果你在內核模式還是在用戶模式下做到這一點沒有任何優勢。要看到,如果一個inode確實是在某些目錄中,您必須閱讀該目錄文件所在的目錄中,通常作爲一個線性表。這可能會導致您的進程阻止目錄塊存在,如果沒有緩存,並且在那段時間內可以修改目錄內容。只有在執行該操作時保持目錄inode被阻止纔有幫助,但這會給操作系統添加嚴重的性能限制。另一個問題是每個文件系統都可以自由地以自己的格式實現目錄內容。在用戶空間中,您可以獲得統一的目錄格式,但在內核模式下,您必須處理不同文件系統類型的不同方法。爲什麼你需要知道這一點?我無法想象可能需要這種情況。也許你可以重新設計你的目錄內容的算法是不必要的。

順便說一句,處理完整路徑或搜索目錄有模糊的競爭條件,可以處理你的系統堵塞好歹。如果在你的搜索過程中有人試圖斷開你正在搜索的inode,那麼會發生什麼?或者目錄內容必須修改;或者某個其他進程正在使用namei()向上遍歷您的目錄;或向下。你有沒有想過在所有這些可能性?

+0

如果您可以閱讀下面的所有評論,您可能已經注意到,我正在這樣做來保護應用程序特定的文件。有兩種方法可以做到這一點,通過訪問'path'或'inode'進行檢查。是的,幾乎無法確定'inode'是否屬於某個目錄,因此我將使用'path',因爲與其他解決方案相比,這是做到這一點的唯一方法。 [這個答案](http://stackoverflow.com/a/28224286/2706918)可以很容易地獲得絕對路徑進行比較。 –

+0

unix/linux的設計原則是在用戶平面實施策略。您是否考慮過在SeLinux方法的用戶空間中進行此操作?如果你最終遵循這種方法,你將不得不通過迴歸測試到整個內核,因爲根據規範,linux內核受到與unix sysv相同的競爭條件和問題的影響。由於'namei()'例程只是鎖定_passing through_上的inode,因此與着名的書籍* Maurice J.Bach –

+0

......在UNIX操作系統的設計中出現的相同問題在1986年已經指出了很大的可能性設計準則是編寫功能,而不是內核中的策略,可能內核中的大多數模塊都依賴於這個原則。可能你最好改變你的設計,而不是依靠這個功能。用戶空間中的任何內容都不依賴於瞭解inode編號。 –

相關問題