Slashdot Mirror
IBM releases JFS to GPL
PinAngel writes "IBM has released its JFS source code for Linux to the GPL. You can read more at the IBM website. " JFS is their Journaling File System - you can grab the latest tarball from their Web site.
← Back to Stories (view on slashdot.org)
So... what? Does this mean that the JFS will now misreport your disk usage, burrow through your hard drive for nasties and send them to the editor for publication?
What's that? It's not the Journalist File System? Never mind then.
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
This is a Good Day for Linux. As soon as Big Blue gets things stable for i386, I <strong>will</strong> be changing file system types.
Glenn Stone, RHCE
Unix professional since 1986
(gee, I'm glad I bought that extra disk now!)
After reading these first few comments, I decided that the tone of quite a few of these posters scared me! "Why do we need more journaling file systems?" they said? Don't we already have ReiserFS, ext3, and of course xfs? Don't we already have some? Why can't IBM just put developers to work on a journaling file system we already have?
Well, quite frankly, I LIKE having a choice? Why doesn't everyone that works for RedHat work on making the Debian project better? Hell, why do we have so many editors, vi, vim, emacs, joe, nedit, gnotepad, ed, pico... why do all of those people have to make their own editor? Why can't they just contribute to an editor that already is there?
Er... maybe because it fits a slightly different niche and philosophy? Maybe because IBM's journaling file system handles things a little bit different then ReiserFS, and for certain applications one or the other might be better? I like choices! I like competition! This much diversity is a sign of a healthy enviroment... I say, let them write their own journaling file systems, let's get 10 or 20 more, each a little bit different, each a slight bit more focused to a certain area. Diversity is wonderful, let's nurture it.
JFS is the =ONLY= working journalling filing system from a commercial company. XFS would have been the first, but there needs to be more released (and soon) if anyone is to have much confidence in it.
Working does =NOT= mean functional or usable, though, but the development is in TRUE Open Source style, with bug-reporting and a read/write CVS repository for developers.
As for when distributions will use this - I don't expect to see any distribution use ANY of the journalling filing systems this quarter. Next quarter, we MIGHT see ReiserFS. This year, I'd expect to see ReiserFS and Ext3fs.
I'd expect to see JFS added to the next development tree, and therefore introduced into distributions in the next cycle of releases.
XFS might (or might not) come out before the year 3000. As far as kernel patches go, SGI are brilliant. As far as graphics, especially OpenGL, go, SGI is untouchable. As far as filing systems go, a concussed doormouse in a tarpit would move faster.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I work in close affiliation with IBM and every indication that I am receiving is that they are totally genuine about their open-source actions. IBM seems to be falling into a model that allows for the greatest customer satisfaction: supporting many diversified products, listening closely to customer demands, and opening up their products to the community. I would like to see more companies follow their example. In the end users will benefit the most!
Which means that if it has (say) a useful B-tree implementation, that may be usable with things completely unrelated to filesystems.
The question, at this point, is to what degree it is actually usable with Linux.
People may recall that the Mozilla source code "dump" had to take out big chunks, notably including bits of Rogue Wave libraries, RSA crypto code, and some ORB whose name escapes me. As well as (for the UNIX edition) Motif.
Is IBM JFS based on Veritas? If so, then the source code that IBM is free to release doesn't include things at the low level that will be needed. That would parallel the notion of NCC having to strip out Motif support from Mozilla, with the further issue that you can't presently get anything that is quite equivalent to Veritas on Linux.
If you're not part of the solution, you're part of the precipitate.
A hearty "thank you, way to go" and other compliments to our friends at IBM. BTW, I've heard muted rumblings that DE.. ooops, Compaq is thinking about porting AFS (which, by the way, is killer) to Linux as well. I started thinking "great, more competition, more confusion, it's going to be a while before I know which one to support, at least until one has bumped off most of the..", then it hit me. Competition, in it's best form.
A journalling file system is a really critical need for our favorite Open Source OS to be taken seriously in an enterprise setting. IBM, SGI et. al. want to be able to say "See, we initially wrote your FS, so we can suppport it best!", and get more business that way. I think that's why there are so many competing projects.
This, friends, is where a new market paradigm begins - we will decide which new FS becomes the standard on our machines, based on it's merits, not marketing. Then we end up supporting it, and by default, the company that created it. It's the new currency - knowledge, the ability to use that knowledge, and our collective mind set because of that knowledge. Welcome to the new world.
"Depression is merely anger without enthusiasm." - Anonymous
Are you talking about the Andrew File System?
If you are it's not from Compaq it's from Transarc (now owned by IBM) and was originally developed by Carngie Mellon University. There's already a beta of AFS for Linux and there should be an official version "real soon now". There's also a free AFS client implementation called Arla.
Also, AFS is a different sort of beast. It's a distributed filesystem (dfs). CMU's latest dfs -- CODA -- is based on AFS2 and a linux port is available.
SeanJFS == Journaling Filesystem
Essentially, each journaled device has an area on disk that acts as a transaction log (or Journal) which keeps track of the FS's state during normal use (basically, what inodes aren't synced). When a JFS system is hard-booted, you only need to check the inodes that weren't synced, rather than scan the entire slice. This results in much faster fsck times.
Also, IBM's JFS (from what I've read on the IBM site) will have LVM features (though apparently not the entire LVM system) which depend on the JFS to ensure data integrity when you start throwing exotic filesystem mangling routines (mirroring, Logical Devices (more interesting than concatenation), etc) into the mix..
In other words, JFS is a good thing. We like it. In fact, I'd like to be able to boot off it.
Cheers,
Your Working Boy,
Note that JFS isn't complete yet. The README says that hard and soft links do not work, you can't *write* to a JFS filesystem, reading is still in progress and it will only work on the Intel architecture due to endian problems. If you want to use a journeling file system now you should probably try ext3
Your argument is heard often, which is really scary, because it is based on the false premise of infinite developer ressources.
Think about the situation before Qt/KDE and Gtk/Gnome, where we had a dozen different GUI toolkits, all of which sucked badly, and none of which had a momentum significantly larger than the other. An application writer would have to choose one of them, and send fixes and enhancement to one that alone, helping perhaps 5% of the other application writers in the process. Today, he can one of the two main toolkits/environments, and his fixes and enhancements will help maybe 45% of the other application writers.
Of course, some choices can be justified because they provide compatibility, for example LessTif, GnuSTEP and winelib, and there should always be room for research-like projects. What is needed is one or two choices that are clearly "mainstream", and thus can be used for focusing developer energy.
For journaling file systems, the situation isn't all bad. XFS, JFS and Ext3 are all clearly needed in order to support interoperability with SGI, IBM and Ext2 systems. And ReiserFS has some very interesting application for file system based databases, which I'm really hoping will turn out good.
JFS : Mostly working, from the sounds of it.
How's that again?
The JFS README file lists the following TODO items left to go:
JFS TODO list:
- JFS:
- make READ fully operational
- READ file
- get write capabilities operational
- MKDIR
- CREATE file
- WRITE file
- RMDIR
- RM
- add support for hard and soft links, special files
That's a pretty broad definition of "mostly working." It does sound exciting, but I'm going to have to withhold judgement until file reading, writing, creation and removal have been made operational.
Just like anything else in the world from Heisenberg on up, there are tradeoffs. You don't get to have your cake and eat it too.
You want speed, you dump journalling or file systems alltogether and do raw, direct disk access. That is the fastest way to get data onto and off of the disk. It has the highest bandwidth both sustained and burst. It has the highest data density. It also is the least flexible and most prone to error.
You want reliability, and/or flexibility, you start taking care how, when, where you put your data, whether or not you do copies, add error correction codes, etc. All of this takes time, which negates speed.
Some people want speed at all cost.
Some people want reliability at all cost.
Some people are somewhere in between.
No one system is going to satisfy all of them.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
First, as someone who manages a large SP system and has run IBM workstations ever since the 320s came out, yes JFS is the business and yes, it would be really nice if IBM released the Logical Volume Manager too.
I think this is a smart and encouraging long-term move by IBM. The real money gets spent not on hardware or software but on support. IBM (and SGI) must reckon that Free Software is here to stay and if they are to make money they must be leaders in it.
Individuals and Universities are likely to use Free Software without commercial support. Companies will it some of the time but not for critical systems. By being leaders in Linux IBM will do little to harm their core sales to people who wouldn't use it anyway but will make their products the logical progression for people moving away from Linux. And maybe open up a profitable Linux support division too.
In this area GPL scores over BSD licensing because companies can release their source code without the fear that a competitor will use it in their propriety closed OS.
The good news is that all this appeals to one of the most powerful force on earth, that dubious thing called enlightened self-interest. Whilst pure altruism, from Stallman and Torvalds all the way down to any of us who have ever submitted a bug-fix to Free Software, is essential it will not change the world on its own. The combination of the two just might.
John
These filesystems are not as simple to interface in as the "Amiga filesystem" or other such stuff, as these FSes have expectations to be able to control somewhat how the kernel manages caches. They're not merely "drop in a patch and all will be well."
As a result, while I agree that it's good to have some diversity now to allow some experimentation, I am far less sure that it will be wise to have four (or more, if rumors of Compaq contribution of AdvFS code turn out to be true...) filesystems integrated in to the "official" kernel stream. There may be merit to having a couple of them, but not likely all of them.
So while I agree that it's quite OK for there to be 5 of them (and that ignores GFS, NTFS, and other stranger options that may be of less direct relevance), I think that there will be, ultimately, a need for several of the "integration projects" to fail.
Otherwise, Linus and others won't have time to fix up NFS3, improve memory management, implement ACLs, implement capabilities, implement IA-64 support, and all the other sorts of things that need to occupy some of their time.
The GUI comparison was pretty good; I agree with Per that it is a Good Thing that we have GNOME and KDE, as this is sufficient diversity to ensure that there is some competition whilst not being so much as to be completely fragmenting. It is unfortunate that this leaves some potentially good toolkits like FLTK or Tk or Amulet or Garnet or InterViews "out in the cold."
The point is that variety is useful at the point in time at which you're not sure what the results should look like.
But after that point, variety comes at the cost of having to support additional "development streams," and while there is logic to "letting the best man win," this has the side effect that if you agree with this, you have to also agree with the notion that the "not quite best men" need to be able to lose.
If you're not part of the solution, you're part of the precipitate.