And there is nothing IDE related either. The code removed
at the time wasn't used!
-
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/
The 1/6th rule is an oversimplification, it should at least be based on how
much flush IO is already in flight, and other more difficult measures we
haven't even started to address yet, such as how much and what kind of other
IO is competing for the same bandwidth, and how much bandwidth is available.
> This is all fairly arbitrary, and is basically designed to map onto
> the time-honoured behaviour. I haven't observed any surprises from
> it, nor any reason to change it.
It's surprisingly resistant to flaming. The starvation problem is going to
get ugly, it's just as hard as the elevator starvation question and the
crude, inode-level resolution of the flushtime makes it tricky. But I think
it can be beaten into some kind of shape where the corner cases are seen to
be bounded.
I don't know, I need to think about it more. It's both convenient and
strange not to maintain per-block flushtime.
> We also need to discuss writeback of metadata. For delayed allocate
> files, indirect blocks are not a problem, because I start I/O against
> them *immediately*, as soon as they're dirtied. This is because we
> know that the indirect's associated data blocks are also under I/O.
>
> Which leaves bitmaps and inode blocks. These I am leaving on the
> dirty buffer LRU, so nothing has changed there.
Easy, give them an address_space.
[snip fascinating/timesucking sortie into online defrag]
-- Daniel - 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/