[haiku-development] Re: BFS code questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 06 Apr 2010 21:48:07 +0200
Janito Ferreira Filho <jvffprog@xxxxxxxxxxx> wrote:
> > This function is used for every read or write operation at least
> > once -
> > it's not an option to call anything else in there.
> > However, one should add a physical block size member to Volume,
> > fill
> > that during Mount(), and just use that through a getter method.
> > Then
> > indeed the DeviceOpener should retrieve the information (alongside
> > the
> > rest).
> Ok. I'll see if I can do that in the weekend =).
Okay.
> > It's initialized like this in line 1639:
> > uint32 group = start >> fVolume->AllocationGroupShift();
> >
> > The shift is the number of bits to shift a block offset in order to
> > get
> > the group index.
> Therefore it returns allocation group containing the block containing
> the "start" byte offset argument?
Exactly, just that "start" is in blocks, not bytes.
> > You are indeed missing something :-)
> > The incoming "start" argument is the first block to check. The
> > CachedBlock is then set to the allocation group containing the that
> > block (retrieved as above), and the block offset within that group
> > ("groupBlock"). In each subsequent iteration, the groupBlock is
> > incremented until the end of the current allocation group is reached
> > which is when "group" is incremented as well, and "groupBlock" is
> > reset
> > to 0.
> Ok. I'm not sure I understood correctly. Does this mean every
> allocation
> group contains it's own bitmap blocks?
Sort of - the whole block bitmap is divided into allocation groups.
> Sorry, for the false alarm... =)
No problem - better one time too often than living with a bug just
because you didn't mention something; usually it hints to code that
could receive some refactoring in order to make it clearer to
understand, at the very least :-)
Bye,
Axel.
Other related posts:
