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)
I really would love to see Deian and the kernel fully support this. Might be a little better than what we have.
Slashdot social engineering at it's finest
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
I wonder which UNIX vendor-contributed FS will make it into distributions first: AIX or XFS.
Can anyone explain differences/advantages/disadvantages of the two filesystems, and perhaps how they compare to some of the other solutions (ReiserFS, ext3)?
New XFMail home page
A non journaling file system was all that we had going for us with linux.
I'll bet that the file system it frickin complicated now, and I won't be able to edit the inodes by hand with magnets anymore.
Before half of us go out and snag a copy, realize that this is oh so very pre-alpha! Serious developers only! You can't do anything more than primitive read operations from an existing JFS partition! Granted, they have a marginally functional mkfs, but what good is a filesystem you can't write to?
At lease it is good to see IBM is keeping their promises, and following the credo 'Release early and often'. (In this case, VERY EARLY).
.sig: Now legally binding!
http://www-4.ibm.com/softw are/developer/library/jfs.html
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!)
Of course (and despite media rumours) Linux isn't the center of the universe. How does this release under GPL affect the chances of the other open OS's such as FreeBSD adopting this? Is it possible to include something this low level which is GPLed into the core of something licensed under the BSD licence? (I have a nasty feeling I may provoke a license flamewar here...)
Colin Scott
Colin Scott If you build it, they will be dumb...
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
I've used JFS on AIX, and I have to say that it is probably one of the best parts of AIX. You can drop the power on an AIX box when it is right in the middle of running code that is reading and writing the drive and when it is powered back on, it will complete its journal rollbacks (which is what it does instead of fscks) in just a few seconds versus potentially a couple of minutes for fsck on a large volume. Another nice thing is that you can dynamically change the sizes of partitions in a more flexible manner than what we are used to with file systems like ext2.
I'd say it should certainly be an option. It will be interesting to see how it compares in a Linux implementation as compared to SGI's XFS from Irix, and also with ext3. There is also at least one other independant journaling file system being developed for Linux, but I can't remember what it is called off the top of my head. I think the next generation of Linux file systems beyond those will really be impressive if it can combine the best attributes of those.
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,
In short, it is very cool. It is much better that the crap Sun gives us by default, and while I don't know much about SGI's XFS, my impression of SGI's has generally been that they suck and are slow.
Time to buy some IBM stock (anyone taking bets on whether IBM swallows redhat?)
-- Slashdot sucks.
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.
What *is* interesting though, and very promising is that they've chosen to release it under the GPL. Of course under any other licence it would have been useless since it's kernel-level and the kernel *is* GPL. But it's a nice move away from the YAL (Yet Another Licence) syndrome that's been plagueing the first careful steps towards Open Source... wanting to reap benefit of the new paradigm, but not really daring to let go.
Hopefully more will follow in this direction.
-- Eythain
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.
So, while we "may" have lots of journaling file systems someday, there's only one contender for 2.4.x, and only 3 actual public code bases. There are, at last count triple digits of window managers
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
File system support is a very touchy area for most, but few see the real potential, and why we need so many file systems supported in Linux.
Just think if you had a box in the office, that if any one of your big iron machines (IBM, SGI, Compaq, etc) decided to up and fail, you could just plug the drive into, and get at your data immediately to get things done. Granted it might not be as fast as the traditional system that you use for every day operations, but this is an "emergency backup". You live with reduced performance instead of no performance at all.
I can see Linux becoming that box. That all purpose box of tricks that a System Administrator can use to his disposal. It's already there in the network doing just that job, and gaining ground. There is a lot more this little system can do that even the big irons can't compete with. And if we want Linux to be the best... *grin*
As for kernel support, all that the many systems will do is provide a very decent API system for passing data to/from the kernel for these Journalling/High Performance systems. Sure everyone does the final product differently, but if the kernel can output a generic, yet fast method for all the file systems to use, then we gain some instant advantages. Firstly we can run all these systems, which is a must, but secondly it opens up an interface that can be exploited by a newly developed system to the max, giving us the best performance possible.
This is not going to be easy, and as people improve their programming techniques and new people get into the kernel code, there is bound to be new revisions, and mebbe even total rewrites. Just look at the networking code. Major revamps by dedicated people have produced now a significantly faster network layer. True a lot of it got re-written, but that is the price you pay for progress.
So instead of bitching about it, lets just let them get on with the job of doing it, and where possible help out. When they make mistakes, don't abuse, just give them a prod in the right direction.
--- Every decision is right, it's just a matter of whose right we are refering to.