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
Hi!
> o developpers,
>
> this is a short description of a particular wish of notebook
> users. Since kernel 2.2.11 the buffer flushing deamon is no longer
> a user space program but part of the kernel (in fs/buffer.c).
>
> Before this kernel release it was the bdflush-program which
> could
Hi!
o developpers,
this is a short description of a particular wish of notebook
users. Since kernel 2.2.11 the buffer flushing deamon is no longer
a user space program but part of the kernel (in fs/buffer.c).
Before this kernel release it was the bdflush-program which
could be
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:
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 more
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
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
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
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 checkpower
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
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
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
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
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
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
>
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
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 the battery running down can.
> >
>
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
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
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
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
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 totally
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
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 the battery running down can.
Well, perhaps the risk
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
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
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 Thinkpad 380XD with
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).
Enable
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
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 switch
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 checkpower
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
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
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
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
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
Tim Brunne writes:
> *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 modifications
what
Hello developpers,
this is a short description of a particular wish of notebook
users. Since kernel 2.2.11 the buffer flushing deamon is no longer
a user space program but part of the kernel (in fs/buffer.c).
Before this kernel release it was the bdflush-program which
could be called with
Tim Brunne writes:
*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 modifications
what
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 modifications
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 itself
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 list:
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.
At the least,
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 to
53 matches
Mail list logo
