Skip to contentSkip to conversation

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

DISCUSSION Xuan Baldauf 5 participants 13 messages Jul 31, 2000 2 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 13 lines · Xuan Baldauf
Quoted 11 lines · Russell King
Quoted 5 lines · Xuan Baldauf

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.

Quoted 8 lines
Quoted 4 lines

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#3 lore raw
Quoted 5 lines · Xuan Baldauf

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#4 lore raw
Quoted 9 lines · Andre Hedrick
Quoted 5 lines · Xuan Baldauf

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".)

Quoted 4 lines

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#5 lore raw
Quoted 7 lines · Xuan Baldauf
Quoted 3 lines
Quoted 1 line

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.

Signature · 6 lines
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#6 lore raw
Quoted 6 lines · Matthias Andree
Quoted 4 lines · Xuan Baldauf
Quoted 3 lines
Quoted 1 line

does not necessarily spin up the disk!

Because you have to issue a drive reset.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 3 lines

--
Matthias Andree

Xuân.:o)

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

#7 lore raw
Quoted 6 lines · Xuan Baldauf

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.

Signature · 6 lines
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#8 lore raw
Quoted 8 lines · Matthias Andree
Quoted 6 lines · Xuan Baldauf

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.

Quoted 6 lines

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#9 lore raw
Quoted 4 lines

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.

Signature · 6 lines
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#10 lore raw
In reply to Xuan Baldauf

Xuan Baldauf writes:
...

Quoted 4 lines

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#11 lore raw
In reply to Matthias Andree
Quoted 3 lines · Matthias Andree

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)).

Signature · 12 lines
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [email protected] |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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#12 lore raw
Quoted 8 lines · Marc Lehmann
Quoted 3 lines · Matthias Andree

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.

Quoted 3 lines

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.

Quoted 3 lines

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 :-)

Signature · 6 lines
Matthias Andree

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#13 lore raw
Quoted 5 lines · Matthias Andree
Quoted 2 lines

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.

Quoted 2 lines

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 ;)

Signature · 12 lines
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [email protected] |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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#14 lore raw
In reply to Xuan Baldauf
Quoted 2 lines · Xuan Baldauf

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.

Signature · 6 lines
Matthias Andree

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