All of lore.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 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.