Re: the " 'official' point of view" expressed by kernelnewbies.orgregarding reiser4 inclusion

From: Hans Reiser
Date: Sun Jul 23 2006 - 18:13:40 EST

Jeff Mahoney wrote:

> That particular bug isn't in the bitmap scanning code, it's a side
> effect of the write batching higher up.

Did you write the code that looks for a window of 32
blocks? If not, and if this code has been around for a long time, I
apologize. I thought you did write it and added it in recent months.

> It's a pathological case when the file system is seriously fragmented.

Most bugs are pathological cases.;-)

> A
> quick fix would be to set a flag indicating that future writes shouldn't
> bother trying to find a window that large,

There are lots of quick fixes. 1) The quickest is to not scan for the
window at all. 2) The second quickest is to limit the number of bitmaps
that will be scanned to some number like 3. 3) The not at all quickest
is to track free extents like XFS does, which is not a hack, but it
belongs in a development branch. I am not sure it is worth the
complexity, but my mind is not closed.

On monday we will do 1) or 2), probably 1). After the repacker is
done, we should review all our block allocation algorithms. I have an
idea for how to do things more optimally for streaming media that will
avoid fragmentation over time, and when combined with the repacker may
make 3 not worthwhile.

I am grateful that you and Chris do bug fixes, but when you guys are too
busy, (and that can and will happen to any of us), the baton needs to
get passed. V3 needs to be a zero defect product, and once we know it
is a bug I don't want bugs in V3 to remain unfixed for more than a day
plus the time it takes to fix it. If you do add code, I want any bugs
that show up in the aftermath of mainstream merging to get jumped on.

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