[lkml]   [2000]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Notebook disk spindown
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 the battery running down can.
> > >
> > > Well, perhaps the risk is worth it.
> > At the least, people should be able to choose whether they are willing
> > to take the risk or not. So a CONFIG_ option would do.
> > Has such a patch been submitted?
> 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.
> In my opinion a CONFIG_ option is not necessary:
> In fs/buffer.c there are already *default values* and
> *upper limits* for relevant kernel paramters present.
> I just increased the upper limits *to be able* to modify
> kernel parameters to suit my needs. Changing the upper
> limits does *not* modify the default behaviour of the
> kernel.

OK, good.

> So I think my tiny patch or some similar one should
> become part of future kernels. There may be a more
> reasonable choice for the upper limits. --- Unfortunately
> I do not know how to "officially submit" a patch, if that
> is what Richard means.

Ask people like Rik and Andrea about reasonable upper limits. Make it
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.
Memory pressure would force disc writes eventually anyway.

Hack 2.4.0-test8 and test it. Then submit a to Linus and Cc: the
kernel list.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.084 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site