Messages in this thread | | | Date | Wed, 24 Mar 2004 17:54:06 +0100 | From | Rüdiger Klaehn <> | Subject | Re: [RFC,PATCH] dnotify: enhance or replace? |
| |
John McCutchan wrote:
[snip] > Maybe adding a rate limiter on these write events would be a better > idea, live updates are usefull for the desktop. Also with a netlink > socket I think the overhead of many events would drop siginificantly. > You could always merge read/write events if you get too many of them. E.g. write [10,11] + write [11,12] => write [10,12]. But I never had event buffer overflows with my tests. And a buffer of a few kbytes per file system for fam won't be that bad, so I am not sure wether it is nessecary to do something as complicated as rate limiting or merging.
> Also a couple other items I think need to be on the list of features, > > * Some way to not have an open file descriptor for each directory you > are monitoring. This causes so many problems when unmounting, and this > is really the most noticable problem for the user. > You can monitor a whole tree with a single file descriptor. But you need at least one open fd per file system, so it would indeed be a problem when unmounting.
> * Better event vocabulary, we should fire events for all VFS ops. I > think right now it is limited to delete,create,written to. It would be > good to tell the listener exactly what happened, moved,renamed, etc. > I had this for a short time, but I threw it away since I wanted to concentrate on the event dispatch infrastructure first. It would not be a big problem to add this again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |