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
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
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
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
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
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
--
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
--
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
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
On May 14 2007 16:46, Dave Jones wrote:
>
>*has sudden brainwave*
>
>Ahh, it's doing atime updates. Duh.
FYI+, noatime,nodiratime :)
Jan
--
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