From: Rob Landley <rob@landley.net>
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: tracking down disk spinups.
Date: Tue, 15 May 2007 00:49:06 -0400 [thread overview]
Message-ID: <200705150049.06974.rob@landley.net> (raw)
In-Reply-To: <20070514204651.GA7242@redhat.com>
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
prev parent reply other threads:[~2007-05-15 4:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-14 18:57 tracking down disk spinups Dave Jones
2007-05-14 19:03 ` Xavier Bestel
2007-05-14 19:21 ` Dave Jones
2007-05-14 19:24 ` Jeremy Fitzhardinge
2007-05-14 19:28 ` Xavier Bestel
2007-05-14 20:12 ` Jan Engelhardt
2007-05-14 20:13 ` Jan Engelhardt
2007-05-14 20:28 ` Rob Landley
2007-05-14 20:46 ` Dave Jones
2007-05-14 21:02 ` Jan Engelhardt
2007-05-15 4:49 ` Rob Landley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705150049.06974.rob@landley.net \
--to=rob@landley.net \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox