[RFC][PATCH] inotify 0.8.1

[RFC][PATCH] inotify 0.8.1

[John McCutchan]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

I am resubmitting inotify for comments and review. Inotify has
changed drastically from the earlier proposal that Al Viro did not
approve of. There is no longer any use of (device number, inode number)
pairs. Please give this version of inotify a fresh view.

Inotify is designed as a replacement for dnotify. The key difference's
are that inotify does not require the file to be opened to watch it,
when you are watching something with inotify it can go away (if path
is unmounted) and you will be sent an event telling you it is gone and
events are delivered over a fd not by using signals.

Inotify is a character device that when opened offers 2 IOCTL's.
(It actually has 4 but the other 2 are used for debugging)

INOTIFY_WATCH:
        Which takes a path and event mask and returns a unique 
        (to the instance of the driver) integer (wd [watcher descriptor]
        from here on) that is a 1:1 mapping to the path passed. 
        What happens is inotify gets the inode (and ref's the inode)
        for the path and adds a inotify_watcher structure to the inodes
        list of watchers. If this instance of the driver is already
        watching the path, the event mask will be updated and
        the original wd will be returned.

INOTIFY_IGNORE:
        Which takes an integer (that you got from INOTIFY_WATCH) 
        representing a wd that you are not interested in watching
        anymore. This will:

        send an IGNORE event to the device
        remove the inotify_watcher structure from the device and 
        from the inode and unref the inode.
        

After you are watching 1 or more paths, you can read from the fd
and get events. The events are struct inotify_event. If you are
watching a directory and something happens to a file in the directory
the event will contain the filename (just the filename not the full
path).


Aside from the inotify character device driver. 
The changes to the kernel are very minor. 

The first change is adding calls to inotify_inode_queue_event and
inotify_dentry_parent_queue_event from the various vfs functions. This
is identical to dnotify.

The second change is more serious, it adds a call to
inotify_super_block_umount
inside generic_shutdown_superblock. What inotify_super_block_umount does
is:

find all of the inodes that are on the super block being shut down,
sends each watcher on each inode the UNMOUNT and IGNORED event
removes the watcher structures from each instance of the device driver 
and each inode.
unref's the inode.

I have tested this code on my system for over three weeks now and have
not had problems. I would appreciate design review, code review and
testing.


Attached is the patch to Linux 2.6.8

John

[-- Attachment #2: inotify-0.8.1.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 10066 bytes --]

Re: [RFC][PATCH] inotify 0.8.1 [u]

[Martin Schlemmer [c]]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Thu, 2004-08-19 at 06:32, John McCutchan wrote:

Hi

> I am resubmitting inotify for comments and review. Inotify has
> changed drastically from the earlier proposal that Al Viro did not
> approve of. There is no longer any use of (device number, inode number)
> pairs. Please give this version of inotify a fresh view.
> 

I applied this to 2.6.8.1 and most of -mm4's patches - it applied
cleanly and compiled fine.

I use devicemapper to stripe two 80gb sata drives on intel sata
controller, using initramfs.

Now when I boot, I see something like:

---
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
Freeing unused kernel memory: 264k freed
inotify device opened
dm ioctl error or such
---

Which then results in a panic as the dm volumes cannot be setup
and no / found by kernel.  So basically it seems like inotify
mess with dm in some way or other - any quick ideas what it
could be?

I do not have serial console, so if you need a more complete log,
just let me know from where abouts I should start, and if any
debugging should be turned on, etc.


Thanks,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][PATCH] inotify 0.8.1 [u]

[John McCutchan]

On Mon, 2004-08-23 at 15:44, Martin Schlemmer [c] wrote:
> On Thu, 2004-08-19 at 06:32, John McCutchan wrote:
> 
> Hi
> 
> > I am resubmitting inotify for comments and review. Inotify has
> > changed drastically from the earlier proposal that Al Viro did not
> > approve of. There is no longer any use of (device number, inode number)
> > pairs. Please give this version of inotify a fresh view.
> > 
> 
> I applied this to 2.6.8.1 and most of -mm4's patches - it applied
> cleanly and compiled fine.
> 
> I use devicemapper to stripe two 80gb sata drives on intel sata
> controller, using initramfs.
> 
> Now when I boot, I see something like:
> 
> ---
> BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
> Freeing unused kernel memory: 264k freed
> inotify device opened
> dm ioctl error or such
> ---
> Which then results in a panic as the dm volumes cannot be setup
> and no / found by kernel.  So basically it seems like inotify
> mess with dm in some way or other - any quick ideas what it
> could be?
> 

This is very strange. 'inotify device opened' is printed when an app
opens /dev/inotify. Do you have code that is doing that? I am wondering
if inotify's MAJOR/MINOR is getting confused with device mappers. I
don't know how it could be happening since /dev/inotify has the kernel
assign it an available minor number, and its major number is the major
number for all misc char devices.

> I do not have serial console, so if you need a more complete log,
> just let me know from where abouts I should start, and if any
> debugging should be turned on, etc.

Could you find out what the major/minor numbers are on /dev/inotify and
whatever dev device mapper has?

Thanks for testing.

John