I have no gkrellmd running.
I used swapoff without success.
I use reiserfs and it's not the problem.
Going to single user mode solves my problem. No more accesses, but i don't know what is really the problem ...

I killed all processes one by one, and this is what i got now (except X stuff, but as i said before, i have this problem, even without going into graphical mode) :

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 764 304 ? Ss 21:26 0:00 init [4]
root 2 0.0 0.0 0 0 ? S< 21:26 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S< 21:26 0:00 [migration/0]
root 4 0.0 0.0 0 0 ? S< 21:26 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< 21:26 0:00 [migration/1]
root 6 0.0 0.0 0 0 ? S< 21:26 0:00 [ksoftirqd/1]
root 7 0.0 0.0 0 0 ? S< 21:26 0:00 [events/0]
root 8 0.0 0.0 0 0 ? S< 21:26 0:00 [events/1]
root 9 0.0 0.0 0 0 ? S< 21:26 0:00 [khelper]
root 42 0.0 0.0 0 0 ? S< 21:26 0:00 [kblockd/0]
root 43 0.0 0.0 0 0 ? S< 21:26 0:00 [kblockd/1]
root 45 0.0 0.0 0 0 ? S< 21:26 0:00 [kacpid]
root 46 0.0 0.0 0 0 ? S< 21:26 0:00 [kacpi_notify]
root 218 0.0 0.0 0 0 ? S< 21:26 0:00 [ata/0]
root 219 0.0 0.0 0 0 ? S< 21:26 0:00 [ata/1]
root 220 0.0 0.0 0 0 ? S< 21:26 0:00 [ata_aux]
root 222 0.0 0.0 0 0 ? S< 21:26 0:00 [kseriod]
root 256 0.0 0.0 0 0 ? S 21:26 0:00 [pdflush]
root 257 0.0 0.0 0 0 ? S 21:26 0:00 [pdflush]
root 258 0.0 0.0 0 0 ? S< 21:26 0:00 [kswapd0]
root 259 0.0 0.0 0 0 ? S< 21:26 0:00 [aio/0]
root 260 0.0 0.0 0 0 ? S< 21:26 0:00 [aio/1]
root 362 0.0 0.0 0 0 ? S< 21:26 0:00 [scsi_eh_0]
root 364 0.0 0.0 0 0 ? S< 21:26 0:00 [scsi_eh_1]
root 380 0.0 0.0 0 0 ? S< 21:26 0:00 [scsi_eh_2]
root 382 0.0 0.0 0 0 ? S< 21:26 0:00 [scsi_eh_3]
root 386 0.0 0.0 0 0 ? S< 21:26 0:00 [scsi_eh_4]
root 388 0.0 0.0 0 0 ? S< 21:26 0:00 [scsi_eh_5]
root 397 0.0 0.0 0 0 ? S< 21:26 0:00 [kpsmoused]
root 401 0.0 0.0 0 0 ? S< 21:26 0:00 [rpciod/0]
root 402 0.0 0.0 0 0 ? S< 21:26 0:00 [rpciod/1]
root 403 0.0 0.0 0 0 ? S< 21:26 0:00 [kirqd]
root 404 0.0 0.0 0 0 ? S< 21:26 0:00 [reiserfs/0]
root 405 0.0 0.0 0 0 ? S< 21:26 0:00 [reiserfs/1]
root 1019 0.0 0.0 0 0 ? S< 21:26 0:00 [khpsbpkt]
root 1126 0.0 0.0 0 0 ? S< 21:26 0:00 [knodemgrd_0]
root 1214 0.0 0.0 0 0 ? S< 21:26 0:00 [ksuspend_usbd]
root 1216 0.0 0.0 0 0 ? S< 21:26 0:00 [khubd]
root 2674 0.0 0.0 0 0 ? S< 21:27 0:00 [loop0]
root 2676 0.0 0.0 0 0 ? S< 21:27 0:00 [loop1]
root 5056 0.0 0.0 0 0 ? S< 22:02 0:00 [loop2]
root 5058 0.0 0.0 0 0 ? S< 22:02 0:00 [loop3]
root 5362 0.0 0.0 1656 536 tty6 Ss+ 22:03 0:00 /sbin/agetty 38400 tty6 linux
root 6898 0.0 0.0 0 0 ? S 22:04 0:00 [lockd]
root 6900 0.0 0.0 0 0 ? S< 22:04 0:00 [loop4]
root 6902 0.0 0.0 0 0 ? S< 22:04 0:00 [loop5]

