Re: udevd is killing file write performance.

[Robin Holt <holt@sgi.com>]

On Wed, Feb 22, 2006 at 11:48:23AM -0500, John McCutchan wrote:
> On Wed, 2006-22-02 at 07:42 -0600, Robin Holt wrote:
> > 
> > I know _VERY_ little about filesystems.  udevd appears to be looking
> > at /etc/udev/rules.d.  This bumps inotify_watches to 1.  The file
> > being written is on an xfs filesystem mounted at a different mountpoint.
> > Could the inotify flag be moved from a global to a sb (or something
> > finer) point and therefore avoid taking the dentry->d_lock when there
> > is no possibility of a watch event being queued.
> 
> We could do this, and avoid the problem, but only in this specific
> scenario. The file being written is on a different mountpoint but whats
> to stop a different app from running inotify on that mount point?
> Perhaps the program could be altered instead? 

Looking at fsnotify_access() I think we could hit the same scenario.
Are you proposing we alter any appliction where multiple threads read
a single data file to first make a hard link to that data file and each
read from their private copy?  I don't think that is a very reasonable
suggestion.

Let me reiterate, I know _VERY_ little about filesystems.  Can the
dentry->d_lock be changed to a read/write lock?

Thanks,
Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/