Marcelo Tosatti released 2.4.20-pre4 today. Included in the bug fixes and driver updates was the merge of JFS. JFS is IBM’s journaled filesystem port from OS/2. JFS had previously been merged into the -ac tree (2.4.18pre9-ac4) and was merged into the 2.5 tree early on (2.5.6). JFS joins ext3 and reiserfs in the 2.4 tree. SGI’s XFS is still awaiting inclusion into the stable tree. Read more at KernelTrap.
I know that’s what it said at KernelTrap, but it wrong either way.
JFS ported to Linux did not come from AIX, but rather from OS/2. AIX also has a file system called JFS, but is was not ported to Linux and I doubt it ever will be.
I submited the story to kerneltrap and was mistaken. The article at kerneltrap has been updated, feel free to update my article here.
–Nate
Is it or isn’t it (already) merged to the kernel ?
JFS is faster then ext3, in my non-benchmarked based opinion (is there a shell tool to benchmark~FS on Linux ? I know a tool on FreeBSD but not on lInux).
XFS and ReiserFS are closer. ext3 is not so good (non-benchmark opinion too). Is the JFS mergeed or not ?
[I wonder why RedHat only supports the ext3 on install time ? Will it change now that JFS was merged to the kernel and available for the new (Limbo isn’t it ?) RedHat8 release ?
– I know the beta should be based on an lder kernel]
Personally, I favor XFS. It is the closest relative to BeFS, and while it is not the fastest on small files, it is the fastest on bigger ones (bigger:more than 40 KB). Sometimes, it is not about the speed anyway, you can’t quite feel the difference most of the time. It is about the features, and XFS has the most full feature-set IMHO.
Right now ext3, reiserfs3, and JFS are in the 2.4 tree. XFS is in the 2.4-ac tree. They will all be in 2.6. I am waiting for reiserfs v4 personaly. I live with two AS/400 folks, not having a unified name space is something I hear about way to much.
Do ya’ll think we will see a shakeout? In a year will we have one default?
–Nate
chicobaud, try iozone.org
😉
JFS from OS/2 is a rewrite of JFS for AIX. JFS2 for AIX is going to be a port of the OS/2 JFS. You’re getting the better JFS.
XFS is the journaled FS of my choice, and I find its possibilities rather exciting, particularly in regards to its support of extended file attributes. It would seem almost trivial to brew up something like BFS’s live queries with it; indeed, it would be very nice to see it garner more support from the community, particularly in that aspect. Does anybody know of any projects within the Linux community to actually make use of XFS’s extended attributes?
Here is an article on XFS, JFS, Ext3, and Reiserfs, all of which are included at install time for Mandrake:
http://www.mandrakeforum.com/article.php?sid=1212&lang=en
They concluded that XFS was the best choice because JFS and Reiserfs had some stability problems. I don’t know if this has changed or not. The one I chose was XFS because the results were decent, tied with Reiserfs, and the stability was like a rock.
The one thing I’m conserned about is making a boot disk. All my attempts with XFS have failed, presumibly because the driver is too big for a floppy disk. I would like to make a boot cd but I don’t know how. Anyone here know how?
Obrigado (Tanks) Fábio R.
I did download iozone.tar
I was surprised with the JFS feeling when I tried all the FS’s available on a Mandrake and on a SuSE. I’m based on my 6th sense.
That “size of files you deal with”.
This is a curious but clear and concise (and old – 1993) survey on UFS user file’s sizes (if you like to read this things)
>
http://www.base.com/gordoni/ufs93.html
Mr. Gordoni says that:
There is no such thing as an average file system. Some file systems have lots of little files. Others have a few big files. However as a mental model the notion of an average file system is invaluable.
and from results he can say average file size is (was in 1993) 22kb, if I didn’t get it wrong.
You can see that by 1993/94 the JFS/AIX was a ?journaled? FS
The BSD FFS statically allocates inodes. By default one inode is allocated for every 2K of disk space. Since an inode consumes 128 bytes this means that by default 6.25% of disk space is consumed by inodes.
but, here it’s
Clearly it is best if the file system dynamically allocate inodes; I believe AIX does this for instance.
Systems that “statically” allocate inodes should probably increase the bytes per inode ratio, but it is not clear to exactly what value. The engineer in me says `it is important to play this one conservatively: stick to 6k’, the artist goes `as Chris Torek says: aesthetics count, 8k’.
Do ya’ll think we will see a shakeout? In a year will we have one default?
Seems like with FS’s it isn’t easy to choose one default; IMHO, better to have several to choose from :-).
i can understand and appreciate choice, it is a great thing. However, i must wondery why, and i may be wrong, the kernel comes with more then 1 files system? its similar to a distro providing both konq and mozilla. maybe i have missed the point, but you only need 1 of everything, doesn’t more just add bloat(if even only a little)…. or is the philosiphy, give the kernel everything and let the user pick and choose, which isn’t all that bad of an idea.
Every distro I know of includes both Konqueror and Mozilla.
As for filesystems, you obviously have never heard of a little thing called “modules”. Also, please readup on these filesystems. Because if you do you will learn there is a reason to pick each of them.
There is almost no downside to having all these different filesystems. They are totally modularized (well except XFS) so compiling them all adds just some disk space requirements (maybe a meg or two). More features do not necessarily mean more bloat. If the system is extendible and modular, more features simply mean a little more used disk space, with the actual bloat dependent on the number of features you use at any given moment. Of course, since all these filesystems share the same interface (the POSIX file I/O API) they’re almost completely plug-in replacements for one another (the exception is XFS and its support of attributes and ACLs). Unlike multiple GUI toolkits (which is an idea I’m not terribly fond of) multiple filesystems don’t fragment the application base, because they’re all completely compatible.
Eugenia: Personally, I favor XFS. It is the closest relative to BeFS
Yet, XFS is too unstable as of now. I would stick to ReiserFS or ext3 on my main partitions. So give it time to be merged into the stable tree :-p
Im pretty sure a boot disk would have to be made in ext2. I don’t think the new journaled FSes work for that yet. Great for a hard drive though. I see some disagreement on the stability of ReiserFS vs. XFS… Id like to see what more people think on that one. I use Reiser at the moment but have been thinking of a complete reinstall latly and I may want to try XFS this time.
What I meant by boot disk is not one that has XFS on it but one that can boot a root filesystem formatted with XFS. The kernel module for XFS is large I’ve heard and prohivitive to making a floppy boot disk. That I why I want to know about cdrom boot disks. So far I have found out how to make one using El Torito but I don’t know how to make a boot image. It has to be the size of floppy disk (either 2.8 or 1.5 or 700KB).
FYI Boot disks don’t even have to have a filesystem but can be put on raw to save space.
If you want a boot disk and are worried about corruption on the root file system just handle this through partitions.
Set /tmp to symlink to /var/tmp.
/root sym to /home/root (if you really need /root and can’t get /home up then it still there just for everyday use).
If you don’t change /usr much you can leave it otherwise give it its own partition or sym to something like /home/usr; with /home on its own partition.
give /var its own partition and put the data for the database you are worried about on /var. 90% of the reason you’ll want journaling on any other partition goes away.
So in a simple setup you end up with:
/ — very rarely written to
/home — frequent written to
/var — constantly written to
swap — doesn’t matter.
Just my $.02
To give the user/system administrator a choice.
The fact is, you probably cant make a filesystem that does
everything good/fast and with all features everyone needs.
Remember, there are not just desktop users. There are people
that needs to store many many gigabytes large files. There are
people that needs to store millions of small files,some requires this features, but dont want to pay the cost of that feature(which they never need) and so on.
And, isnt it nice that linux can read your old fat32 filesystem? Or your BeFS partition?
I have used XFS since kernel 2.4.0 and haven’t had
any issue, save some deletion bug in 2.4.3 (I think).
Since it’s ported from Irix, it’s a well tested
technology.
Boot/rescue floppies can be downloaded from
ftp://ftp.astro.umn.edu/pub/users/carde/linux-xfs-disks/
(It’s 2.4.18)
/peder
I use XFS for all my linux boxes. The file server had many power-offs, no problem for XFS.
One day i accidently killed my partition table and the first few kilobytes of my XFS partition on my development box.
XFS recovery worked great, i was able to recover everything but the overwritten parts.
So I’ll stick with XFS until OpenBeOS is usable…
Casper