Subject: Re: udevd is killing file write performance.
From: John McCutchan <john@johnmccutchan.com>
Reply-To: john@johnmccutchan.com
To: Robin Holt <holt@sgi.com>
Cc: linux-kernel@vger.kernel.org, rml@novell.com, arnd@arndb.de, hch@lst.de,
       akpm@osdl.org
In-Reply-To: <20060222134250.GE20786@lnx-holt.americas.sgi.com>
References: <20060222134250.GE20786@lnx-holt.americas.sgi.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Feb 2006 11:48:23 -0500
Message-Id: <1140626903.13461.5.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1005
Lines: 21

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? 

-- 
John McCutchan <john@johnmccutchan.com>
-
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/