[lkml]   [2001]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Ext2-devel] disk throughput

On Mon, 5 Nov 2001, Linus Torvalds wrote:

> And you have to realize that _whatever_ we do, it will always be a
> heuristic. We don't know what the right behaviour is without being able to
> predict the future. Agreed?

No arguments. While we are at it, let's just state once and forever:
FFS allocator sucks for fast-growth case
Everyone agrees with that, including me, you _and_ Kirk.

> The question is: "what can we do to improve it?". Not "what arguments can
> we come up with to make excuses for a sucky algorithm that clearly does
> the wrong thing for real-life loads".


> One such improvement has already been put on the table: remove the
> algorithm, and make it purely greedy.
> We know that works. And yes, we realize that it has downsides too. Which
> is why some kind of hybrid is probably called for. Come up with your own


> And maybe the fundamental problem is exactly that: because we're stuck
> with our decision forever, people felt that they couldn't afford to risk
> doing what was very obviously the right thing.
> So I still claim that we should look for short-time profit, and then try
> to fix up the problems longer term. With, if required, some kind of
> rebalancing.

Whatever heuristics we use, it _must_ catch fast-growth scenario. No
arguments on that. The question being, what will minimize the problems
for other cases.

On-line defrag can be actually fairly nasty - that had been tried and
it ends up with a hell of tricky details. Especially with page cache
in the game. And "umount once a month" is not serious - think of a
_large_ disk on a department NFS server. So I'd rather look for decent
heuristics before going for "let's defrag it once in a while" kind of

I definitely want to start with looking through relevant work - both
for the data and for information on _failed_ attempts to solve the

/me goes to dig through that stuff

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

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