Re: (reiserfs) Re: sync: why disk cannot spin down

Re: (reiserfs) Re: sync: why disk cannot spin down

[Xuan Baldauf]

Xuan Baldauf wrote:

> Russell King wrote:
>
> > Xuan Baldauf writes:
> > > this problem is possibly unrelated to reiserfs but related to
> > > linux-kernel, but now I can prove it: regular sync()s do prevent the
> > > spindown of (IDE) disks. There will be a call to sync() after 32 or less
> > > seconds have elapsed since the last sync(). Not a problem itself, but
> > > every sync spins up the disk again.
> >
> > You may want to have a look at the atime/diratime mount options, or
> > even chattr -A to prevent certain files causing a write when they're
> > run/read.
> >
> > Note that just executing "sync" causes its atime to be marked for update,
> > which will cause a write back to disk a short while later.
> >
> > [...]
>
> Thank you for waking me! :o) I forgot the atime issue. I wonder why it still
> is the default...
>

Now I made all my partitions noatime, and wow,

sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda

does not necessarily spin up the disk!

Someone suggested noflushd (does anybody have pointers?), because every write
would trigger spin up, but that is okay for me, I'd like to have a system where
no writes are done else when needed. About a minute (some more or less seconds)
after spindown, the disk spins up again, but now I cannot find out the cause.

I tried to strace the whole system with

strace `ps x|grep -v PID|grep -v $PPID|awk {' print "-" "p " $1 '}`

but this was not very clueful, because if some process writes, the buffers are
only changed in memory. Then the disk spins down (spindown time set to 20
seconds). After some time, the disk spins up again, because kupdate sends the
buffers to disk. Unfortunately, this way I cannot find (time-)relations between
writes or write-like functions (like munmap) and disk access.

Is there a simple switch or a patch out there which makes every buffer (head)
release synchronous (yet not discarding the buffer, it is still needed so all
daemons can fully run in RAM).

Xuân.:o)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Andre Hedrick]

On Mon, 31 Jul 2000, Xuan Baldauf wrote:

> Now I made all my partitions noatime, and wow,
> 
> sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda
> 
> does not necessarily spin up the disk!

Because you have to issue a drive reset.

Andre Hedrick
The Linux ATA/IDE guy


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Xuan Baldauf]

Andre Hedrick wrote:

> On Mon, 31 Jul 2000, Xuan Baldauf wrote:
>
> > Now I made all my partitions noatime, and wow,
> >
> > sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda
> >
> > does not necessarily spin up the disk!
>
> Because you have to issue a drive reset.

This is my intent, not to spin up the disk. (In my previous case, sync
always spun up the disk because the filesystem was not mounted with
"noatime".)

>
>
> Andre Hedrick
> The Linux ATA/IDE guy

Xuân.:o)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Matthias Andree]

On Mon, 31 Jul 2000, Xuan Baldauf wrote:

> > > does not necessarily spin up the disk!
> >
> > Because you have to issue a drive reset.
> 
> This is my intent, not to spin up the disk. (In my previous case, sync
> always spun up the disk because the filesystem was not mounted with
> "noatime".)

This will still not work, since after some time, the kernel starts
missing the drive acknowledgements and eventually issues a reset
condition on that IDE channel. See my other mail for details.

-- 
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Xuan Baldauf]

Matthias Andree wrote:

> On Mon, 31 Jul 2000, Xuan Baldauf wrote:
>
> > > > does not necessarily spin up the disk!
> > >
> > > Because you have to issue a drive reset.
> >
> > This is my intent, not to spin up the disk. (In my previous case, sync
> > always spun up the disk because the filesystem was not mounted with
> > "noatime".)
>
> This will still not work, since after some time, the kernel starts
> missing the drive acknowledgements and eventually issues a reset
> condition on that IDE channel. See my other mail for details.

You tell me the kernel starts missing drive ACKs even if there are no read
or write requests pending? Even then, the drive was never in sleep mode
(requires reset), it always was in standby mode (does not require reset). My
primary intent is to reduce the noise of the drive, not the power
consumption.

