Re: [RFC,PATCH] dnotify: enhance or replace?

[Rüdiger Klaehn]

Alexander Larsson wrote:

[snip]
>>About recursive notification:
>>
>>Some way to watch for changes on a whole file system is a must.
>>Otherwise there is really no need to replace dnotify. When I start up
>>KDE it watches for 256 different directories in my /home directory. It
>>would probably watch even more directories if it could. With recursive
>>watching it would only need to watch two or three directories 
recursively.
>
>
> I see no reasons for a file manager to monitor all of $HOME, unless
> you're showing all of it. Getting all the events for $HOME will just
> cause things to be slower.
>
I don't know why KDE does this. Probably because of the .desktop files.
  But I can see plenty of reasons to monitor large trees. For example to
keep some kind of metadata consistent with data.

What is everybodys obsession with file managers anyway? They are the
most *boring* application of an enhanced file change mechanism, and
certainly not the most demanding.

[snip]
>>This would require large changes, and I think figuring out all aliases
>>to a path might as well be done in userspace. You don't gain much by
>>putting this in the kernel, and it requires a lot of complexity.
>
>
> There is no sane way to do that in userspace. How would you find all the
> aliases? traverse the whole filesystem?
 >
This would indeed be an expensive operation. You would need a mapping
from paths to inode numbers for the files you want to watch. If you just
want to watch for changes for a single file or a small subdirectory it
is not that bad though.

Want me to code this into my userspace tool to see what I mean? I am
100% certain it can be done as long as you have inode numbers or
something else to uniquely and persistently identify a file (as opposed
to the name of the file). Unfortunately inode numbers are not unique and
persistent on all file systems, but for e.g. ext3 it should be no problem.

 > What if a new alias was created?
>
You would get an event. And the new alias would point to the same file.
No problem there.

>
>>>* Some way to get an event when the last open fd to the file is closed
>>>after a file change. This means you won't get hundreds of write events
>>>for a single file change. (Of course, you won't catch writes to e.g.
>>>logs which aren't closed, so this has to be optional. But for a desktop,
>>>this is often what you want.)
>>>
>>
>>Should be no problem to add this with the current approach. But it is
>>not that bad if you are getting hundreds of write events for a single
>>file. They are just 32 bytes, so you can just throw them away in the
>>userspace if you are not interested in them.
>
>
> If you get a changed event for every write() to a file downloading to
> the desktop then fam and the filemanager will use 100% cpu while
> downloading. Been there, done that, added the rate limiter. However the
> rate limiter doesn't fix the cpu use from just getting and ignoring all
> the events.
>
Strange. I have my userspace tool running on the first console. It is
watching for everything on "/" (throwing away most of it immediately). I
am downloading various stuff with mldonkey, playing an mp3 file with
xmms, and running a KDE session and mozilla.

My CPU load is at an average of 5%. (Athlon 2500+ with 512mb ram)

If the file manager insists on redrawing itself each time he gets a
write event, you would get 100% cpu. But such a braindead implementation
should not be blamed on the notification mechanism.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/