Fred Schaettgen wrote:
On Thursday 13 January 2005 14:15, you wrote:
Fred Schaettgen wrote:...
..
Let's first specify the notification interface. Should it be kernelThere is a union (file_plugin_data) in struct reiser4_inode to keepI can't use that union, since my plugin would call the methods of the
features specific
for file plugins.
original file plugin of a file,
messages, or
should the fs write something to /proc? (I don't have ideas)
Hi, sorry for long silence
Actually I didn't think about active notification at all. The idea is to set an timestamp for each monitored file, which is reset for the file itself and the whole path(s) upwards when the file is changed.
A userspace program which manages an index will find the newly changed files by looking at that timestamp in some base directory and descending into each subdirectory for which this timestamp is more recent than a saved timestamp or if the timestamp isn't set at all. On the way back, the missing timestamps will be updated.
So it's by design a single-shot "notification" and you would have to poll a single file to be able to update your stored data continously. This should be adequate for applications which index large parts of the file system. For other needs, inotify will be the better solution.
The pseudo-file interface could look like this:
file/..../watch/m_timestamp [r]
dir/..../watch/m_watch_file [w]
m_timestamp is set for a file, when its name is written into the m_watch_file-attribute of one of it's parent directories.
This will also add a link to the file back to the directory, so that when the file is changed, the timestamp of both the file and the directory (and so on) are reset.
So what is the values of reset timestamps for all the objects in the path?
That's quite expensive, but it will happen only once per file, until the timestamp for a file was set again by a crawler.
so file_plugin_data is occupied already. I'm not sureThis is why you need a new object plugin with its own methods.
if adding another field outside that union would make reiser4 perform any
worse, but I was just hoping that this plugin can be implemented without
any overhead at all as long as it is not used. A new feature is much more
easily accepted if it doesn't affect you if you don't use it.
Ok, so creating a new file type called "watched_file" seems really the right way. This still leaves the problem where to save per-inode data for this plugin without having to increase the size of a reiser4_inode in general. I don't care much, so before anyone else complains, I'll stop thinking about it ;)
It seems you just need one pointer to in-memory slot of link names (the number of names
is i_nlink). Disk stat-data should be updated by appropriate link operations so its size can
be changed. This can be implemented via killing old stat-data and creating a new one.
There is some methods of the reiser4 object plugin which may be responsible for this update:
->can_add_link() should check if there is enough place in stat-data to add a new name.
->add_link(), ->rem_link() besides inc/dec of i_nlink should update inode's in-memory slot
and kill old/create new stat-data. After killing an old stat-data set a flag REISER4_NO_SD,
so write_sd_by_inode_common() will create a new one. Killing stat-data is unsafe operation
and should be protected (see using of safe_link interface in common_object_delete()).
Edward.
regards Fred
