From: "Rüdiger Klaehn" <rudi@gamemakers.de>
To: John McCutchan <ttb@tentacle.dhs.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC,PATCH] dnotify: enhance or replace?
Date: Wed, 24 Mar 2004 17:54:06 +0100 [thread overview]
Message-ID: <4061BD2E.2060900@gamemakers.de> (raw)
In-Reply-To: <1080146269.23224.5.camel@vertex>
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.
next prev parent reply other threads:[~2004-03-24 16:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-24 14:17 [RFC,PATCH] dnotify: enhance or replace? Rüdiger Klaehn
2004-03-24 15:40 ` Alexander Larsson
2004-03-24 16:15 ` Rüdiger Klaehn
[not found] ` <1080202140.8108.101.camel@localhost.localdomain>
2004-03-26 9:52 ` Rüdiger Klaehn
[not found] ` <4062C63F.6050907@gamemakers.de>
[not found] ` <1080219862.8108.138.camel@localhost.localdomain>
2004-03-26 9:59 ` Rüdiger Klaehn
2004-03-24 16:37 ` John McCutchan
2004-03-24 16:54 ` Rüdiger Klaehn [this message]
2004-03-24 19:53 ` John McCutchan
2004-03-24 20:00 ` Paul Rolland
2004-03-24 20:04 ` viro
2004-03-26 10:12 ` Rüdiger Klaehn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4061BD2E.2060900@gamemakers.de \
--to=rudi@gamemakers.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rudi@lambda-computing.de \
--cc=ttb@tentacle.dhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.