Janito Ferreira Filho <jvffprog@xxxxxxxxxxx> wrote: > while digging through the BFS code, I found a minor TODO > (kernel_interface.cpp at line 91), and was wondering if it was > possible > to fulfill it. It says it would be better to use the device block > size > for alignment. To do this we would first need to get the device block > size. I found (on another part of the code) a way to do this, however > I'm not sure if it would be inefficient or how to handle error cases. > The idea is, from the inode, get the volume, then get the device, > create > a DeviceOpener and finally call the GetSize method. Is this a > suitable > approach? Or maybe just skip the DeviceOpener? 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). > Also, in the > CheckBlocks method of the BlockAllocator, the local variable group > contains the allocator group of the start offset, or the allocator > group > of the bitmap containing the start offset? 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. > If I understood the code > correctly, it should check inside the bitmap to see the respective > bits > (starting from start and up to length). Also, if I'm not mistaken, > the > bitmap blocks are on the beginning of the disk, following the > superblock. So it should first read the respective bitmap block > containing the starting offset, and from there iterate. However, it > seems to load the block from the start offset. This seems to work if > the > bitmap block contains the offset block (ie. if the start offset is > 0), > and after a grep through the files, it only calls with start = 0. > However I'm not sure the logic is entirely correct because if the > starting offset isn't zero, it would get the wrong blocks. Am I > missing > something, or is there a potential bug? 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. Bye, Axel.