[haiku-development] Re: file modification watching
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 18 Jun 2011 14:38:05 +0200
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.
> While that could be done, you have to take into account that the node -
> > path pair is not just a pair, but each node can have any number of
> > paths. For the problem you are trying to solve, this is not really
> important though. Furthermore, a path can change at any time, which
> makes it quite annoying to keep up.
>
> But for that particular problem, it's also not needed to go this route.
> For one, BFS always knows the parent of an inode (as it doesn't support
> hard links, and needs this feature for queries to work), so it wouldn't
> be needed to store the data twice in that case, anyway.
>
> But since this would only work for BFS, one could also just allow root
> to open any known node_ref, just like every directory can be opened via
> a node_ref. The vnode will be in the VFS anyway while the file is open,
> and even if you're not fast enough, and didn't open it in time, chances
> are very good that the vnode is still around afterwards. You could even
> make it 100% reliable with a callback mechanism if needed.
If the vnode limit is reached, the vnode will be deleted as soon as its
last reference has been released. For some (most?) file systems it is not
trivial to open a node by ID. I suspect even BFS would have to traverse the
complete file system to do that safely (I don't think allowing root an
unsafe operation is a good idea). For some file systems (e.g. those that
assign node IDs dynamically when loading a node) it is even impossible to
do that.
> > Another not directly related question, why the fs and not the vfs is
> > responsible to send out notifications? At least for most
> > notifications it
> > seams possible to me that the vfs has all needed information and can
> > send
> > the message.
>
> I have a faint memory that there was a good reason (like a network file
> system is a good reason, as the VFS would only know the things that it
> did itself), but I don't remember it right away (I think there was
> something else), and have no time right now -- maybe Ingo can chime in
> though ;-)
Yeah, network FSs (similarly packagefs) or FSs that implement operations
with side-effects or additional operations (e.g. via ioctls) are one
reason. The other reason is that one cannot implement it without race
conditions in the VFS (or without artificially serializing operations).
Regarding the index server problem in general, I don't see why it cannot be
solved there. As I see it, the index DB should already store a node -> path
(or entry ref) map, so that the indexed contents can just refer to nodes.
CU, Ingo
Other related posts:
