On Fri, 2005-06-17 at 00:47 +0300, Martin Pärtel wrote: > Hello, > > Do I understand correctly that when gamin is using inotify inside a > mountpoint > it always prevents umounting whereas when it's using polling this is never > (?) a problem? >
No, you don't understand correctly. When gamin is using dnotify, it can cause mount point problems. With inotify there can't be any. Also, new versions of gamin do their best to avoid this problem by not using dnotify on any path that looks like a removable device. > I skimmed the kernel's inotify.c source file and it looked like there was one > syscall to register a process to receive events on an inode. This apparently > makes the mountpoint the inode is in unumountable because some reference > count is incremented, right? Inotify does indeed reference the inodes, but the kernel notifies inotify when it is about to unmount a filesystem, giving us time to clean up. > > My question is, why doesn't the kernel provide an interface to watch inodes > without "locking" them like that. Why couldn't it send "this inode went away" > events when an fs is umounted? Inotify provides just that. When you are watching something with inotify, you will receive an IN_UNMOUNT event when the filesystem is unmounted. Inotify hooks into the kernel, so when an unmount is about to happen, we unref all the inodes and send the events. Then the kernel code checks to make sure that nothing is left using it, as usual. -- John McCutchan <[EMAIL PROTECTED]> _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
