[haiku-development] Re: BFS code questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 07 Apr 2010 17:38:09 +0200
Hi Janito,
Janito Ferreira Filho <jvffprog@xxxxxxxxxxx> wrote:
> > Exactly, just that "start" is in blocks, not bytes.
> I think I got it now. Dividing "start" by the number of bits in a
> block
> (BlockSize() << 3) we have the block that contains the start bit.
> And doing "start" % number of bytes in a block, we have the byte that
> contains the start bit.
Indeed.
> What I still don't understand is why we calculate the "group" that
> way.
> Shouldn't it be (block that contains the start bit) / (number of
> blocks in
> an allocation group)? And the remainder be the actual "groupBlock"?
Blocks span over the whole device, and all blocks are divided by
allocation groups; the block 0 only exists once, in the first
allocation group. By dividing the block by the number of blocks in the
allocation group, we get the group index.
> Also, the AllocationGroupShift() returns the log2 of the number of
> blocks
> or bytes in an allocation group? (I assume it's blocks =)
Blocks. There is no byte level in the block bitmap (that's even
expressed by its name) ;-)
> > 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 :-)
> If you want, I could comment the lines to explain the calculations.
> Thanks for your help, =)
Why not, although I guess it would be better to have some overview
documentation at the beginning of the file that explains the
architecture, even though you can find it all in the BFS book:
http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf
-- at least I think that this should be all that makes you not
understand the code.
Bye,
Axel.
Other related posts:
