Jan Engelhardt wrote:
> I am using 2.6.23-rc9 with pata_sis. `modprobe -r sd_mod`, which I ran
> from initramfs, caused all my disks to spindown - sd even told me so.
>
> I recall there has been talk a while back about whether to spin down
> disks on shutdown or not, but
Jan Engelhardt wrote:
I am using 2.6.23-rc9 with pata_sis. `modprobe -r sd_mod`, which I ran
from initramfs, caused all my disks to spindown - sd even told me so.
I recall there has been talk a while back about whether to spin down
disks on shutdown or not, but I do not think it touched
Hi, I use 2.6.22.9 with CFS-v22.
When I shutdown my laptop I see a error (last message on shutdown, after
"will be halt now"), but I can't read because is very fast (laptop
power-off automatically).
I see something about "Spindown error on ata-piix".
I try found on /var
Hi, I use 2.6.22.9 with CFS-v22.
When I shutdown my laptop I see a error (last message on shutdown, after
will be halt now), but I can't read because is very fast (laptop
power-off automatically).
I see something about Spindown error on ata-piix.
I try found on /var/log (messages, kern
Hi,
I am using 2.6.23-rc9 with pata_sis. `modprobe -r sd_mod`, which I ran
from initramfs, caused all my disks to spindown - sd even told me so.
I recall there has been talk a while back about whether to spin down
disks on shutdown or not, but I do not think it touched the removal of
sd_mod
Hi,
I am using 2.6.23-rc9 with pata_sis. `modprobe -r sd_mod`, which I ran
from initramfs, caused all my disks to spindown - sd even told me so.
I recall there has been talk a while back about whether to spin down
disks on shutdown or not, but I do not think it touched the removal of
sd_mod
On Thu, Jun 14, 2007 at 01:48:46PM -0400, Daniel Drake wrote:
> Greg KH wrote:
> > I think it looks way too big.
>
> Agreed (otherwise I would have submitted the patches already).
>
> > If there are smaller patches, it might be a bit more reasonable.
>
> It may be possible to get rid of the
Greg KH wrote:
I think it looks way too big.
Agreed (otherwise I would have submitted the patches already).
If there are smaller patches, it might be a bit more reasonable.
It may be possible to get rid of the couple of unrelated ones (sd
printing, SCSI constants). These were required for
On Thu, 14 Jun 2007, Greg KH wrote:
> Are there reported bugs that this patchset fixes?
Yes, at least one I opened and which got a CODE_FIX when Tejun prepared the
first version of the patch.
http://bugzilla.kernel.org/show_bug.cgi?id=7838
--
"One disk to rule them all, One disk to find
On Thu, Jun 14, 2007 at 12:01:14PM -0400, Chuck Ebbert wrote:
> Should we put these patches in 2.6.21-stable?
>
> Gentoo developers did a full backport:
>
> http://marc.info/?l=linux-ide=118047865916766=2
I think it looks way too big.
If there are smaller patches, it might be a bit more
Should we put these patches in 2.6.21-stable?
Gentoo developers did a full backport:
http://marc.info/?l=linux-ide=118047865916766=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Should we put these patches in 2.6.21-stable?
Gentoo developers did a full backport:
http://marc.info/?l=linux-idem=118047865916766w=2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
added Daniel to CC:
On Thu, Jun 14, 2007 at 12:01:14PM -0400, Chuck Ebbert wrote:
Should we put these patches in 2.6.21-stable?
Gentoo developers did a full backport:
http://marc.info/?l=linux-idem=118047865916766w=2
I think it looks way too big.
If there are smaller patches, it might be
On Thu, 14 Jun 2007, Greg KH wrote:
Are there reported bugs that this patchset fixes?
Yes, at least one I opened and which got a CODE_FIX when Tejun prepared the
first version of the patch.
http://bugzilla.kernel.org/show_bug.cgi?id=7838
--
One disk to rule them all, One disk to find them.
Greg KH wrote:
I think it looks way too big.
Agreed (otherwise I would have submitted the patches already).
If there are smaller patches, it might be a bit more reasonable.
It may be possible to get rid of the couple of unrelated ones (sd
printing, SCSI constants). These were required for
On Thu, Jun 14, 2007 at 01:48:46PM -0400, Daniel Drake wrote:
Greg KH wrote:
I think it looks way too big.
Agreed (otherwise I would have submitted the patches already).
If there are smaller patches, it might be a bit more reasonable.
It may be possible to get rid of the couple of
On Fri, 01 Jun 2007, Jeff Garzik wrote:
> IIRC, Debian was the one OS that really did need a shutdown utility
> update, as the message says :)
Actually, editing /etc/init.d/halt is enough. Find the hddown="-h" and
change it to hddown="".
--
"One disk to rule them all, One disk to find them.
On 6/1/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Tuncer Ayaz wrote:
> I'm still seeing the libata warning that disks were not spun down
> properly on the following two setups and am wondering whether I need
> a new shutdown binary or the changeset mentioned below is not meant
> to fix what I'm
Tuncer Ayaz wrote:
I'm still seeing the libata warning that disks were not spun down
properly on the following two setups and am wondering whether I need
a new shutdown binary or the changeset mentioned below is not meant
to fix what I'm triggering by halt'ing.
If it's not a bug I will try to
I'm still seeing the libata warning that disks were not spun down
properly on the following two setups and am wondering whether I need
a new shutdown binary or the changeset mentioned below is not meant
to fix what I'm triggering by halt'ing.
If it's not a bug I will try to update my shutdown
I'm still seeing the libata warning that disks were not spun down
properly on the following two setups and am wondering whether I need
a new shutdown binary or the changeset mentioned below is not meant
to fix what I'm triggering by halt'ing.
If it's not a bug I will try to update my shutdown
Tuncer Ayaz wrote:
I'm still seeing the libata warning that disks were not spun down
properly on the following two setups and am wondering whether I need
a new shutdown binary or the changeset mentioned below is not meant
to fix what I'm triggering by halt'ing.
If it's not a bug I will try to
On 6/1/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Tuncer Ayaz wrote:
I'm still seeing the libata warning that disks were not spun down
properly on the following two setups and am wondering whether I need
a new shutdown binary or the changeset mentioned below is not meant
to fix what I'm
On Fri, 01 Jun 2007, Jeff Garzik wrote:
IIRC, Debian was the one OS that really did need a shutdown utility
update, as the message says :)
Actually, editing /etc/init.d/halt is enough. Find the hddown=-h and
change it to hddown=.
--
One disk to rule them all, One disk to find them. One
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote:
> Pavel Machek wrote:
> > > Isn't this why noflushd exists or is this an evil thing that shouldn't
> > > ever be used and will eventually eat my disks for breakfast?
> >
> > It would eat your flash for breakfast. You know, flash
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote:
Pavel Machek wrote:
Isn't this why noflushd exists or is this an evil thing that shouldn't
ever be used and will eventually eat my disks for breakfast?
It would eat your flash for breakfast. You know, flash memories have
Hi!
> > You know about this project no doubt:
> >
> >http://noflushd.sourceforge.net/
>
> Only vaguely. It's huge. Over 2300 lines of C code and >560 lines in
> .h files! As you say, not really lightweight. There must be a better
> way. Also, I suspect (without having looked at the code)
Hi!
> > > > I'd like that too, but what about sync writes? As things stand now,
> > > > there is no option but to spin the disk back up. To get around this
> > > > we'd have to change the basic behavior of the block device and
> > > > that's doable, but it's an entirely different proposition
Hi!
You know about this project no doubt:
http://noflushd.sourceforge.net/
Only vaguely. It's huge. Over 2300 lines of C code and 560 lines in
.h files! As you say, not really lightweight. There must be a better
way. Also, I suspect (without having looked at the code) that it
Hi!
I'd like that too, but what about sync writes? As things stand now,
there is no option but to spin the disk back up. To get around this
we'd have to change the basic behavior of the block device and
that's doable, but it's an entirely different proposition than the
at of large files being written out.
But that's not the only advantage of doing the early update:
- Early spindown for laptops
- Improved latency under some conditions
- Improved throughput for some loads
- Improved filesystem safety
> It should be easy enough to just trigger writeout o
On Sun, 24 Jun 2001, Anuradha Ratnaweera wrote:
> It is not uncommon to have a large number of tmp files on the disk(s)
> (Rik also pointed this out somewhere early in the original thread) and
> it is sensible to keep all of them in buffers if RAM is sufficient.
> Transfering _very_ large files
On Sunday 24 June 2001 05:20, Anuradha Ratnaweera wrote:
> On Wed, Jun 20, 2001 at 04:58:51PM -0400, Tom Sightler wrote:
> > 1. When running a compile, or anything else that produces lots of small
> > disk writes, you tend to get lots of little pauses for all the little
> > writes to disk. These
On Sunday 24 June 2001 05:20, Anuradha Ratnaweera wrote:
On Wed, Jun 20, 2001 at 04:58:51PM -0400, Tom Sightler wrote:
1. When running a compile, or anything else that produces lots of small
disk writes, you tend to get lots of little pauses for all the little
writes to disk. These seem
On Sun, 24 Jun 2001, Anuradha Ratnaweera wrote:
It is not uncommon to have a large number of tmp files on the disk(s)
(Rik also pointed this out somewhere early in the original thread) and
it is sensible to keep all of them in buffers if RAM is sufficient.
Transfering _very_ large files is
of doing the early update:
- Early spindown for laptops
- Improved latency under some conditions
- Improved throughput for some loads
- Improved filesystem safety
It should be easy enough to just trigger writeout of
pages of an inode once that inode has more than a
certain amount of dirty
On Wed, Jun 20, 2001 at 04:58:51PM -0400, Tom Sightler wrote:
>
> 1. When running a compile, or anything else that produces lots of small disk
> writes, you tend to get lots of little pauses for all the little writes to disk.
> These seem to be unnoticable without the patch.
>
> 2. Loading
On Wed, Jun 20, 2001 at 04:58:51PM -0400, Tom Sightler wrote:
1. When running a compile, or anything else that produces lots of small disk
writes, you tend to get lots of little pauses for all the little writes to disk.
These seem to be unnoticable without the patch.
2. Loading
On Saturday 23 June 2001 01:25, Daniel Kobras wrote:
> On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
> > Daniel Phillips writes:
> > > I'd like that too, but what about sync writes? As things stand now,
> > > there is no option but to spin the disk back up. To get around this
>
On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
> Daniel Phillips writes:
> > I'd like that too, but what about sync writes? As things stand now,
> > there is no option but to spin the disk back up. To get around this
> > we'd have to change the basic behavior of the block device
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote:
> Pavel Machek wrote:
> > > Isn't this why noflushd exists or is this an evil thing that shouldn't
> > > ever be used and will eventually eat my disks for breakfast?
> >
> > It would eat your flash for breakfast. You know, flash
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote:
Pavel Machek wrote:
Isn't this why noflushd exists or is this an evil thing that shouldn't
ever be used and will eventually eat my disks for breakfast?
It would eat your flash for breakfast. You know, flash memories have
On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
Daniel Phillips writes:
I'd like that too, but what about sync writes? As things stand now,
there is no option but to spin the disk back up. To get around this
we'd have to change the basic behavior of the block device and
On Saturday 23 June 2001 01:25, Daniel Kobras wrote:
On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
Daniel Phillips writes:
I'd like that too, but what about sync writes? As things stand now,
there is no option but to spin the disk back up. To get around this
we'd
Pavel Machek wrote:
> > Isn't this why noflushd exists or is this an evil thing that shouldn't
> > ever be used and will eventually eat my disks for breakfast?
>
> It would eat your flash for breakfast. You know, flash memories have
> no spinning parts, so there's nothing to spin down.
Btw
Pavel Machek wrote:
Isn't this why noflushd exists or is this an evil thing that shouldn't
ever be used and will eventually eat my disks for breakfast?
It would eat your flash for breakfast. You know, flash memories have
no spinning parts, so there's nothing to spin down.
Btw Pavel, does
On Wednesday 20 June 2001 22:58, Tom Sightler wrote:
> Quoting Daniel Phillips <[EMAIL PROTECTED]>:
> > I originally intended to implement a sliding flush delay based on disk
> > load.
> > This turned out to be a lot of work for a hard-to-discern benefit. So
> > the
> > current approach has just
Quoting Daniel Phillips <[EMAIL PROTECTED]>:
> I originally intended to implement a sliding flush delay based on disk
> load.
> This turned out to be a lot of work for a hard-to-discern benefit. So
> the
> current approach has just two delays: .1 second and whatever the bdflush
>
> delay is
On Wednesday 20 June 2001 19:32, Rik van Riel wrote:
> On Wed, 20 Jun 2001, Daniel Phillips wrote:
> > BTW, with nominal 100,000 erases you have to write 10 terabytes
> > to your 100 meg flash disk before you'll see it start to
> > degrade.
>
> That assumes you write out full blocks. If you
On Wed, 20 Jun 2001, Daniel Phillips wrote:
> BTW, with nominal 100,000 erases you have to write 10 terabytes
> to your 100 meg flash disk before you'll see it start to
> degrade.
That assumes you write out full blocks. If you flush after
every byte written you'll hit the limit a lot sooner ;)
On Tuesday 19 June 2001 12:46, Pavel Machek wrote:
> > > > Roger> It does if you are running on a laptop. Then you do not want
> > > > Roger> the pages go out all the time. Disk has gone too sleep, needs
> > > > Roger> to start to write a few pages, stays idle for a while, goes to
> > > > Roger>
Daniel Phillips writes:
> On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
> > Starting I/O immediately if there is no load sounds nice. However,
> > what about the other case, when the disc is already spun down (and
> > hence there's no I/O load either)? I want the system to avoid doing
> >
On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
> Daniel Phillips writes:
> > I never realized how much I didn't like the good old 5 second delay
> > between saving an edit and actually getting it written to disk until
> > it went away. Now the question is, did I lose any performance in
>
Hi!
> > > Roger> It does if you are running on a laptop. Then you do not want
> > > Roger> the pages go out all the time. Disk has gone too sleep, needs
> > > Roger> to start to write a few pages, stays idle for a while, goes to
> > > Roger> sleep, a few more pages, ...
> > > That could be
Hi!
Roger It does if you are running on a laptop. Then you do not want
Roger the pages go out all the time. Disk has gone too sleep, needs
Roger to start to write a few pages, stays idle for a while, goes to
Roger sleep, a few more pages, ...
That could be handled by a metric
On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
Daniel Phillips writes:
I never realized how much I didn't like the good old 5 second delay
between saving an edit and actually getting it written to disk until
it went away. Now the question is, did I lose any performance in
doing
Daniel Phillips writes:
On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
Starting I/O immediately if there is no load sounds nice. However,
what about the other case, when the disc is already spun down (and
hence there's no I/O load either)? I want the system to avoid doing
writes
On Tuesday 19 June 2001 12:46, Pavel Machek wrote:
Roger It does if you are running on a laptop. Then you do not want
Roger the pages go out all the time. Disk has gone too sleep, needs
Roger to start to write a few pages, stays idle for a while, goes to
Roger sleep, a few more
On Wed, 20 Jun 2001, Daniel Phillips wrote:
BTW, with nominal 100,000 erases you have to write 10 terabytes
to your 100 meg flash disk before you'll see it start to
degrade.
That assumes you write out full blocks. If you flush after
every byte written you'll hit the limit a lot sooner ;)
On Wednesday 20 June 2001 19:32, Rik van Riel wrote:
On Wed, 20 Jun 2001, Daniel Phillips wrote:
BTW, with nominal 100,000 erases you have to write 10 terabytes
to your 100 meg flash disk before you'll see it start to
degrade.
That assumes you write out full blocks. If you flush after
Quoting Daniel Phillips [EMAIL PROTECTED]:
I originally intended to implement a sliding flush delay based on disk
load.
This turned out to be a lot of work for a hard-to-discern benefit. So
the
current approach has just two delays: .1 second and whatever the bdflush
delay is set to.
On Wednesday 20 June 2001 22:58, Tom Sightler wrote:
Quoting Daniel Phillips [EMAIL PROTECTED]:
I originally intended to implement a sliding flush delay based on disk
load.
This turned out to be a lot of work for a hard-to-discern benefit. So
the
current approach has just two delays:
Daniel Phillips writes:
> I never realized how much I didn't like the good old 5 second delay
> between saving an edit and actually getting it written to disk until
> it went away. Now the question is, did I lose any performance in
> doing that. What I wrote in the previous email turned out to
I never realized how much I didn't like the good old 5 second delay between
saving an edit and actually getting it written to disk until it went away.
Now the question is, did I lose any performance in doing that. What I wrote
in the previous email turned out to be pretty accurate, so I'll
On Fri, Jun 15, 2001 at 03:23:07PM +, Pavel Machek wrote:
> > Roger> It does if you are running on a laptop. Then you do not want
> > Roger> the pages go out all the time. Disk has gone too sleep, needs
> > Roger> to start to write a few pages, stays idle for a while, goes to
> > Roger>
On Fri, Jun 15, 2001 at 03:23:07PM +, Pavel Machek wrote:
Roger It does if you are running on a laptop. Then you do not want
Roger the pages go out all the time. Disk has gone too sleep, needs
Roger to start to write a few pages, stays idle for a while, goes to
Roger sleep, a few more
I never realized how much I didn't like the good old 5 second delay between
saving an edit and actually getting it written to disk until it went away.
Now the question is, did I lose any performance in doing that. What I wrote
in the previous email turned out to be pretty accurate, so I'll
Daniel Phillips writes:
I never realized how much I didn't like the good old 5 second delay
between saving an edit and actually getting it written to disk until
it went away. Now the question is, did I lose any performance in
doing that. What I wrote in the previous email turned out to be
On Mon, 18 Jun 2001, Daniel Phillips wrote:
> On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
> > It _juuust_ so happens that I was tinkering... what do you think of
> > something like the below? (and boy do I ever wonder what a certain
> > box doing slrn stuff thinks of it.. hint hint;)
>
On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
> It _juuust_ so happens that I was tinkering... what do you think of
> something like the below? (and boy do I ever wonder what a certain
> box doing slrn stuff thinks of it.. hint hint;)
It's too subtle for me ;-) (Not shy about sying that
On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
It _juuust_ so happens that I was tinkering... what do you think of
something like the below? (and boy do I ever wonder what a certain
box doing slrn stuff thinks of it.. hint hint;)
It's too subtle for me ;-) (Not shy about sying that
On Mon, 18 Jun 2001, Daniel Phillips wrote:
On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
It _juuust_ so happens that I was tinkering... what do you think of
something like the below? (and boy do I ever wonder what a certain
box doing slrn stuff thinks of it.. hint hint;)
It's
On Sun, 17 Jun 2001 [EMAIL PROTECTED] wrote:
> On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
> >
> > It _juuust_ so happens that I was tinkering... what do you think of
> > something like the below? (and boy do I ever wonder what a certain
> > box doing slrn stuff thinks of
On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
>
> It _juuust_ so happens that I was tinkering... what do you think of
> something like the below? (and boy do I ever wonder what a certain
> box doing slrn stuff thinks of it.. hint hint;)
>
I'm sorry to say this box doesn't
On Saturday 16 June 2001 23:54, Rik van Riel wrote:
> On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > > Does the patch below do anything good for your laptop? ;)
> >
> > I'll wait for the next one ;-)
>
> OK, here's one which isn't reversed and should work ;))
>
> --- fs/buffer.c.orig Sat Jun 16
On Sat, 16 Jun 2001, Daniel Phillips wrote:
> On Saturday 16 June 2001 23:06, Rik van Riel wrote:
> > On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > > As a side note, the good old multisecond delay before bdflush kicks in
> > > doesn't really make a lot of sense - when bandwidth is available
On Sat, 16 Jun 2001, Daniel Phillips wrote:
On Saturday 16 June 2001 23:06, Rik van Riel wrote:
On Sat, 16 Jun 2001, Daniel Phillips wrote:
As a side note, the good old multisecond delay before bdflush kicks in
doesn't really make a lot of sense - when bandwidth is available the
On Saturday 16 June 2001 23:54, Rik van Riel wrote:
On Sat, 16 Jun 2001, Daniel Phillips wrote:
Does the patch below do anything good for your laptop? ;)
I'll wait for the next one ;-)
OK, here's one which isn't reversed and should work ;))
--- fs/buffer.c.orig Sat Jun 16 18:05:29
On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
It _juuust_ so happens that I was tinkering... what do you think of
something like the below? (and boy do I ever wonder what a certain
box doing slrn stuff thinks of it.. hint hint;)
I'm sorry to say this box doesn't really
On Sun, 17 Jun 2001 [EMAIL PROTECTED] wrote:
On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
It _juuust_ so happens that I was tinkering... what do you think of
something like the below? (and boy do I ever wonder what a certain
box doing slrn stuff thinks of it.. hint
On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > Does the patch below do anything good for your laptop? ;)
>
> I'll wait for the next one ;-)
OK, here's one which isn't reversed and should work ;))
--- fs/buffer.c.origSat Jun 16 18:05:29 2001
+++ fs/buffer.c Sat Jun 16 18:05:15 2001
@@
On Saturday 16 June 2001 23:06, Rik van Riel wrote:
> On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > As a side note, the good old multisecond delay before bdflush kicks in
> > doesn't really make a lot of sense - when bandwidth is available the
> > filesystem-initiated writeouts should happen
On Sat, 16 Jun 2001, Rik van Riel wrote:
Oops, I did something stupid and the patch is reversed ;)
> --- buffer.c.orig Sat Jun 16 18:05:15 2001
> +++ buffer.c Sat Jun 16 18:05:29 2001
> @@ -2550,8 +2550,7 @@
> if the current bh is not yet timed out,
>
On Sat, 16 Jun 2001, Daniel Phillips wrote:
> In other words, any episode of pageouts is followed immediately by a
> short episode of preemptive cleaning.
linux/mm/vmscan.c::page_launder(), around line 666:
/* Let bdflush take care of the rest. */
out buffers
> > at some low rate to keep the pressure from rising too rapidly.
>
> Notice that write is not free (in terms of power) even if disk is spinning.
> Seeks (etc) also take some power. And think about flashcards. It certainly
> is cheaper tha spinning disk up but still no
te is not free (in terms of power) even if disk is spinning.
Seeks (etc) also take some power. And think about flashcards. It certainly
is cheaper tha spinning disk up but still not free.
Also note that kernel does not [currently] know that disks went spindown.
is spinning.
Seeks (etc) also take some power. And think about flashcards. It certainly
is cheaper tha spinning disk up but still not free.
Also note that kernel does not [currently] know that disks went spindown.
Pavel
--
Philips Velo 1
that write is not free (in terms of power) even if disk is spinning.
Seeks (etc) also take some power. And think about flashcards. It certainly
is cheaper tha spinning disk up but still not free.
Also note that kernel does not [currently] know that disks went spindown.
There's an easy answer
On Sat, 16 Jun 2001, Daniel Phillips wrote:
In other words, any episode of pageouts is followed immediately by a
short episode of preemptive cleaning.
linux/mm/vmscan.c::page_launder(), around line 666:
/* Let bdflush take care of the rest. */
On Sat, 16 Jun 2001, Rik van Riel wrote:
Oops, I did something stupid and the patch is reversed ;)
--- buffer.c.orig Sat Jun 16 18:05:15 2001
+++ buffer.c Sat Jun 16 18:05:29 2001
@@ -2550,8 +2550,7 @@
if the current bh is not yet timed out,
On Saturday 16 June 2001 23:06, Rik van Riel wrote:
On Sat, 16 Jun 2001, Daniel Phillips wrote:
As a side note, the good old multisecond delay before bdflush kicks in
doesn't really make a lot of sense - when bandwidth is available the
filesystem-initiated writeouts should happen right
On Sat, 16 Jun 2001, Daniel Phillips wrote:
Does the patch below do anything good for your laptop? ;)
I'll wait for the next one ;-)
OK, here's one which isn't reversed and should work ;))
--- fs/buffer.c.origSat Jun 16 18:05:29 2001
+++ fs/buffer.c Sat Jun 16 18:05:15 2001
@@ -2550,7
Hi!
> >Thanks for this patch. But why hasn't it been included into
> >the kernel earlier? Wouldn't be a combination of yours and my
>
> It's basically included into 2.4.x.
>
> >patch be the proper way? As far as I understand you switch
>
> Your patch is sure fine. BTW, 2.4.x have an high
it works for me.
> I have modified the constants used in fs/buffer.c to allow for
> bigger time intervals between forced buffer flushings. The "patch"
> may be found at http://www.hmi.de/people/brunne/Spindown .
Can you mail me the patch? [I do not have way to access
to allow for
bigger time intervals between forced buffer flushings. The "patch"
may be found at http://www.hmi.de/people/brunne/Spindown .
Can you mail me the patch? [I do not have way to access web easily.]
Shouldn't Linux support hard disk spindown during periods of
inactivity? Is the
On Tue, 12 Sep 2000, Jamie Lokier wrote:
> Dave Zarzycki wrote:
> > Personally speaking, I always thought it would be nice if the kernel
> > flushed dirty buffers right before a disk spins down. It seems silly to me
> > that a disk can spin down with writes pending.
>
> Absolutely. That allows
Hi!
> > On Sat, 9 Sep 2000 [EMAIL PROTECTED] wrote:
> > > Would it be possible to detect when the disk spins up, and do the flush then?
> > Yes if you had a continuious polling of power status wrt standby.
>
> I think the following flushing policy would work almost as well, while
> remaining
Dave Zarzycki wrote:
> Personally speaking, I always thought it would be nice if the kernel
> flushed dirty buffers right before a disk spins down. It seems silly to me
> that a disk can spin down with writes pending.
Absolutely. That allows more time spun down too.
-- Jamie
-
To unsubscribe
Dave Zarzycki wrote:
Personally speaking, I always thought it would be nice if the kernel
flushed dirty buffers right before a disk spins down. It seems silly to me
that a disk can spin down with writes pending.
Absolutely. That allows more time spun down too.
-- Jamie
-
To unsubscribe from
Hi!
On Sat, 9 Sep 2000 [EMAIL PROTECTED] wrote:
Would it be possible to detect when the disk spins up, and do the flush then?
Yes if you had a continuious polling of power status wrt standby.
I think the following flushing policy would work almost as well, while
remaining generic:
1 - 100 of 145 matches
Mail list logo
