inotify on FUSE

http://sourceforge.net/p/fuse/mailman/message/24625009/

因為最近自己想做 FUSE ,為了加速,希望能夠做到 inotify 的功能。基本上我想做的事情是類似 Google Drive 網頁界面會做的事情,開啟一個目錄的時候先使用本地的快取回應,同時在背景發出 request 向 server 請求新目錄資料,收到請求之後再更新顯示畫面。也就是說在一個資料夾點兩下,會馬上進去並且看到資料夾的內容,這份內容由 cache 提供,同時在背景向 server 發出更新請求,從 server 取回新的結果之後,更新 cache ,並且顯示新的結果。

這東西用網頁做當然很容易,可是如果讓桌面應用程式像是檔案管理員(譬如說 Nautilus )做到這個功能,就必須支援 FUSE 。因為爬了一下文之後發現 Nautilus 裡面這部分的功能應該是用 GIO 實作的,而 GIO 達到檔案系統通知的方法又是依賴 kernel 的 inotify 。

所以要達到的話很自然就是需要讓 FUSE 也能夠支援 inotify 。

我原本以為 inotify 會提供 filesystem module 一個 system call 來通知某個路徑有更新,filesystem module 只要呼叫這個 syscall 就可以了。在 FUSE 的狀況下則是 FUSE 的 kernel filesystem module 會再接收來自 userspace libfuse 的呼叫,然後 FUSE 實作只要呼叫 libfuse 的這個 function 就可以了。

結果發現 inotify 完全不是這樣實作的。

inotify 的實作依賴 VFS ,也就是說,inotify 之所以知道某個物件被動過是因為有其他程式透過 VFS 來修改這個物件,而不是由 VFS 底層的 filesystem module 來通知 inotify 。事實上 VFS 並不提供任何方法讓 filesystem module 通知它物件的更動。

螢幕快照 2015-06-13 下午5.58.16

也就是說,圖中的 FUSE 沒有任何方法可以通知 VFS 某個物件被修改了。VFS 知道物件被修改(VFS 知道就等於 inotify 知道,應該是每個 VFS 的操作都有 inotify 的 hook 之類的)是因為有除了圖中 ls -l 之外其他的 userspace 程式呼叫 VFS ,這時候就會一併 invoke inotify 的 hook ,inotify 進而通知 watcher 。

所以基本上,要達到我想要的功能,這個 userspace 的 FUSE 程式本身要去戳 VFS ,才會觸發 inotify 。

可是這樣顯然非常容易造成 deadlock ,因為 VFS 收到呼叫會再呼叫 FUSE filesystem module ,然後又會呼叫 userspace 的 FUSE 程式,要詳加調查有什麼不會造成 deadlock 的方式……

或是說另一個方式是直接去改 VFS ,讓 VFS 支援由底層的 filesystem module 來 trigger inotify 。這樣可行性不知道如何。

或是說要做到我所說的效果,似乎應該直接 patch Nautilus ,讓 userspace FUSE 程式和 Nautilus 有溝通的機制,某種程度上的整合。

參考資料:

  • 巴西某大學的課程簡報,講 VFS 和一點點 FUSE ,蠻易懂的快速入門:http://www.ic.unicamp.br/~islene/2s2013-mo806/vfs/andre-zhen.pdf

FSEvents and inotify

正在看 Linux 的 inotify system call 的介紹,底下的留言 #165 提到,一個目錄被新增時,在 inotify 開始 watch 它之前(也就是 inotify_add_watch() 系統呼叫還在執行中尚未完成的這段時間內),目錄本身和目錄內發生的任何事情都沒有辦法抓到。

接下來就有人提到 OSX 當中的實作,FSEvents 系統。FSEvents API 允許應用程式監控一個目錄,當目錄有任何改變的時候,kernel 會將通知訊息透過 /dev/fsevents 傳遞給一個 userspace 的 process , fseventsdfseventsd 會合併在短時間內發出的大量 notification ,再通知應用程式。

其實 XNU 某些部分也是蠻先進的呢。

YYP OOP 之亂

前情提要

個人想法

YYP OOP 作業的問題點並不在於實際上有多難,而是我覺得大學部的必修課本來就不應該讓這麼多人覺得困難,就算本來已經很簡單了,很多人抱怨困難的話還是應該要更簡單。
大學部必修課的重點在於讓學生瞭解基本概念,如果讓學生有撞牆的感覺的話,很多人就會直接放棄了,無助於達成「讓學生瞭解基本概念」這個目標。

有人說,如果現在不設這樣的標準,不教這麼多內容,那以後出去工作是要怎麼辦?
重點再講一次,必修課的重點是「讓學生瞭解基本概念」,而不是「讓學生有工作能力」。
大學什麼時候有訓練學生符合業界需求的責任了?這本來不是大學的目的。

有人說,就是要這樣的難度,讓學生知道 C++ 很困難,或是讓他們知難而退。
再講一次,必修課的重點是「讓學生瞭解基本概念」,不是篩選學生,或是讓他們知難而退。

我並不想討論 OOP 作業內容上是否太難或不合理,問題在於實際上就是有相當比例的人覺得過於困難,對於他們來說是一種撞牆的感覺,這時候這門課就已經與「讓學生瞭解OOP的基本概念」這個目標偏離了。
如果你覺得這些東西是「本來就應該要會」的東西,那你大可自己精進或修選修課。讓這麼多人撞牆,不是必修課應該產生的合理現象。

以現在作業的難度,你批評那些做不出來的人是「不夠認真」、「不適合唸資工系」,那假設作業的難度再提升,你花了更多的時間把它完成,同時有更多人做不出來,那些人是否仍然「不夠努力」?
換句話說,假設難度不斷提升,通過的比率越來越少,失敗的比率越來越多,用這樣的方法去強迫大家「努力」,那何時停止?因為努力永遠都還可以更努力啊
有沒有發現,為什麼「夠不夠努力」是由一個外部的標準評定的?而且原本「夠努力」的人,我只要把標準再提升,馬上就變成「不努力」」。這樣有意義嗎?

教育並不是不斷地把標準提高以激勵(逼迫)學生符合標準,教育也不是篩選,教育…是讓大部分的學生學到東西(不管東西在你看來是多麼地少)。
因為有興趣的人大可以自己精進,可是對於初次接觸的人,你讓他這樣撞牆,可能就是讓他永遠不會再碰這個美妙而有趣領域的轉機了。