Re: [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes
- From: nf <nf2 scheinwelt at>
- To: John McCutchan <ttb tentacle dhs org>
- Cc: Nautilus mailing <nautilus-list gnome org>, "Manuel Amador \(Rudd-O\)" <amadorm usm edu ec>, Alexander Larsson <alexl redhat com>
- Subject: Re: [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes
- Date: Sat, 05 Jun 2004 16:10:33 +0200
On Sat, 2004-06-05 at 15:39, John McCutchan wrote:
> On Sat, 2004-06-05 at 05:15, nf2 scheinwelt at wrote:
> > Just to put this right: Nonotify does NOT require open fd's, it does NOT pin
> > down dentries and it does NOT block cdrom ejection.
> > Nonotify just uses a modified stat-call to read the new 'dcontents_mtime' field.
> > Nothing else. Stat-calls don't open fd's and don't block.
> Yes it does. When you call stat() there is a bunch of activity on the
> filesystem that will stop cdrom ejection during the stat call. Assuming
> that nonotify is stat()ing every X ms, there is a race between the
> stat() call and the unmount. So it could happen, but it would be rare.
Interesting point! But is it true? I actually tried to explore this
yesterday by brute-force attacking a mounted dir with stat-calls, but
unmounting never was blocked. It seems that reading the inode-attributes
is "almost" atomic.
I don't know enough about the spin_lock() function. I thought it
synchronizes access to a certain resource, rather than throwing an
error. Can you show me the place in the kernel, where the umount
blocking via "stat" would happen?
] [Thread Prev