On Sunday 26 October 2014 at 17:45:33, Edward Shishkin wrote:
> [...]
> >
> >>> BTW, in plugin/space/bitmap.c:1141 (around that line)
> >>> in function alloc_blocks_forward()
> >>> shouldn't the second scan be done with bitmap_alloc_backward(), as per the
> >>> comment?
> >>
> >> I think that those comment means a jump in backward direction
> >> (to the start) and one more pass with bitmap_alloc_forward().
> >> Such a "compound, non-monotonic" forward...
> > I don't intend to argue here, but doesn't that defeat the purpose of hint->blk?
> > The first pass begins from the *closest* blocks. And if it fails, the second
> > pass begins from the *most distant* blocks...
> >
> > ("closest" and "most distant" terms are used here with respect to hint->blk)
>
>
> You don't like the block allocator?
> Actually it was a subject of long investigations in ReiserFS (v3).
> You can find a number of block allocators in ./fs/reiserfs/bitmap.c
> I don't know which one went to reiser4..
I've specifically stated that I don't intend to argue or claim that the
allocator is wrong in any way :)
That thing has just seemed strange to me, so I decided to ask whether is this
intentional and, if yes, what was the intention.
--
Ivan Shapovalov / intelfx /Attachment:
signature.asc
Description: This is a digitally signed message part.
