Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 17 Jun 2002 02:54:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 17 Jun 2002 02:52:48 -0400 Received: from david.siemens.de ([192.35.17.14]:42450 "EHLO david.siemens.de") by vger.kernel.org with ESMTP id ; Mon, 17 Jun 2002 02:52:11 -0400 Message-ID: <6134254DE87BD411908B00A0C99B044F039645EB@mowd019a.mow.siemens.ru> From: Borsenkow Andrej To: "'akpm@zip.com.au'" , "'drow@false.org'" Cc: "'linux-kernel@vger.kernel.org'" , "'devfs@oss.sgi.com'" Subject: Re: Inexplicable disk activity trying to load modules on devfs Date: Mon, 17 Jun 2002 10:59:26 +0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1796 Lines: 38 >> >> I just booted into 2.4.19-pre10-ac2 for the first time, and noticed >> something very odd: my disk activity light was flashing at about >> half-second intervals, very regularly, and I could hear the disk >> moving. I was only able to track it down to which disk controller, via >> /proc/interrupts (are there any tools for monitoring VFS activity? >> They'd be really useful). Eventually I hunted down the program causing >> it: xmms. >> >> The reason turned out to be that I hadn't remembered to build my sound >> driver for this kernel version. Every half-second xmms tried to open >> /dev/mixer (and failed, ENOENT). Every time it did that there was >> actual disk activity. Easily reproducible without xmms. Reproducible >> on any non-existant device in devfs, but not for nonexisting files on >> other filesystems. Is something bypassing the normal disk cache >> mechanisms here? That doesn't seem right at all. >> > > >syslog activity from a printk, perhaps? No. It is most probably devfsd trying to load sound modules. This is exactly the reason Mandrake does not enable devfs in kernel-secure. You can badly hit your system by doing in a loop ls /dev/foo for some device foo that is configured for module autoloading. It is very fascist decision; the slightly more forgiving way is to disable devfsd module autoloading (or disable devfsd entirely, just run it once after all drivers are loaded to execute actions) but then you lose support for hot plugging and some people do use kernel-secure on desktops. -andrej - 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/