[lkml]   [2003]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] concurrent block allocation for ext2 against 2.5.64
On Mar 13, 2003  14:25 -0800, Andrew Morton wrote:
> This is great work.

Agreed. This is something that has been talked about but not implemented
for a long time now. Thanks for the efforts.

> a) The algorithm which you are using to distribute the root-reserved
> blocks across the blockgroups will end up leaving a small number of unused
> blocks in every blockgroup. So large files which span multiple
> blockgroups will have little gaps in them.
> I think it's probably better to just lump all the root-reserved blocks
> into as few blockgroups as possible.

I might disagree here. One of the reasons for having the reserved blocks
is to prevent fragmentation, and not necessarily to reserve space for root.
For the lots of small files cases it makes more sense to leave free space
in each group to prevent fragmentation at the group level.

For the large file case, there is less need to worry about fragmentation,
so we can just ignore the group's reserved percentage for "large" files.
A heuristic which says "if this file is huge, just keep allocating from this
group, and screw the reserved blocks" makes sense.

One such heuristic is if the file is, say, larger than 1/2 or 1/4 of the
entire group in size, it is allowed to continue allocating from the same

We could also say that for the purpose of allocating new files in a directory,
anything more than 95% full is "full" and the inode should be allocated in
a different group regardless of where the parent is. It may be that the
Orlov allocator already has such a heuristic, but I think that is a different

Cheers, Andreas
Andreas Dilger

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:33    [W:0.403 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site