https://bugzilla.novell.com/show_bug.cgi?id=281147 joeshaw@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpr@novell.com ------- Comment #2 from joeshaw@novell.com 2007-06-06 09:37 MST ------- (In reply to comment #1)
IMHO this is a BUG in Beagle. Why Beagle does this?
It gets notification of file changes so that they can be indexed in real time. It's no different from file managers like Nautilus or Konqueror listening for changes on the directories its viewing.
This slows down the system e.g. think about a multi users system and more then 100 co-workers on such a system. I do not like this kind of workarounds, please fix the application its self.
You're conflating two different problems here. Simply setting up watches doesn't have any real effect on the system performance. It's how the application uses it. I'm happy to have a conversation on how to improve Beagle's performance and behavior, but it's a totally orthogonal discussion. In the specific case of Beagle, with all else being equal, it would make the system a lot *slower* if Beagle had to continuously recrawl the user's home directory to watch for changes. Without complete file notification, this is the only alternative. Inotify was written specifically for this use case. This problem will eventually come up for any application which needs to watch changes across a large number of directories, it's not a workaround and it's not Beagle-specific.
The question is: why Beagle requires such a large amount of watch points for monitoring file system events?
It requires one watch per directory. How many directories you have is entirely dependent upon how big your home directory is set up, and developers with huge source trees often hit this limit. You can roughly count the number of directories to be indexed with this command: find . -type d | grep -v "^\.\/\." | wc -l (You may also want to grep out CVS and any dot-directories like .svn) On my desktop machine, it's 47720 and that's a 104 gigabyte home directory. So it's a pretty reasonable upper limit, IMO. As to the 100-user use case you mention, in the unlikely case that there are that many users with huge home directories such that kernel memory does become scarce, then the system administrator can edit /etc/sysctl.conf and reduce it. That's why it's a sysctl and not a hardcoded value in the kernel. But using that use case to justify not doing it is weak because it's the vast minority of our users. It may make sense for SLES, and if we could only change it there (and not also in SLED) then perhaps we should. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.