Then compare your '/etc/rc.d/rc.K' (single user init script) to your '/etc/rc.d/rc.M' (multi-user init script), it's gotta be something listed in 'rc.M' but not in 'rc.K'.

Is your hard drive light in any way connected to the CD-ROM interface? If so, you might be seeing the kernel polling the CD-ROM to see if any new media has been inserted. It's a shot in the dark...

This would happen, imo, only when you have both cd-rom and hdd connected with the same IDE cable as master & slave. In old PCs motherboards were probing cd-roms if they have anything inside, but I don't think it is the case now.

I have exactly the same "problem" on my Slackware 12 servers. The HD led lights up once every 3-4 seconds, even if I shutdown all running services (Postfix, Samba, Apache, Dovecot).

Apparently it doesn't hurt anything, or at least I haven't experienced any kind of slowdown.

All computers are running with a RAID 1 setup with 2 or 3 SATA disks.

I've noticed that this is happening with most of my Slackware 12 install, be it servers or desktop, whereas my Slackware 11 installs don't seem to be suffering from the same urge to turn on the HD led.

Hmm, perhaps it's worth noting that all my Slackware 11 installs are using IDE disks.. I don't know.

rmmod all modules, maybe one of them is probing something

I separated krellms for each block device. Only / and /home are active. They are only writings on it.

I use SATA drives.

rc.M is a lot more populated .

Removed a lot. Now there's nothing suspicious.

It must exist something that tells me "this file is currently being read/write".
Should i increase some system log level ?

Nope - no-one cares.
The I/O schedulers are designed specifically to aggregate the I/Os so the head movement is minimized- and to delay the physical I/Os so this check can be made. This means that multiple (physical) I/Os that are "close" are issued together - but probably out of the order they were issued.

NOOP might offer some prospects, but I know of nothing to do the "backward mapping".

You may use laptop-mode tools from http://samwel.tk/laptop_mode/
Laptop-mode makes the hard disk spin down to save power and as such pinpointing drive-awaking applications is crucial.
Start with http://samwel.tk/laptop_mode/faq , section "Spinup Debugging".

bash-3.1# inotifywatch -r -v /home/
Establishing watches...
Setting up watch(es) on /home/
OK, /home/ is now being watched.
Total of 5777 watches.
Finished establishing watches, now collecting statistics.
total access close_nowrite open filename
12 4 4 4 /home/me/

Greetings,

This looks like a good place for me to add my 'blinking HDD light' situation..

I am using an MSI P6N-SLI-FI nVidia-chipset motherboard, connected to which are 2 PATA/IDE hard-disks (IDE0) and 2 PATA/IDE optical drives (IDE1). All has been and still is working fine since the board was new...

I recently installed a SATA DVD-R/W unit which I got for Xmas. I then added SATA support to the kernel (2.6.22.5), recompiled and rebooted, and the new SATA drive and the 4 IDE drives all appear to be working properly, but for one small issue: after accessing the SATA drive in any way, the HDD activity light begins blinking at a near perfect 2 Hz rate.
There is no disk activity to speak of, and everything otherwise is still working just fine, including all the drives; but this steady blink continues forever until I log out and/or go to init 1. When I log back in, it no longer blinks, until I once again access the SATA drive (eg, sw-ejecting it, or reading a disc).

Google shows a few similar tales but no (useful) suggestions as yet, except to try a different SATA port (which I will try for the heck of it)... TOP or KDE-Sysguard shows 'ps#376 scsi_eh_0' (the SCSI Error Handler) which has 0 CPU time and 0% resources used, but occasionally it flicks from 'sleeping' to 'disk sleep'.

The nVidia Users forum has one relevant thread, but the respondents seem to be misunderstanding the issue.

I am far from done looking into this, but if there's anyone out there with a similar issue or some ideas, please feel free....

SVA

EDIT - I haven't changed ANYTHING and yet the issue is... (temporarily)... gone...

Take a look at this:
http://git.kernel.org/?p=linux/kerne...f4c836;hb=HEAD