lkml.org 
[lkml]   [2001]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: O_TRUNC problem on a full filesystem
Hi,

On Fri, May 25, 2001 at 10:24:49AM +1000, Andrew Morton wrote:

> For example, when we miss the goal block we search forward
> up to 63 blocks for a *single* free block, and use that.
> Perhaps we shouldn't?

The reasoning here is that it's much cheaper to go to a single block
which is very nearby than to be forced to use that single block later
on as part of some distant file once the disk becomes fuller. It's a
sort of opportunistic fragmentation: if we can sneak in a disk
allocation that uses the awkward block without requiring a seek (and
in all likelihood coming out of the track buffer), then we reduce the
overall impact on performance of that isolated free block.

> And perhaps the search for eight contiguous free blocks
> is no longer appropriate to current disks. 32 may be better?

I've thought about that but today we're usually allocating in 4k
chunks rather than 1k so it's normally a 32k preallocation which we
get, anyway.

Cheers,
Stephen
-
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 12:53    [W:0.066 / U:1.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site