“Reiserfs is fast and reliable. The new ext3 is an easy upgrade. Both journal metadata, but ext3 journals data too, but at a big price. Which journaling filesystem is right for you?” The IDG Network discusses which Linux journaling filesystem is right for you. Our Take: Personally, I would definetely go with SGI’s XFS.
Reiserfs or ext3: Which Journaling Filesystem is Right for You?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Exactly why would you rather choose XFS, Eugenia? I havent read too much about XFS, though I know a bit about ext3 and reiserfs, and would like to know what you base that sentence on…
More features, more BeOS-like, especially in the IRIX version (nodes are supported better under IRIX). You can read http://www.osnews.com/story.php?news_id=69“>here here” rel=”nofollow”>http://www.linuxgazette.com/issue55/florido.html”>here</A>… for more info.
Considering XFS blows away BeFS on many of its technical aspects (see <a href=”http://oss.sgi.com/projects/xfs/features.html“>here), I don’t doubt Eugenia prefers it. For me at least, Reiser has always been slow to mount and taxing on the CPU … XFS on the other hand just seems more refined. I don’t have enough technical experience with either XFS or Reiser to comment much more.
Yes, XFS is indeed more mature and more powerful than BeFS (got to love its Live Queries though) and ReiserFS/ext3. IBM’s JFS is my second best. Also, do not forget that Dominic Giampaolo, who wrote the filesystem book and also designed and wrote BeFS, used to work for SGI and XFS before he started working at Be. 😉
… that there isn’t (?) any way of combining XFS and the BeFS Live Queries … Hey, I can dream can’t I??
that would be nice 🙂
‘Live Queries’ is not just part of the filesystem feature set, as it requires special kernel support for it. IRIX & BeOS, have this feature in their kernel, Linux does not.
well before BeFS can be supported in Linux, it must have Kernel support, so they put the full support into the kernel with a module (until Linus puts it in the main tree) and vuala full BeFS support……….I love OSS 🙂
>well before BeFS can be supported in Linux, it must have Kernel support, so they put the full support into the kernel with a module (until Linus puts it in the main tree) and vuala full BeFS support……….I love OSS 🙂
What?!?
What do you mean what? you can put the kernel support into the Linux kernel by way of modules. then when Linus feals that the module is stable enough for the kernel tree he can add your code to the regular system.
thats how it works.
Yes, but you are talking about BFS. BFS is closely tight to BeOS, there is no one working on porting BFS to Linux, neither it is possible to do so (technical reasons which have to do with BeOS reentrant, preemptive kernel nature something that Linux does not exercise by default).
If you are talking about the BlueOS guys, they are not porting BFS. They are using ReiserFS, and then they are writting a BFS wrapper *API* on top of ReiserFS.
oh well I thought we were talking hypotheticly here not realisticly. but all the realtime/preemptive/reentrant stuff can theoreticly be placed in the Linux kernel, except it would fundamentaly change the kernel so much that I doubt Linus would put it in the main tree…..that is why the preemptive patch has not been included yet…..mabye 2.5.x
I should have made my self more clear though, I was just hypothisising.
BlueOS is using Reiser? :/
Yes. This is what they told in the interview a month ago.
I emailed them privately and asked them to go with XFS at least, but Guillaume prefers ReiserFS for some reason.
For most people, XFS would be the better filesystem, but there are many cases in which Reiser wins out. In particular, metadata manipulation in ReiserFS is many times faster (it has a very fast journeling implementation) so things like creating/deleting/growing files runs more quickly. A squid server, for example (which is very metadata-manipulation-speed dependant) often runs twice as fast on ReiserFS as on XFS. However, on most workstation systems (ie. doing wordprocessing, web-browsing, image-manipulation, compiling, etc) file sizes tend to be bigger (the average source file size in Linux is around 10-20KB, a six-page average Word document is 20-40KB) than ReiserFS’s optimal of around 4-10KB, so at that point XFS’s throughput advantatages start to kick in, and meta data performance isn’t as important. The difference between the two filesystems isn’t enormous, however. Compiling the Linux kernel, for example, takes almost the same amount of time on both filesystems. In the end, I use XFS, not so much for its throughput (though if I did more high-res media, it would be a factor) but because it is extremely stable, extremely well-featured (attributes, node monitoring, growable on the fly) and works well with the preemptive and low-latency patches (of which I have both applied simultaniously).
Yes, the “official” FS for BlueOS is ReiserFS.
Why:
– works well
– stable enough (never had a loss of files with it)
– integrated in the kernel tree
– we had to choose, and it was not easy
Today, “Live queries” are not a priority, time & developpers are missing to modify the kernel to add this “feature”.
To make BFile&Co working is the first step.
But as soon we have the time, all the nice features of BFS will be “integrated”.
It would be wise to make BlueOS filesystem independant. Linux supports all of these various filesystems equally well, and different users will have different needs. Given the fact that the VFS abstracts filesystems from the rest of the system, depending on one particular filesystem would be entirely unnecessary. This is one part of the “choice” of Linux that works very well. People have the option to use whatever FS they want (based on features/stability/performance) and everything else works with that FS transparently.
that is true, however, they are not trying to make a Linux Distrobution, they are trying to make a clone of Be with the Linux Kernel. that means that they will be hacking some stuff into the kernel to support certain things. so FS independence is not that big of a deal.
Trouble is, it’s wrong. There are BeFS drivers for Linux, and they support Node monitoring through the VFS (as do most other FS drivers, not that anyone uses it)
Live queries aren’t a Linux feature, but you’d be welcome to maintain a third party patch (a la POSIX ACLs) and try to persuade people that it’s a must have for the vendor kernels (which eventually control Linus’ direction anyway).