Comment 29 for bug 332270

My setup:

Dual core X2, 2gb ram, sata hard disk (sdaX), etc.

A windows vista partition (came with laptop -rarely- used... 'when I have to')
A normal boot partition
An LVM partition

crypttab
rootvolume /dev/ubuntu/encryptedroot none luks,retry=1
homevolume /dev/ubuntu/encryptedhome none luks,retry=1
mediavol /dev/ubuntu/media none luks,retry=1

fstab
/dev/mapper/rootvolume / ext3 relatime,errors=remount-ro 0 0
/dev/mapper/homevolume /home ext3 relatime 0 2
/dev/mapper/mediavol /media/m ext3 relatime 0 2
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

I am going to postulate where the problem originates by explaining an earlier statement I made.

"< IntuitiveNipple> "Device nodes can be watched for changes with inotify with OPTIONS="watch". If closed after being opened for writing, a "change" uevent will occur."
- -
So... any time a close event happens a change event will be triggered... and presumably logged?
Which could then re-open and ..."

I have three ext3 partitions with internal logging, all of which live inside of encrypted LVM containers. I am unsure where in the chain the problem occurs, but this is what I think may be happening.

1) Something modifies the state of the disk, logging info/etc.
2) That change constitutes a change event.
3) Change events are bad, but even worse, may be logged, feeding back in to step 1.

A recursive notification loop would thus form.

In conclusion, to quote a line I said in IRC "what lesson did this illustrate: Never inotify for normal operations of a special device file..."