tracking down disk spinups.

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

Re: tracking down disk spinups.

[Xavier Bestel]

Le lundi 14 mai 2007 à 14:57 -0400, Dave Jones a écrit :

> (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.

Are you sure it's the kernel, and not just mount ?
Did you try cat /proc/mounts ?

	Xav

Re: tracking down disk spinups.

[Dave Jones]

On Mon, May 14, 2007 at 09:03:05PM +0200, Xavier Bestel wrote:
 > Le lundi 14 mai 2007 à 14:57 -0400, Dave Jones a écrit :
 > 
 > > (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.
 > 
 > Are you sure it's the kernel, and not just mount ?
 > Did you try cat /proc/mounts ?

Yes.  It's further evidenced that it's ext3 by the fact
that kjournald still shows up in the logs.
Not a single line gets printed to dmesg.

	Dave

-- 
http://www.codemonkey.org.uk

Re: tracking down disk spinups.

[Jeremy Fitzhardinge]

Dave Jones wrote:
> (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.
>   

I don't think you can change filesystem types with remount.  Doesn't
that just change flags on an existing mount?

    J

Re: tracking down disk spinups.

[Xavier Bestel]

Le lundi 14 mai 2007 à 12:24 -0700, Jeremy Fitzhardinge a écrit :
> I don't think you can change filesystem types with remount.  Doesn't
> that just change flags on an existing mount? 

+1

Re: tracking down disk spinups.

[Jan Engelhardt]

On May 14 2007 21:28, Xavier Bestel wrote:
>Le lundi 14 mai 2007 à 12:24 -0700, Jeremy Fitzhardinge a écrit :
>> I don't think you can change filesystem types with remount.  Doesn't
>> that just change flags on an existing mount? 
>
>+1

+2.

Hell, it'd be fun to switch from reiser to xfs by just passing in a -t!


	Jan
-- 

Re: tracking down disk spinups.

[Jan Engelhardt]

On May 14 2007 14:57, Dave Jones wrote:
>
>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..

Perhaps it would help if you use `fuser` to see who's got
open files for read and/or write, then strace all processes
and see who does reads/writes?


	Jan
-- 

Re: tracking down disk spinups.

[Rob Landley]

On Monday 14 May 2007 2:57 pm, Dave Jones wrote:
> 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.

Remount doesn't switch filesystem drivers, it tells the existing filesystem 
driver to accept new flags and/or a new option string.

To switch drivers you have to umount the old sucker and mount the new one.  
(The idea of handing off consistent cache data from one mounted filesystem 
driver to another...  Ouch.)

Most filesystem drivers aren't compatible with each other anyway.  Sounds like 
what you really want to do is put the ext3 driver into "ext2 mode", and stop 
journaling.  Many people have wanted this over the years, but alas our dream 
of "one darn driver for the ext# family" got squashed years ago because 
people wanted two different codebases for the same filesystem that could 
diverge, require the same bugs to be fixed twice, become incompatible...

Rob

Re: tracking down disk spinups.

[Dave Jones]

On Mon, May 14, 2007 at 04:28:35PM -0400, Rob Landley wrote:
 > On Monday 14 May 2007 2:57 pm, Dave Jones wrote:
 > > 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.
 > 
 > Remount doesn't switch filesystem drivers, it tells the existing filesystem 
 > driver to accept new flags and/or a new option string.

yes, I had misinterpreted what 'remount' did. I thought behind the scenes
it actually did a umount/mount.

 > To switch drivers you have to umount the old sucker and mount the new one.  
 > (The idea of handing off consistent cache data from one mounted filesystem 
 > driver to another...  Ouch.)

a umount would purge the cache, but that's irrelevant given it doesn't
work that way.

Anyways, I rebooted after s/ext3/ext2/ on my fstab, and found things
hadn't really got any more obvious what was going on.
Instead of 'kjournald' writing stuff out, now it's 'pdflush'.

*has sudden brainwave*

Ahh, it's doing atime updates. Duh.

	Dave

-- 
http://www.codemonkey.org.uk

Re: tracking down disk spinups.

[Jan Engelhardt]

On May 14 2007 16:46, Dave Jones wrote:
>
>*has sudden brainwave*
>
>Ahh, it's doing atime updates. Duh.

FYI+, noatime,nodiratime :)


	Jan
-- 

Re: tracking down disk spinups.

[Rob Landley]

On Monday 14 May 2007 4:46 pm, Dave Jones wrote:
> On Mon, May 14, 2007 at 04:28:35PM -0400, Rob Landley wrote:
>  > On Monday 14 May 2007 2:57 pm, Dave Jones wrote:
>  > > 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.
>  > 
>  > Remount doesn't switch filesystem drivers, it tells the existing 
filesystem 
>  > driver to accept new flags and/or a new option string.
> 
> yes, I had misinterpreted what 'remount' did. I thought behind the scenes
> it actually did a umount/mount.

I implemented the BusyBox mount command last year.  (Well, rewrote three times 
until just about none of the old code was left.)  Getting remount to work 
right is a monster headache.  (The new flags _replace_ the old flags, not 
delta against them, so you have to parse /etc/mtab (or /proc/mounts), read 
the old flags out of that, mask them yourself, and supply them back in.  And 
of course, not all of them are flags, some remain strings, but you can't keep 
strings you turned into flags because the driver will barf that it's an 
unrecognized string option...  Headache.  And don't get me started on vfat 
spitting back string options from /proc/mounts that are THE DEFAULT VALUES...  
Grrr.  I'll stop now.)

You can always umount/mount yourself.

>  > To switch drivers you have to umount the old sucker and mount the new 
one.  
>  > (The idea of handing off consistent cache data from one mounted 
filesystem 
>  > driver to another...  Ouch.)
> 
> a umount would purge the cache, but that's irrelevant given it doesn't
> work that way.
> 
> Anyways, I rebooted after s/ext3/ext2/ on my fstab, and found things
> hadn't really got any more obvious what was going on.
> Instead of 'kjournald' writing stuff out, now it's 'pdflush'.
> 
> *has sudden brainwave*
> 
> Ahh, it's doing atime updates. Duh.

I had to add MS_SILENT (1<<15) to the default mount options for busybox 
(because otherwise the kernel got log message diarrhea).  I was seriously 
tempted to add MS_NOATIME to that, but didn't.

I should write up a good "mount" spec, from the kernel's point of view.  
(There isn't one.  I looked.)

Rob