Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)

Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to let the harddisk spin down - I found out that "kjournald" writes a few blocks every few seconds.

I run a server that usually doesn't have to do anything on the local filesystems, it just needs to answer some requests and perform some computations in RAM.

So I use the "hdparm -S 123" parameter setting to keep the (IDE) system disk from spinning unneccessarily.

Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to let the harddisk spin down - I found out that "kjournald" writes a few blocks every few seconds.

As I wouldn't like to downgrade to ext2: Is there any way to keep the 2.6 kjournald from writing to idle disks?

I cannot see a good reason why kjournald would write when there are no dirty buffers - but still it does.

Hi everyone,

I run a server that usually doesn't have to do anything on the local filesystems, it just needs to answer some requests and perform some computations in RAM.

So I use the "hdparm -S 123" parameter setting to keep the (IDE) system disk from spinning unneccessarily.

Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to let the harddisk spin down - I found out that "kjournald" writes a few blocks every few seconds.

As I wouldn't like to downgrade to ext2: Is there any way to keep the 2.6 kjournald from writing to idle disks?

I cannot see a good reason why kjournald would write when there are no dirty buffers - but still it does.

Hi everyone,

I run a server that usually doesn't have to do anything on the local filesystems,
it just needs to answer some requests and perform some computations in RAM.

So I use the "hdparm -S 123" parameter setting to keep the (IDE) system disk from
spinning unneccessarily.

Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to
let the harddisk spin down - I found out that "kjournald" writes a few blocks every
few seconds.

As I wouldn't like to downgrade to ext2: Is there any way to keep the 2.6 kjournald
from writing to idle disks?

I cannot see a good reason why kjournald would write when there are no dirty buffers -
but still it does.

Regards,

Lutz Vieweg

BTW: I used the following script to find the source of the write operations,
just start it in one terminal, do a "sync" in another, then say "hdparm -y /dev/hda"
and you can see that immediately or a few seconds later kjournald will enter the
"D" state and wake up when the disk has spun up.

-------------------------------------------------------------------------------------
#!/usr/bin/tclsh

cd /proc

set stat_arr {
pid
comm
state
ppid
process_group,
session
tty_nr
tty_pgrp
flags
min_flt
cmin_flt
maj_flt
cmaj_flt
utime
stime
cutime
cstime
priority
nice
num_threads
it_real_value
start_time
vsize
rss
RLIMIT_RSS
start_code
end_code
start_stack
esp
eip
pending_signals
blocked_sigs
sigign
sigcatch
wchan
nswap
cnswap
exit_signal
task_cpu
rt_priorit
policy
}

proc scan_stat {_pids _dat} {
   upvar $_dat dat
   upvar $_pids pids
   global stat_arr

   set pids [lsort -integer [glob {[0-9]*}]]

   foreach pid $pids {
           set in [open "$pid/stat" "r"]
           set l [gets $in]
           close $in

           set a [split $l " "]

           foreach x $a n $stat_arr {
                   set dat($pid,$n) $x
           }
   }
}

#puts [array get dat]

array set dat {}
set pids {}

scan_stat pids dat

while {1} {
        after 1000

        array set new_dat {}
        set new_pids {}

        scan_stat new_pids new_dat

        foreach pid $new_pids {
                if {$pid != [pid]} {
                   if {![info exists dat($pid,pid)]} {
                           puts "new process $pid $new_dat($pid,comm)"
                   } else {
                           set somechange 0
                           foreach a $stat_arr {
                                   if {$new_dat($pid,$a) != $dat($pid,$a)} {
                                           puts "$pid $new_dat($pid,comm) 
                                           attribute '$a' from 
                                           $dat($pid,$a) to $new_dat($pid,$a)"
                                           set somechange 1
                                   }
                           }
                           if {$somechange} {
                                   puts ""
                           }
                   }
                }
        }

        array set dat {}
        array set dat [array get new_dat]
        set pids $new_pids
}

-------------------------------------------------------------------------------------

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

Quoted 13 lines · Lutz Vieweg

I run a server that usually doesn't have to do anything on the local filesystems, it just needs to answer some requests and perform some computations in RAM.

