lkml.org 
[lkml]   [2002]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: faster boots?
Itai Nahshon writes:
> On Sunday 07 April 2002 17:42 pm, Pavel Machek wrote:
> > Hi!
> >
> > > I'm curios, how much work can you accomplish on your laptop
> > > without any disk access (but you still need to save files - keeping
> > > them in buffers until it's time to actually write them).
> >
> > Debugging session (emacs/gcc/gdb) for half an hour with disks stopped is
> > easy to accomplish.
> > Pavel
>
> My suggestion was: there should _never_ be dirty blocks for disks
> that are not spinning. Flush all dirty buffers before spinning down,

This is fine, and I wish the block I/O layer was smarter and could
handle spin/idle management itself, rather than telling the drive to
spin down after inactivity. That way, when the bio layer sees
inactivity, it can tell the drive to go to sleep, but first it can
flush any remaining buffers.

> and spin-up on any operation that writes to the disk (and block that
> operation).

Absolutely not! I don't want my writes to spin up the drive.

> The opposite to that (which I do not like) processes create as many
> dirty buffers as they want and disk spins up only on sync() or when
> the system is starving for usable memory.

Maybe you don't like that, but many of us with laptops prefer that
behaviour. And for many reasons, it is definately the correct
behaviour.

> An aletrnate ides (more drastic) is that fle systems can mount
> internally read-only when a disk is spinned-down. Means - you cannot
> spin down when there is a file handle open for writing. Other than
> this there are advantages.

Undesirable behaviour.

> I don't see how any of these will stop you from doing emacs/gcc/gdb
> with the disk stopped, as long as you are not trying to write to the
> disk or read from files that are not cached.

But I *want* to write while the drive is spun down. And leave it spun
down until the system is RAM starved (or some threshold is reached).

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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