On Fri, 14 May 1999 12:54:01 +0200 (CEST), Andrea Arcangeli wrote:
>On Thu, 13 May 1999, Steve Willer wrote:
>
>>Ideally, the flushing algorithm would be tightly coupled to the wakeup
>>time calculation. update is quite simplistic, and also isn't part of the
>
>update can run every msec but the number of dirty buffer flushed/sec has
>to remain the same. That doesn't happen due the current flushtime design
>but this is a completly different issue (and I just spotted and fixed it
>some time ago), you don't need to kill update if there's a bug somewhere
>else.
>
>Even if you run update very frequently you won't flush more data to disk.
>The only point of update is trying to be friendly under crash. Nothing
>more.

`Being friendly under crash' is an essential behavior which should not
be made light of.

Your jumbo patch tries to do so many different things at once that I
cannot evaluate it.  Could you please separate out the flushtime
changes versus 2.3.1?  Leave everything else alone.  Then I will
attempt to say something meaningful about it.

atime is a red herring.  It does affect performance, but mounting
noatime doesn't suffice to let a disk spin down when the system is
"idle"; you have to postpone real data writes.  This is something I am
extremely reluctant even to consider, but since there is huge demand,
I will see what can be done.

Also, you took the scan of the locked buffer queue out of bdflush.
Are you sure this is safe?  Running with debugging compiled in, I saw
a dirty buffer on the clean list occasionally - just one, and under
very specific conditions (right at the beginning of bonnie's seek
tests), so there's another bug somewhere else.

zw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/