>
> --
> Matthias Andree

Xuân.:o)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Matthias Andree]

On Mon, 31 Jul 2000, Xuan Baldauf wrote:
> Matthias Andree wrote:
> You tell me the kernel starts missing drive ACKs even if there are no read
> or write requests pending? Even then, the drive was never in sleep mode
> (requires reset), it always was in standby mode (does not require reset). My
> primary intent is to reduce the noise of the drive, not the power
> consumption.

Of course, if the kernel is not writing, it's not missing "operation
complete" transactions.

My point is: putting a drive to sleep rather than to standby will not
help much, it will only delay the spin-up and possibly leave you with a
slower drive.

-- 
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Xuan Baldauf]

Matthias Andree wrote:

> On Mon, 31 Jul 2000, Xuan Baldauf wrote:
> > Matthias Andree wrote:
> > You tell me the kernel starts missing drive ACKs even if there are no read
> > or write requests pending? Even then, the drive was never in sleep mode
> > (requires reset), it always was in standby mode (does not require reset). My
> > primary intent is to reduce the noise of the drive, not the power
> > consumption.
>
> Of course, if the kernel is not writing, it's not missing "operation
> complete" transactions.
>
> My point is: putting a drive to sleep rather than to standby will not
> help much, it will only delay the spin-up and possibly leave you with a
> slower drive.

But I never wanted it to be in sleep (rather than standby) mode, my original
intent was to bring the system to a state where spin ups are only done when
necessary. Someone said something about noflushd, but I could not find any links
or rpm packages, does anybody have...?

Maybe the off-topic discussion is going to be off-topic of the off-topic... ;o)

Xuân.:o)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Matthias Andree]

> But I never wanted it to be in sleep (rather than standby) mode, my
> original intent was to bring the system to a state where spin ups are
> only done when necessary. Someone said something about noflushd, but I
> could not find any links or rpm packages, does anybody have...?

yup. Freshmeat has:

http://freshmeat.net/appindex/1999/09/04/936483800.html

which links to the home page:

http://www.tuebingen.linux.de/~s-kod1/noflushd/

Note you cannot currently build the RPM as user since it has install -o
root somewhere in its Makefile. If you dare, rpm --rebuild as root,
else, fix the Makefile or wait for the update. I have contacted Daniel
Kobras about this (noflushd maintainer) and he agreed to use %defattr in
the RPM .spec in the next release rather than using -o/-g root on
$(INSTALL). Daniel is not an RPM expert, he's using Debian.

Also note I'm Bcc:'ing Daniel. It's not really blind cc: this way, but
this prevents him from being drawn into a possible continued discussion.
I see many people with improperly configured mailers or mailers without
mailing list support that have this tendency (of drawing people in).

Let's please take this off the list. I'm setting Reply-To:, but I'm not
sure if it makes it through the list software.

-- 
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Billy Harvey]

Xuan Baldauf writes:
...
 > But I never wanted it to be in sleep (rather than standby) mode, my original
 > intent was to bring the system to a state where spin ups are only done when
 > necessary. Someone said something about noflushd, but I could not find any links
 > or rpm packages, does anybody have...?

http://www.tuebingen.linux.de/~s-kod1/noflushd/testing/ .  I'm testing
the latest version right now on my Toshiba notebook, and it seems to
work fine.

Billy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Marc Lehmann]

On Mon, Jul 31, 2000 at 04:53:00PM +0200, Matthias Andree <matthias.andree@gmx.de> wrote:
> My point is: putting a drive to sleep rather than to standby will not
> help much, it will only delay the spin-up and possibly leave you with a
> slower drive.

Cool logic. How do you define "much"? Drive electronics can still use
a lot of power, and most users (xuan and me excluded ;) want this for
power-save.

In practise, of course, there is a clear trade-off between ugly error (!)
messages from the kernel drawing for your attention and not putting the
drive to sleep.

In general, the kernel support is lacking much with respect to
power-savings (just spin down your scsi-drive to get some nice hang (and
yes, I know the scsi-idle patch)).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Matthias Andree]

On Mon, 31 Jul 2000, Marc Lehmann wrote:

