public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Samwel <bart@samwel.tk>
To: bill davidsen <davidsen@tmr.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)
Date: Tue, 27 Jan 2004 16:16:30 +0100	[thread overview]
Message-ID: <401680CE.2080007@samwel.tk> (raw)
In-Reply-To: <bv4atl$77d$1@gatekeeper.tmr.com>

bill davidsen wrote:
> In article <20040125205219.GE26600@luna.mooo.com>,
> Micha Feigin  <michf@post.tau.ac.il> wrote:
> 
> | There are two things to do. First you should mount the disk with the
> | noatime option.
> 
> Hopefully on an idle system there isn't any access, so there isn't any
> atime impact. It would be nice if the atime write was very lazy, as in
> only when the file is closed or something. Like an atimeonclose option.

> | The other thing is ext3 which is updating its journal every 5
> | seconds. I was told that laptop-mode was imported into 2.6 by now (I
> | think that it is in the main stream). Check the kernel docs there
> | should be some mount option to state the dirty time for the ext3
> | journal. The method changed since 2.4 so I don't remember the 2.6
> | option since I don't use it yet, sorry.
> 
> Someone will have to explain that one, in a normal mount I would not
> expect an idle system to be doing anything on the filesystems.

Anything that reads anything from a filesystem updates the atime, I 
guess, even though the read data comes from the cache. This means that 
pages are dirtied, and they need to be written back. The atime is part 
of the filesystem metadata, so that might explain metadata journaling 
activity. AFAICS your system is not truly idle w.r.t the disk in 
question. Mount it with noatime and see if you can spin it down when you 
know it should really be idle. (You can use hdparm -y on it to spin it 
down by hand, so you don't have to wait for the hardware timer.) If it 
still spins up without atime, you know it isn't really idle, so you need 
to find out what app is accessing the disk. A look at the output of 
"lsof" can be enlightening. If that doesn't help, you can try to use 
laptop mode's block_dump functionality (without enabling laptop mode 
itself!) to see which process is reading/writing which block.

Laptop mode is not in 2.6 mainstream yet, it can be found in the -mm 
series. After you're done using block_dump you can get rid of laptop 
mode again: you don't need the actual mode, the spun-down times it gets 
you are way too short for your needs. Furthermore it's indiscriminate 
w.r.t disks, so it would have an undesired effect on your other disk as 
well.

-- Bart

  reply	other threads:[~2004-01-27 15:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-25 18:29 Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs) Lutz Vieweg
2004-01-25 18:33 ` Andreas Dilger
2004-01-25 18:56 ` Matthias Andree
2004-01-25 19:26 ` Felipe Alfaro Solana
2004-01-26 10:16   ` Lutz Vieweg
2004-01-26 10:43     ` Nick Piggin
2004-01-26 10:43     ` Bart Samwel
2004-01-25 20:52 ` Micha Feigin
2004-01-27  0:21   ` bill davidsen
2004-01-27 15:16     ` Bart Samwel [this message]
2004-01-27 18:44       ` Bill Davidsen
2004-01-27 18:54         ` Bart Samwel
2004-01-28 13:30           ` Lutz Vieweg
2004-01-28 23:06             ` Micha Feigin
2004-01-29 12:51               ` Bart Samwel

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=401680CE.2080007@samwel.tk \
    --to=bart@samwel.tk \
    --cc=davidsen@tmr.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