Another BFS surprise
Turns out BFS logging code is not that intelligent - it uses block_runs in the log area, but it doesn’t make use of them. In other words: it only accepts block_runs with length 1 - which effectively kills the whole idea of using them. It’s now as space consuming as the single block number arrays I had before, but doesn’t share the binary search capability we had earlier.
While our code now could use block_runs how they should be used, I have disabled joining separate block_runs to make our BFS fully compatible to Be’s in this regard. If we someday leave compatibility with the current BFS behind, we can enable it again, of course.
While this is probably just a fault in the implementation of the original BFS, it’s not the first time we have to live with a sub-optimal solution in order to retain compatibility. The good thing is, since we should be 100% compatible to BFS now, it should also be the last of these surprises now.
- Haiku to mentor 3 interns in Outreachy and GSoC
- Introducing myself gsoc 2019
- [GSoC 2019] Improving the btrfs filesystem
- Haiku monthly activity report - 03 and 04/2019
- NVMe Driver Now Available
- Most long-standing XHCI (USB 3.0+) issues resolved!
- Haiku monthly activity report - 02/2019
- Haiku monthly activity report, January 2019
- Haiku monthly activity report - 12/2018
- Haiku monthly activity report - 11/2018