Over at IsComputerOn, an article discusses with Axel Dörfler, the Haiku move for the FreeBSD network stack. Also talked about is the thought of using ReiserFS instead of BFS.
Over at IsComputerOn, an article discusses with Axel Dörfler, the Haiku move for the FreeBSD network stack. Also talked about is the thought of using ReiserFS instead of BFS.
What use is to me Haiku then if it doesn’t use BFS? Why use ReiserFS? I don’t get it. I f I want another Linux distro I can get one. Sad, so sad. Since Zeta is such a dissappointment, I was putting my hopes into Haiku. Seems BeOS IS dead
Who cares if it uses BeFS or it has magic fairies hold onto data for you? As long as it has the same user-visible features, what does it matter?
That said, if they do manage to port ReiserFS that’d be pretty impressive indeed. Linux filesystems are closely tied in with both Linux’s kernel locking mechanism and its page cache. It’d be quiet a feat to do the port.
why not take the kernel too?
The Be OS is a hybrid microkernel and FreeBSD is not. Some people actually like the design of a microkernel. Still it is an interesting concept to take the well designed FreeBSD monolithic kernel and layer Be OS elements onto it.
The BeOS kernel is not a true microkernel. I’ve read that it was more of a microkernel in the very early BeBox days. Marketing has perpetuated this buzzword. FreeBSD’s kernel is not monolithic. They are both pretty hybrid/modular. But I suppose it’s all a matter of definition. Interesting, however, is that DragonFly BSD, the offspring of FreeBSD 4.x (4.8?), may end up much more microkernel-ish than BeOS. BeOS-clone Haiku is no more a microkernel than BeOS, AFAIK.
Comparing FreeBSD or Linux to BeOS, they aren’t so different in where the features live. Device drivers run in kernel-space, with video as the notable exception in both BSD/Linux and BeOS. Daemons/servers and libraries provide higher-level OS services.
The cool thing about BeOS, IMO, is its neat, simple C++ API, the metadata features, the “virtual root” (rootfs), the presentation of the filesystems, the folder hiearchy, the mime-based filetype system, and the user experience of the complete system. This is what makes the BeOS great. I don’t see the things I love about BeOS in BSD or Linux yet. Don’t get me wrong. They are definitely superior to BeOS in file and network services, and the unix desktop environments are making a lot of progress.
I guess there will still be BeFS support but they wont improve it, and they’ll move all development and future FS enhancement over to ReiserFS
I’m all for it. If existing components can be used without any significant disadvantages, why reinvent the wheel? This way the Haiku team can devote its resources to other tasks.
I don’t get it? I thought FreeBSD had a stack that was considered at this point to be aging and sub par. A lot of work has gone into making the linux stack multiprocessor friendly and I seem to recall one of BeOS’s claims to fame was the the entire GUI was heavily threaded thus yeiled high benefits from SMP systems.
I don’t personally like reiserFS because it ate my data one time but I could see why you’d use it in an OS that really isn’t ready for production yet. It has many cool features and shares some of the design philosphies of the original BeFS
I don’t get it? I thought FreeBSD had a stack that was considered at this point to be aging and sub par. A lot of work has gone into making the linux stack multiprocessor friendly and I seem to recall one of BeOS’s claims to fame was the the entire GUI was heavily threaded thus yeiled high benefits from SMP systems.
I’m going to guess it’s because of licensing.
To all those who don’t know: BeOS/Zeta’s own “BONE” networking stack is HIGHLY based on the FreeBSD networking stack. It does not use portions of its code, but this is where the Be engineers LOOKED and got INSPIRED and used IDEAS in order to write Bone.
So, when Axel says “I want to use FreeBSD’s stack”, he doesn’t go too far from where Be engineers themselves looked. It is all good IMHO and a nice idea.
As for ReiserFS 4, as long as it does provide ALL the BFS features, I agree that it is a good idea to switch to it too, because Haiku’s BFS was *never* really TESTED as they properly testing file systems on other commercial OSes: crazy day and night testing that is with SPECIAL scripts. ReiserFS on the other hand *is* enjoying testing from Novell/SuSE, and so it might prove to be a good candidate because of this testing that has undergone.
FreeBSD’s network stack has always been world-class. What was the problem was that it wasn’t as fine-grained multithreaded as Linux’s, which mean it didn’t scale well on SMP. However, as part of FreeBSD’s SMPNG project, they’ve been worked on fixing those issues. In any case, concurrent performance doesn’t matter on Haiku. It’s a desktop system, and desktop users don’t have enough connections open simultaniously for it to be worth distributing the network stack across multiple CPUs.
I think he’s talking about Reiser4. If I remember the plugin system properly you could probably emulate most of the BFS features while having access to the really good design of Reiser4.
FreeBSD has a really nice network stack. Sounds very logical to use it.
I don’t know enough about technical differences of OBFS/BFS and ReseirFS4… ReseirFS looks very good and capable (I’m also risking and saying that Linux doesn’t really using some of it’s strengs…). I really liked how BeOS was, and BFS is part of it, but I can’t say it was perfect…
But, if it’s like Axel said:
“And to solve all BFS downsides, we would need to break on-disk compatibility anyway”
and:
“We will have a close look at how to solve the problems of BFS, but if ReiserFS maybe delivers all what we expect from a BFS successor (…)”
Than it’s good for me… =]
I’m looking foward for Haiku… maybe we can have in a not so distant future… =]
FS support only requires a Driver to access the FS I/O inputs / outputs and any other advanced functioinality, Linux FS’s dont interact with the Kernel they interact with the VirtualFS Layer, the Only FS that the Linux kernel is tied to is ext2; which all Linux kernel compiles must include.
Not really true. Linux filesystems are also very closely tied to the page cache, because Linux does all buffered file I/O through the page cache. The Linux page cache doesn’t have nearly the kind of well-defined API that the VFS does, which makes the task of disconnecting something from it much more complex.
*IF* we do decide to go the ReiserFS way, we will do whatever we need in ReiserFS so it will have axactly the same functionality as BFS does today. That said, using ReiserFS is just one possible scenario. Right now we use (Open)BFS and we will stick to it.
-Bruno (OpenBFS Team Lead)
What FS are you talking about ReiserFS (3.6) or Reiser4 ?
Are you kidding? FreeBSD’s stack is one of the finest in the world. A FreeBSD box can route 1 million packets per second. Try that with the proprietary Microseft XP joke. (Hint: Microseft can barely route 10000 packets/sec).
You do know Microsoft “borrowed” it’s TCP/IP stack from BSD don’t you?
Microsoft at one point used a stack from a company that based their product on the FreeBSD code. The NT team rewrote the stack later, but still kept some of the userspace utilities from that product (like the FTP client).
You do know Microsoft “borrowed” it’s TCP/IP stack from BSD don’t you?
And you do know they ditched it for their own stack afterwards, don’t you?
NT’s network stack has been based on FreeBSD’s since NT4(?).
http://www.kuro5hin.org/?op=displaystory;sid=2001/6/19/05641/7357
Great article, clears up the nonsense. It also has my favorite line in an internet article ever: “It’s like the event horizon calling the kettle black!”
BeFreeBSD or FreeBeSD? What other cute names will come forth.
I thought the BFS was the part of Haiku what was the fastest one to be nearly in beta phase. Too bad they have to replace it. But ReiserFS will do, that is for sure. Still they need BFS support for downward compatibility.
An added pro of ReiserFS is that Haiku and Linux could (in theory) live on the same partition (not that you should want that) and could easily share files for dual-boot systems. That will speed up Haiku acceptance.
mmmmmmmm… everyone, it’s just a thought, an idea, not even a concept. People are saying “Too bad they have to replace it” (sorry for quoting you evert
, refering to BFS, and this just an idea. Don’t jump the gun 
DaaT
Isn’t Haiku MIT/BSD licensed? Why would they would move in this direction. If they start linking GPL’d components into the Haiku then they may as well adopt the linux network stack as well. At that point, why base Haiku on newos? Why not just build Haiku on top of Linux?
I hope they extend BFS instead. Alternative component implimentations that showcase different strengths foster competition and help drive technology forward.
And FreeBSD’s network stack is not aging or sub par. In fact, it just went through a massive overhaul to make it more SMP friendly. To compliment the locking work, a developer has been funded to do 3 months of full-time performance tuning ( starting monday ). FreeBSD will be a top performer again, but this time on SMP as well as UP systems.
The Reiser4 team is probably as big as the entire Haiku kernel team, and is led by a guy whose spent the last decade working on filesystems. Sun offered him the job to architect their new filesystem, and he turned it down so he could work on Linux. That’s one heck of a steep hill to climb. I don’t want to put words in their mouth, but if I were in the same position, I’d try to take advantage of that already-available work. Certainly, there are more interesting things to do in Haiku than to try and one-up a filesystem design that is already pretty damn good.
The maker of BFS has worked for SGI, Be, Google, QNX, and is currently at Apple. I.e., he’s no sub par programmer.
http://www.nobius.org/~dbg/
I believe OpenBFS was made possible in part by his book “Practical File System Design with the Be File System” and whatever necessary reverse engineering.
Anyway, let the future come as it may.
No doubt. I have his book. However, note that his work at Google, QNX, and Apple all occurred after BFS was designed, and IIRC, he didn’t work on XFS at SGI. But that’s completely besides the point. The question is how much original design work went into BFS. If you read the book itself, you’ll see that BFS was designed in fairly serious haste. If you read the book, you’ll see that he mentions that BFS was designed, implemented, and tested in ten months. That means that, at most, a few months of design work went into it.
ReiserFS and BFS were started around the same time: 1996-1997. The main difference is that ReiserFS has been continually developed by Namesys ever since then, while no information about the design of BFS ever left Be since 1999 (when Practical Filesystem Design) was written.
If you actually look at the design of BFS, these facts are plain to see. BFS is an excellent design for a traditional filesystem. However, algorithmically, its more at the level of ext3 than reiser4.
You do know your stuff, Rayiner.
I don’t think ReiserFS should be taken to seriously as a successor of (open)BFS.
First and foremost they “will have a close look at how to solve the problems of BFS” before porting a different FS.
Furthermore, I think ReiserFS was mostly mentioned as an example of a (stable) ready-made (popular?) file system.
When the time comes for a BFS2, I’m sure the pros and cons of most file systems out there will be taken into consideration, including the license.
V
On the stack, watever. As long as the coding API don’t get messy, that the performance are still there and that it does not eat RAM for nothing.
On the file system, being a desktop OS imply doing choice. For one, the speed to delete the trashcan for exemple is a non-issue. It’s like booting-shutdown speed, i don’t care how fast it shutdown, i care if it boot fast.
It’s also important the core OS team know well the file system. I think it is well know as of now. The reason is that we talk R5 FS here. We need to keep our door open for possible different concept in the future. Being too related to reiser 4 without it being a fork is dangerous to have the FS impacting the OS design in the long run.
For one, i would like Haiku R2 to be a lot less FS centric (like most OS are now) and be more OO. That mean see FS simply as a “keep data when computer is off” and not as a central center of the computation almost as much as the cpu is.
Texas made 64M ferromagnetic permanent RAM module. Look at the time haiku will be at release 2 and you see that this technology will be around. If you don’t want to play catchup later you need to code those possibility right now in the infrastructure.
M$ and other apple don’t need to think that way as they can afford to buy startup when the time come and if they missed the boat. They can also have support from the gizmo maker in the shadow to have it ready on launch (like currently with most drivers) . OSS project can’t, they need to code the future today to be there to intersect new consumer electronic when it hit the street.
In the end, as long as the FS bug-limitation are fixed i’m fine with it, just beware of a “possible” bloat and too much reliance that taking already made code can bring.
AlienSoldier
What does Texas’ ferromagnetic memory have to do with the File System? Won’t it take the role that HD or RAM has traditionally fulfilled?
If it takes the role of HD, it’ll need a FS.
If it’s used as RAM then the access method would/should also be compatible with traditional RAM and can be used as a RAMdisk.
If it’s used in a different manner, it’ll probably need a device driver when/if the product comes out and could be exported as a data storage device (or HD) and should still use a FS. There’s not much to do before you have the product to test and preferably some documentation.
V
Will changing the file system change how BeOS handles files?
For instance, before i could move a file while it was being writtten to the hard drive. Willt his still by possible?
That’s possible in Linux too. Any OS that identifies files by file descriptors rather than path names (ie: not MacOS Classic), won’t care if the pathname is changed while the file is being written.
ReiserFS insted of BFS and FreeBSD in place of BONE? I don’t understand it. Zeta is starting to look better.
My question would be: is current haiku network stack really worth throwing away and beginning the work again from start. As I understand, current stack is inspired form BSD stack, but built more in BeOS style. Also, I know it works (?) So, why all the rush? Let’s improve currnet stack and make it even better than BSD-s.
The BSD stack is the product of over two decades of development. Making a network stack “better than BSD’s” would be a project the size of Haiku itself.
Now, that is not to say that I think Haiku necessarily needs to replace its stack. If it works and is stable, then fine — its a desktop OS, so who cares how good the network stack is? However, I think its important to have a little perspective of just how hard and time-consuming it is to build stuff like this!
Haiku’s network stack is terrible, believe me!
It is *not* thread-safe and making it safe would mean a huge amount of work. FreeBSD’s 5.x netstack is already thread-safe (but coarse-grained).
Haiku’s current code looks very ugly (and there are hidden bugs). FreeBSD’s stack is more well cleaned-up and one of their developers wants to further clean-up and speed-up the TCP and routing code (if he gets enough money).
See: http://www.osnews.com/story.php?news_id=11347
If Haiku’s port will be maintainable enough such that upgrades from FreeBSD are easy they get a high-quality netstack that is maintained by the FreeBSD team nearly for free.
Maintaining the current code is annoying.
Porting new protocols/features is difficult. Some day Haiku will need to have IPv6 and porting the protocol from FreeBSD is easier if they have the newest netstack version (since it was written for that version).
The current netstack is implemented such that it works on net_server and BONE. The new port could probably drop net_server compatibility (I’m not talking about R5 app-compatibility). The select() emulation code is not needed, for example.
As an example, non-blocking sockets do not work correctly, so e.g. Firefox doesn’t either. And nobody knows why (but nobody really looked at that problem intensively).
To those who think Haiku should have its own BeOS-style netstack: in the repository somewhere under tests/… you will find new_stack. Some nice ideas, but not efficient enough, too much work.
Then, look at Marrow (David Reid). He started a new netstack, but in the end he mostly reused FreeBSD’s code (so, it’s BONE-like, but with newer codebase). Currently, Marrow does not progress much (or at all).
You see, there are too many problems and not enough developers. There is one developer trying to write a DHCP client module (no code in repository, yet, AFAIK). And Philippe (team lead) does not commit to the net code very often, either, since he started the Mesa port and his work on OpenGL. Well, that’s it. Basically, there is no activity at all.
One ambitious developer could easily port FreeBSD’s netstack and I think that in the end Axel will be the one (even if he doubts it ATM
.
IMHO, this is the right decision and the port should/could have been started at least half a year earlier.
Thank you for dropping that comment! It made me calm down a bit.
there’s one “but” with reiser FS – There’s no code yet existing. Haiku already has almost stable openBFS.