So I use the "hdparm -S 123" parameter setting to keep the (IDE) system disk from spinning unneccessarily.

Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to let the harddisk spin down - I found out that "kjournald" writes a few blocks every few seconds.

As I wouldn't like to downgrade to ext2: Is there any way to keep the 2.6 kjournald from writing to idle disks?

Quoted 2 lines

I cannot see a good reason why kjournald would write when there are no dirty buffers - but still it does.

Have you tried playing with the laptop-mode patch? It's already in the -mm kernel tree from Andrew Morton. I've been playing with it a little (just a few minutes) and seems keep the disks spun down for some time.

Quoted 15 lines · Felipe Alfaro Solana

Quoted 13 lines · Lutz Vieweg

I run a server that usually doesn't have to do anything on the local filesystems, it just needs to answer some requests and perform some computations in RAM.

So I use the "hdparm -S 123" parameter setting to keep the (IDE) system disk from spinning unneccessarily.

Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to let the harddisk spin down - I found out that "kjournald" writes a few blocks every few seconds.

As I wouldn't like to downgrade to ext2: Is there any way to keep the 2.6 kjournald from writing to idle disks?

Quoted 8 lines

Quoted 2 lines

I cannot see a good reason why kjournald would write when there are no dirty buffers - but still it does.

Have you tried playing with the laptop-mode patch? It's already in the -mm kernel tree from Andrew Morton. I've been playing with it a little (just a few minutes) and seems keep the disks spun down for some time.

This "laptop-mode" patch would make things far worse than they're now: Spinning up the disk about every 10min would reduce their lifetime significantly instead of extending it.

It's not a laptop, but a server with an ordinary 3.5" harddisk I'm speaking about, my goal is not saving power, but spinning down a harddisk that does not need to spin up the whole day long.

What I'm questioning is whether there's a need to write to idle disks at all - does anybody know why kjournald writes data even if there is nothing to commit at all?

It's not a laptop, but a server with an ordinary 3.5" harddisk I'm speaking about, my goal is not saving power, but spinning down a harddisk that does not need to spin up the whole day long.

What I'm questioning is whether there's a need to write to idle disks at all - does anybody know why kjournald writes data even if there is nothing to commit at all?

In article <[email protected]>, Micha Feigin <[email protected]> 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.

Quoted 17 lines · bill davidsen

In article <[email protected]>, Micha Feigin <[email protected]> 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.

Quoted 2 lines

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.

Well, it's the o.p. system, not mine, but I don't see how noatime will help him, the atime shouldn't change unless he's doing disk access, and if he's doing disk access the disk will spin up anyway.

The place noatime helps is when actually doing reads to open files, and getting an inode update free with every read. His problem is that something really is accessing the drive, and he won't get the desired spindown until that's addressed.

I hope the original poster is following this ;-)

Quoted 3 lines

Well, it's the o.p. system, not mine, but I don't see how noatime will help him, the atime shouldn't change unless he's doing disk access, and if he's doing disk access the disk will spin up anyway.

If something really is accessing the drive, noatime might still help as long as the accesses are from the cache.

Quoted 3 lines · Bart Samwel

Quoted 3 lines

Well, it's the o.p. system, not mine, but I don't see how noatime will help him, the atime shouldn't change unless he's doing disk access, and if he's doing disk access the disk will spin up anyway.

That's what I thought, too... and I really killed everything that I could imagine accessing the disk... but...

Quoted 2 lines

If something really is accessing the drive, noatime might still help as long as the accesses are from the cache.

... that really helped! I'm kind of surprised, since I didn't use noatime before the update, and I still don't know of any process that might do the reading, but since mounting / with noatime helped, I'm happy for now.

My curiosity isn't completely gone, though, so maybe one day I'll try to find out who-is-trying-to-read-what, "find -atime ..." didn't reveal the secret
yet.

Regards,

Lutz Vieweg

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

Quoted 3 lines

My curiosity isn't completely gone, though, so maybe one day I'll try to find out who-is-trying-to-read-what, "find -atime ..." didn't reveal the secret yet.

It might help you find the culprit. There is a laptopmode patch for 2.6. If you echo a number n larger then 1 into /proc/sys/vm/laptopmode it will dump the first n disk accesses to the console (The docs that come with the patch have the complete description).