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
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
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 c
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 them.
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&m=118047865916766&w=2
I think it looks way too big.
If there are smaller patches, it might be a bit more r
Should we put these patches in 2.6.21-stable?
Gentoo developers did a full backport:
http://marc.info/?l=linux-ide&m=118047865916766&w=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 http://vger.ker
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 t
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 up
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 uti
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 memori
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) th
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 th
that 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 trigg
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 i
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 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 p
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 memori
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
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 flush
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> s
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 handle
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 b
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 ju
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,
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 b
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.
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 real
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 the
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
@@ -255
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 rig
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. */
wakeup_bdflush(0
iting 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 sti
t 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.
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 limi
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 web
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 gen
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 fr
On Sat, 9 Sep 2000 [EMAIL PROTECTED] wrote:
> Would it be possible to detect when the disk spins up, and do the flush then?
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 wi
Andre Hedrick wrote:
> 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
On Sat, 9 Sep 2000, Richard Gooch wrote:
>at least a day, IMO. There's probably no reason it can't effectively
>be infinite. The kernel shouldn't be enforcing policy in this area.
Right. An embedded usage where there are no writeable blockdevices can
just set the interval to zero and avoid a sch
On Sat, 9 Sep 2000, Tim Brunne wrote:
>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
On Sat, 9 Sep 2000, Alan Cox wrote:
Alan you assume that you only have one disk (this is okay).
How does this wakeup a spindown?
If you call a 'SETMULTI" and the drive is not ready it may/will hang the
system. This is why I think that the issue of a reset and then a polling
loop of
On Sat, 9 Sep 2000 [EMAIL PROTECTED] wrote:
> On Sat, Sep 09, 2000 at 03:25:35PM +0200, Tim Brunne wrote:
> > Thanks for this patch. But why hasn't it been included into
> > the kernel earlier? Wouldn't be a combination of yours and my
> > patch be the proper way? As far as I understand you switc
On Sat, 9 Sep 2000, Russell King wrote:
> Also, please note that I was talking about the whole machine, NOT just
> the hard drive.
Okay, but I was responding based upon the subject line.
Cheers
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe lin
Christoph Rohland writes:
> Russell King <[EMAIL PROTECTED]> writes:
> > (and I've seen my Thinkpad 380XD with RH's 2.2.14-5.0 kernel and
> > RH's apmd run itself dead. Kill apmd and it'll do the right thing
> > and suspend, then hibernate. And no, I haven't even attempted to
> > debugg it yet).
Russell King <[EMAIL PROTECTED]> writes:
> Jamie Lokier writes:
> > With laptops, people are willing
> > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > lose the data.
>
> But a buggy apm implementation and the battery running down can.
>
> (and I've seen my Thinkpa
On Sat, 9 Sep 2000, Tim Brunne wrote:
> I think Jamie is right. The nice feature of the old
> bdflushd deamon was, that disk writes were possible
> without spin up of the disk, because of RAM
> buffering. This is achived again by patching the
> kernel later than 2.2.10.
It is still possible with
Tim Brunne writes:
> Richard Gooch wrote:
>
> > Jamie Lokier writes:
> > > Russell King wrote:
> > > > > With laptops, people are willing
> > > > > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > > > > lose the data.
> > > >
> > > > But a buggy apm implementation and
> I have and offered it to the folks at linuxcare the apmd guys.
> The ideas were to create an ioctl pair that would/could knock-out a drive
> and preserve the settings, because the reset command to wake it up flushes
> the settings. Thus after the wakeup reset, and a checkpower-loop for
> ready-
On Sat, Sep 09, 2000 at 03:25:35PM +0200, Tim Brunne wrote:
> Thanks for this patch. But why hasn't it been included into
> the kernel earlier? Wouldn't be a combination of yours and my
> patch be the proper way? As far as I understand you switch
> off automatic buffer flushing completely, but it
Andrea Arcangeli wrote:
> On Fri, 8 Sep 2000, Tim Brunne wrote:
>
> >*a silent hard disk hard disk is no longer feasible since kernel
> >2.2.11*.
>
> Try:
>
> echo 40 500 64 256 0 >/proc/sys/vm/bdflush
>
> once you want to return to the old behaviour:
>
> echo 40
On Fri, 8 Sep 2000, Tim Brunne wrote:
>*a silent hard disk hard disk is no longer feasible since kernel
>2.2.11*.
Try:
echo 40 500 64 256 0 >/proc/sys/vm/bdflush
once you want to return to the old behaviour:
echo 40 500 64 256 500 >/proc/sys/vm/bdfl
g the local disk, so again in principle hours of work
are possible without a spinning hard disk. And I don't have
to tailor a lot of deamons, etc. . A simple write to
/proc/sys/vm/bdflush and calling hdparm once, both
in some startup script is sufficient.
Thanks to all of you for your
Andre Hedrick writes:
> If apmd could issue a WIN_STANDBY value and execute WIN_STANDBYNOW1 then
> the drive would know the thresholds to attempt a "suspend". Where as an
> issue of WIN_SLEEPNOW1 would "hibernate" the drive.
Ok, so that deals with the hard drive, so the series of events
on hiber
On Sat, 9 Sep 2000, Russell King wrote:
> Andre Hedrick writes:
> > You know that it would take me 25 minutes or less to fix the code if I had
> > a full native taskfile. This would allow a (void *)(void) to be set in
> > kernel apmd and have all the drive data and callouts.
>
> Andre,
>
> I t
Andre Hedrick writes:
> You know that it would take me 25 minutes or less to fix the code if I had
> a full native taskfile. This would allow a (void *)(void) to be set in
> kernel apmd and have all the drive data and callouts.
Andre,
I totally fail to see how taskfile will fix the problem of a
On Fri, 8 Sep 2000, Russell King wrote:
> Jamie Lokier writes:
> > With laptops, people are willing
> > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > lose the data.
>
> But a buggy apm implementation and the battery running down can.
>
> (and I've seen my Thinkpad
On Sat, Sep 09, 2000 at 12:32:27AM +0200, Jamie Lokier wrote:
> You're right, but what you're missing is that with "noflushd", it was
> possible to keep the disk spun down _even with pending writes_.
You may tweak /proc/sys/vm/bdflush
to have it collect data for a long time before it is written t
Jamie Lokier writes:
> Russell King wrote:
> > > With laptops, people are willing
> > > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > > lose the data.
> >
> > But a buggy apm implementation and the battery running down can.
>
> Well, perhaps the risk is worth it.
Russell King wrote:
> > With laptops, people are willing
> > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > lose the data.
>
> But a buggy apm implementation and the battery running down can.
Well, perhaps the risk is worth it.
-- Jamie
-
To unsubscribe from this l
Jamie Lokier writes:
> With laptops, people are willing
> to assume the RAM is reliable -- accidentally pulling the plug out won't
> lose the data.
But a buggy apm implementation and the battery running down can.
(and I've seen my Thinkpad 380XD with RH's 2.2.14-5.0 kernel and
RH's apmd run itse
Russell King wrote:
> > *a silent hard disk hard disk is no longer feasible since kernel
> > 2.2.11*.
>
> Yes it is. I have one of my machines (which NFS serves a NFS root
> client, both of which are on 24 hours a day) capable of spinning
> down for up to 4 hours at a time, with no kernel modifi
s
what so ever.
> Shouldn't Linux support hard disk spindown during periods of
> inactivity? Is the tiny patch worth of being included into standard
> kernels?
It does. You really want to think about how you partition your disk
in conjunction with what the filesystems will contain,
"patch"
may be found at http://www.hmi.de/people/brunne/Spindown .
Shouldn't Linux support hard disk spindown during periods of
inactivity? Is the tiny patch worth of being included into standard
kernels?
Yours,
Tim Brunne
--
Tim Brunne | web: http://www.hmi.d
78 matches
Mail list logo