> On Mon, Jul 31, 2000 at 04:53:00PM +0200, Matthias Andree <matthias.andree@gmx.de> wrote:
> > My point is: putting a drive to sleep rather than to standby will not
> > help much, it will only delay the spin-up and possibly leave you with a
> > slower drive.
> 
> Cool logic. How do you define "much"? Drive electronics can still use
> a lot of power, and most users (xuan and me excluded ;) want this for
> power-save.

How much you get, depends on how much the actual drive saves. Still, you
lose performance, you possibly lose the settings, that's on the negative
side. I'm aware of these implications, a good friend of mine has written
his diploma thesis in electrical engineering on exactly this topic,
namely "Algorithmen für den leistungsarmen Betrieb mobiler Festplatten"
(German-language, translates to 'algorithms for the low-power operation of
mobile hard disk drives'). Contact me in private mail if you need
more information. 

He collected some information from manufacturers that I'm working up
here: (quoting from 

manuf.+model  IBM DARA Hitachi    Fujitsu  Seagate Ma-  Maxtor
cont'd        225000   DK22AA     2064AT   rathon 2250  251010A 

power (W)
active          2.6    2.22        2.15    2.50         1.83
idle    2.0/1.3/0.85   1.7/0.8     0.95    1.20         0.90
standby         0.25   0.25        0.35    0.30         0.20
sleep           0.1    0.125       0.13    0.10         0.10

So, effectively, you gain about 100..200 mW by putting a drive from
standby to sleep, while you gain roughly 1000 mW from idle to standby
after gaining 0.5 .. 1.5 W from active to idle. (depends on the usage
pattern). OTOH, if you're talking about power, the more interesting
thing is the energy (integral t0...t1 P(t) dt), and waking up
electronics and spinning up the drive costs additional energy, even if
it's only for the delay until the request is satisfied. If waking up
from sleep costs additional seconds, that's going to cost battery life,
to put it popularly.

> In practise, of course, there is a clear trade-off between ugly error (!)
> messages from the kernel drawing for your attention and not putting the
> drive to sleep.

The error message is natural, a drive put to sleep is put there
permanently, since the drive is supposed to power down its interface
electronics as well. 

> In general, the kernel support is lacking much with respect to
> power-savings (just spin down your scsi-drive to get some nice hang (and
> yes, I know the scsi-idle patch)).

Since SCSI drives are only manually powered down, the Kernel is fine in
this respect, although it leaves room for feature requests, admittedly
:-)

-- 
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Marc Lehmann]

On Mon, Jul 31, 2000 at 06:40:48PM +0200, Matthias Andree <matthias.andree@gmx.de> wrote:
> > messages from the kernel drawing for your attention and not putting the
> > drive to sleep.
> 
> The error message is natural, a drive put to sleep is put there
> permanently, since the drive is supposed to power down its interface

It still isn't an error, though, and linux could, if it were
better-than-neccessary, take this into account.

Linux doesn't bitch on spinned-down scsi disks at boot either, but
properly starts them.

> Since SCSI drives are only manually powered down, the Kernel is fine in
> this respect

"Fine" = "lacks any support". So just for me, that isn't fine. But it's
bearable ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: sync: why disk cannot spin down

[Matthias Andree]

On Mon, 31 Jul 2000, Xuan Baldauf wrote:

> Xuan Baldauf wrote:
> sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda

Note that "sleep" mode is quite different from "standby" mode. Drives
spin up from standby mode by themselves, they are NOT supposed to wake
up from sleep mode, unless you issue a reset.

Sleep mode is meant to put the drive to sleep, possibly switching the
laptop off or something.

We happen to be so lucky that the Linux kernel issues a reset if it is
fed up with IDE timeouts, which will bring the drive back online, at the
expense of voiding all settings in that IDE channel, particularly, DMA
modes, PIO modes and the like, unless you use the "keep options over
reset flag".  (which means soft reset, effectively).

Admittedly, drives should use less power in sleep mode, the price is
higher latency and, as said before, possibly loss of drive
configuration.

-- 
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/