lkml.org 
[lkml]   [2004]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.048 / U:1.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site