On Sun, 19 Jun 2011 00:38:05 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
On 2011-06-17 at 23:24:44 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:> Now my question to the experts. I thought about to add a table of > open > nodes in the vfs. When opening a file in the vfs using file_open a > node -> > path pair could be stored in a hash table. When file_close is called > the > entry has to be removed again. When sending a stat or attr changed > notifications this information could be used to add an entry_ref to > the > outgoing message. This could be done optional when the user adds an > additional flag in watch_node.Storing actual paths makes things relatively ugly, since keeping them up-to-date is somewhat complicated. Storing entry refs would be simpler. The node monitoring hooks already provide the update points for those.
I now map nodes to open entries node->entry_ref's and it seems to work fine. So whenever a node gets modified I can lookup in this map what entries are open for this node.
The question is how too send this information out. My first thought was to add another flag to the node monitor to specify if a watcher is interesting in the entry_ref. After looking into the implementation I figured out that in the current implementation it is not that easy to do. This is not really a problem but before doing so I asked myself how big the performance impact is when sending out the entry_ref every time?
The missing information that has to be added to the message is the file name and the directory id. I would estimate that this would be in average less than 30byte. How does memcpy works? is there a performance difference when coping this amount of memory around? What is the memory block size? (if there is anything like that)
Using a special flag would also need some more cycles so it might be the easier option to always attach the missing information.
thank you,
Clemens
