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.
10 Comments:
I think a split of OBFS should be considered. For now 100% compatibilty is a good thing. But once Haiku leaves the ground how often will this really be an issue? Either a new format, OBFS with the different journalling system should be considered. A little advancemen would not be a bad idea.
I think Haiku should, for version 2 at least have an alternative file system.
I for one vote for Reiser4 becasue of the file system plugins and work that's went into it.
Also, it would add one more buzzword to the list, and isn't that why we're all here ?
It seems like Reiser4 isn't really an option, as the whole thing is GPL.
The on disk data structures are interesting, but there are plenty of improvements in the driver that can't be copied into Haiku due to licencing issues
Can't the file system be gpl'd?
It'd not like people are dying to use it.
Does it even matter that the file system is gpl?
That doesn't mean the whole of Haiku has to be gpl.
AFAICT, GPL drivers or file systems are not problematic at all - the license of our kernel is compatible with the GPL - our license is just less restrictive. You could relicense our kernel under the GPL without getting into legal issues, but you couldn't relicense a GPLd driver under the MIT.
Anyway, BFS is still a good file system - I'm using it for years, and the only real complaint I have is it's slowness with small files. And that can mostly be attributed to the index support, and some BeOS faults (like the cache).
Despite the chkbfs design problem, and the usual bugs, where BFS really falls is missing defragmentation - it ages, and all you can do about it is to reformat the drive. And that's where our BFS could shine, but doesn't do so right now, either.
> And that's where our BFS could shine
So that could be a good reason to switch to OBFS for Haiku ... nope ?
So I'm thinking we (i.e. you) will break compatability and fix the problems with obfs (ohfs?) for haiku version 2 or have a legacy mode.
> So that could be a good reason
> to switch to OBFS for Haiku ... nope ?
I'm afraid I don't understand what you are saying. Of course we are using our version of BFS, no matter if with or without defragmentation support.
I think he meant: When will you break compatibility to use your system of log which seems better (if i understood what you said) than Be's one.
For R2 we will certainly break on-disk compatibility - but if that means a BFS2 or a tuned ReiserFS, I honestly don't know yet.
In any case, we'll keep a compatible version of BFS around, and may even include a tool that lets you switch to the new file system easily (likely if there will be a BFS2).
Post a Comment
<< Home