public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox