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
}
-------------------------------------------------------------------------------------
On Jan 25, 2004 19:29 +0100, Lutz Vieweg wrote:
> 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.
Loop for laptop-mode patches, which should allow you to do this.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Sun, 25 Jan 2004, Lutz Vieweg wrote:
> 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.
I can spin down my "extra" hard drives just fine with 2.6; I have a
"hde" drive (IBM DTLA, a wonder it's still alive, it's just a cache disk
however, no valuable data on it) attached to a Promise PDC 20265R which
has one large ext3fs partition, /dev/hde1, across the whole disk, which
will sit idle for ages, without spinning up. I have another IDE harddisk
with just reiserfs and vfat, it stays in standby as well. The third IDE
harddisk is so quiet I can't tell, without asking hdparm -C, whether it
is up, and I do not really care, but it seems it stays in standby as
well.
So the question is, do you run stuff that marks blocks dirty regularly?
atime updates? Does mounting ALL the partition (including root) with
option "noatime" help, policy and applications permitting?
Another thing I find very annoying however: whenever a disk writes the
last dirty block and is in a known-good shape, it should mark its state
as "clean" so it doesn't need to be spun up just to change the
superblock from "not clean" to "clean" when the computer is shut down
and the FS is umounted. The first action when touching the disk would
then mark the fs "not clean" until after the last fs was marked "clean".
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
On Sun, 2004-01-25 at 19:29, Lutz Vieweg wrote:
> 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.
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.
However, I haven't been able to get it suit my needs, since I use apps
like Evolution which are continuously writting to the disk.
If you are willing to play with it, I recommend you downloading the
latest -mm patch from http://www.kernel.org, untar the sources and then
read Documentation/laptop-mode.txt.
On Sun, Jan 25, 2004 at 07:29:30PM +0100, Lutz Vieweg wrote:
> 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.
>
There are two things to do. First you should mount the disk with the
noatime 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.
>
> 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/
>
Felipe Alfaro Solana wrote:
> On Sun, 2004-01-25 at 19:29, Lutz Vieweg wrote:
>
>>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.
>
>
> 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?
Regards,
Lutz Vieweg
Lutz Vieweg wrote:
> 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?
Hmmm. My 2nd HD (that I almost never use) is set to hdparm -S 4 (20
seconds), it has an ext3 filesystem on it, and it spins down some 20
seconds after mounting and never spins up again. I haven't had to set
any options to make this possible. Is it possible that there may still
be something that is dirtying blocks on that disk? (If you want to check
this out, laptop_mode has a /proc/sys/vm/block_dump setting that makes
the kernel log all reads, writes and block dirtyings.)
-- Bart
Lutz Vieweg wrote:
> Felipe Alfaro Solana wrote:
>
>> On Sun, 2004-01-25 at 19:29, Lutz Vieweg wrote:
>>
>>> 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.
>>
>>
>>
>> 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?
Because you aren't using the noatime option?
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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
bill davidsen wrote:
> 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.
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
On Tue, 27 Jan 2004, Bart Samwel wrote:
> bill davidsen wrote:
> > 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.
>
> 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.
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.
> 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.
I hope the original poster is following this ;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill Davidsen wrote:
> 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.
If something really is accessing the drive, noatime might still help as
long as the accesses are from the cache. BTW, it wasn't clear to me from
his posts that he knows that something is _really_ accessing the drive,
I thought he only had kjournald activity -- and that might be explained
by atime updates. But I might have missed something of course!
> I hope the original poster is following this ;-)
I added him to the CC list again. That should fix it. :)
-- Bart
Bart Samwel wrote:
>> 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...
> 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
On Wed, Jan 28, 2004 at 02:30:52PM +0100, Lutz Vieweg wrote:
> Bart Samwel wrote:
>
> >>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...
>
> >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.
>
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).
> 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/
>
Micha Feigin wrote:
>>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).
This was true in the first version (for /proc/sys/vm/block_dump, not
laptop_mode), however, this approach was then shot down in favor of a
simple on/off flag.
--Bart