tracking down disk spinups.

[Dave Jones]

I was curious why my firewall box never spins down its disk.
Given it rarely writes stuff to logs, it's odd that it always
seems to have something to write out.
killing syslogd, and enabling /proc/sys/vm/block_dump
gets me a periodic spew in /proc/kmsg like..

<7>[2695397.990000] kjournald(366): WRITE block 243056 on dm-0
<7>[2695397.990000] kjournald(366): WRITE block 243064 on dm-0
<7>[2695397.990000] kjournald(366): WRITE block 243072 on dm-0
<7>[2695397.990000] kjournald(366): WRITE block 243080 on dm-0

How do I map those blocks back to files ?
I tried mapping these from blocks->inodes->names using debugfs
but that doesn't get me very far..

debugfs:  icheck 243056
Block   Inode number
243056  <block not found>



Given the dirtying process name is kinda useless, I wondered if I'd get
something more useful if I used ext2 instead of ext3, when I found
this oddness..

(14:49:52:root@firewall:~)# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
(14:49:56:root@firewall:~)# mount /dev/mapper/VolGroup00-LogVol00 / -t ext2 -o remount,rw
(14:50:37:root@firewall:~)# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)

Why did the kernel ignore what I told it to do ?
I'm sure it thinks it knows better than me for a reason, but
I'd like to know what it is.

	Dave

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