Re: [gamin] Question on locked mountpoint problem

[John McCutchan <ttb tentacle dhs org>]

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 <ttb tentacle dhs org>