Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
IBM

IBM releases JFS to GPL 202

Posted by Hemos from the letting-it-be-free dept.
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.
This discussion has been archived. No new comments can be posted.

IBM releases JFS to GPL More

IBM releases JFS to GPL

Comments Filter:
  • I really would love to see Deian and the kernel fully support this. Might be a little better than what we have.

  • To those that say "show me the code"... IBM is showing us the code. I think they should be commended for their obvious support of Open Source (free) software.

    Anyonw know how good the JFS is? Should we use it?


    If you can't figure out how to mail me, don't.
  • and fast... at least, that's what the people who run Warp Server are saying...

    Looks like JFS can be ported over to the client, too, now...


    +----------------------------------------------- -------

  • Journalist file system (Score:5)

    by JustShootMe ( 122551 ) <rmiller@duskglow.com> on Thursday February 03, 2000 @06:45AM (#1308477) Homepage Journal

    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.
  • I've seen a lot of stuff go by about journelling file systems and understand the theory/needs. Can someone in the know do a comparison between the various ones out in the marketplace (*nix in general, commercial and other) and how the IBM system stacks up? Is there a review/FAQ available that compares the product in the market niche?
  • Just to be greedy, can we have LVM too?

  • I begin to wonder how many journaling file systems we will have in the end, ext3, ReiserFS, XFS, JFS now.

    Hey we soon will have more journaling file systems than window managers!
  • I haven't used AIX much, so I don't know that much about JFS, but I do know that many other regard it as an excellent file system. IBM was, last I heard, porting JFS to OS/2, so that it would finally have a journalling, secure file system (HPFS, while a decent FS for a single-user system, lacked any kind of built-in security as well as journalling).

    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 [slappy.org]

  • YAJFS (Score:2)

    by tono ( 38883 )
    How many journalling filesystems does linux really need? I realize that after the Microsquish FUD wars, it came to the attention of linux developers that we needed a jfs, but this is rediculous. We need one good jfs, ONE not 4 or 5. While I am happy IBM decided to contribute their hard work to the linux movement, I would rather they contribute developers to make one of the options we currently have as stable and fast as possible. Just my thoughts on the matter though.

  • Those bastards. (Score:3)

    by Anonymous Coward on Thursday February 03, 2000 @06:47AM (#1308483)
    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.
  • > Anyonw know how good the JFS is? Should we use it?

    I'm not 100% sure where the jfs stops and lvm starts, but you can do some really incredible things with aix boxes.

    For example I once moved actively paging paging space from a drive that was logging errors to a new drive without shutting down, having other people log off, or anything, it just worked.
  • Though it's great news that the corporate world is embracing free software, it's important to note that this is a pre-alpha release. It barely reads. About all you can do right now is mkfs, mount/unmount, and ls. So no, I don't think Debian will be intergrating this into their kernel yet. :)

    --GnrcMan--

  • Whoa! (Score:3)

    by technos ( 73414 ) on Thursday February 03, 2000 @06:52AM (#1308487) Homepage Journal
    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).

  • Details of IBM JFS (Score:3)

    by psmith ( 11508 ) on Thursday February 03, 2000 @06:52AM (#1308488)
    Well, here's a paper discussing technical detailse details of JFS on IBM's oss site:

    http://www-4.ibm.com/softw are/developer/library/jfs.html [ibm.com]

  • Re:IBM gets it. (Score:4)

    by warpeightbot ( 19472 ) on Thursday February 03, 2000 @06:53AM (#1308489) Homepage
    <blockquote><em>Anyonw know how good the JFS is? Should we use it? </em></blockquote>The IBM JFS as I knew it back in 1990-4 was built like the proverbial brick outhouse. I think in four years of Atlanta summers and their persistient power flickers and outages I lost maybe one file, thanks to the journalling feature.... most of the time the system had already written to journal and didn't even know it hadn't been unmounted cleanly (including one spectacular instance where the power switch on an RS/6000-320 fell victim to a visiting toddler... the boss hadn't been doing anything on the box for a few minutes, and despite his screen being full of X sessions, when I brought it back up, everything was intact; it didn't even bother running fsck. I did, twice, just to make sure. Zero errors).

    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!)

  • I've done the same thing with Digital Unix (now Tru64 :P) and their LVM. It's quite impressive to watch. I hope that part is being ported or will be ported soon. That would be a major improvement for fault-tolerance.

    Swapping disk drives without the user even knowing. Now THAT'S impressive.


    If you can't figure out how to mail me, don't.

  • Timeframe (Score:3)

    by colinscott ( 8989 ) on Thursday February 03, 2000 @06:54AM (#1308491) Homepage
    What kind of timeframe would we be looking at for this to be available? I'd find it unlikely that this would go into 2.3 at tbhis stage, but what's the likelyhood of a patch for 2.4 being available. And will it be included in 2.5? Journaling file systems are at the top of my list of things I'd like to see in major distributions right 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

  • Choices? (Score:5)

    by ilkahn ( 6642 ) on Thursday February 03, 2000 @06:54AM (#1308492) Homepage
    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.

  • Wow. Count me as a potential convert too. Ext2 is cool but it's not quite a workhorse.

    Does JFS support file attributes (such as immutable or append-only) like ext2 does?


    If you can't figure out how to mail me, don't.

  • Re:I think this is a good thing (Score:3)

    by Anonymous Coward on Thursday February 03, 2000 @06:59AM (#1308495)
    Not speaking for IBM... #include I'm also not a JFS expert.

    As I understand it, there are 2 or 3 varieties of JFS. There are at least two but their might be three. The big difference between the 2 JFSs is max filesize. Standard JFS on a 32bit PowerPC or POWERx chip supports a 2G max filesize. There is a patch that will kick it up to the full 32bit int 4G limit.

    I believe there is a big file version, in fact I'm positive there is because we routinely have to deal with cusomters who transfer 8G files from MVS to AIX. I'm not sure if that requires a 64bit PowerPC or POWERx chip to run the big file version or not.

    That being said, a possible difference is the file size limitations between XFS and JFS. I think they are both very similar in a lot of other respects. XFS provides a promised performance level, JFS probably promises a critical level of data integrity (at IBM you absolutely cannot lose a single bit of a customers data, under any circumstances other than castastrophic hardware failure and even then every attempt is made to save it) I think they are both variants of the Veritas filesystem, but I could be wrong. Anyways, both xfs and jfs are top notch filesystems.

    There may be some differences in what is put in the log, logging of only meta data isn't that unusual.

    As for Reiser and Ext3. Ext3 suffers from Ext2's native int size as a limit of filesize. I'm not sure about Reiserfs, I understand they are working on 64bit support on 32bit machines. As I understand it, both ReiserFS and Ext2/3 are "light weight" compared to JFS and XFS, not in a bad way but they are simple lean and mean but I believe that XFS and JFS go to great pains to provide extra services that are outside the realm of what ext2 and reiserfs intend to provide. JFS uses a btree, reiserfs does also. I'm pretty sure xfs does, ext2/3 doesn't.

  • Here's a brief summary of what's out there, and how I think JFS is fitting into this picture:

    • ReiserFS-journalling : Supports metadata journalling only. Reiserfs' performance is superior to most other filing systems out there.
    • Ext3fs : Supports metadata journalling only? Ext3fs is Ext2fs + journalling, so is essentially compatiable.
    • XFS : Only partially released. Impossible to say what XFS for Linux will actually do, or how well it'll work.
    • JFS : Mostly working, from the sounds of it. The TODO lists logging as incomplete. Nothing on the web pages as to what type of logging is done, but I'm going to guess it's full journalling.

    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.

  • Go FTP it PDQ, or be SOL.

    Just had to keep the TLA's going...

    ---------------------
  • It is great that the software has been GPLed, but that only means that me, john doe linux enthusiast, who can rebuild his machine every day for fun can try it out and play with it. GPL software inherently comes without any guarantees. IBM figured that anybody in the business world choosing between two distribs - one with the GPL filesystem and no warranty/support and another from IBM of the exact same software + implicit warranty would buy the IBM product.

    Business entities have little incentive to use GPL products while there inhouse IT staff are not linux experts (and this is generally the case). Also, IT system maintenance folks in NT environments "like to get on the phone with the vendor" for most problems and are generally not code-oriented people.

    Can your sysadmin code?

  • IBM should be applauded for not inventing and using another one of those pseudo-opensource licenses like Sun's SCSL. This gives a much needed boost to the GNU license and other large companies wanting to take the opensource route should pay particular attention.

    Note to Bob Metcalfe and the likes: should the largest computer company in the world be treated as a communist symphatizer now?

  • Just yesterday we had an article [slashdot.org] right here on Slashdot talking about a speech Linus gave mentioning the various efforts to bring a journaling file system to Linux. I don't know whether that article may have prompted IBM to put their code up for everyone to have a look or not. It may just be a coincidence. Either way, I tip my hat to them. Thanks, IBM.
  • JFS is a great filesystem. It is probably one of the few great features of AIX. You have to hand it to IBM. They are showing big signs that they truly understand open source. I hope SUN is watching. Granted all this is pre-alpha but it is GPL and the code is out there. Just think next year reiserfs, xfs, ext3, and jfs. Is this the begining of the reunification of UNIX? Matt
  • I heartily agree.

    What's happening, I think, is that every subsystem of Linux is going through a brutal natural selection process. In some cases, one technology emerges as the de facto standard. In other cases, similar technologies serve different markets.

    --

  • huh? (Score:1)

    by teepee ( 47012 )
    Uh, what's wrong with choices? Isn't that part of what all of this is about? Maybe IBM's JFS isn't the fastest, but it has a higher chance of avoiding corruption on a poweroff or crash. Maybe ext3 will be faster, but has other problems. If we have choices, we can choose what is important to our own work, at the current time. Limitting choice is bad, m'kay?

    Plus, I'm sure whatever additions/improvements that end up in JFS from open source developers will end up back in AIX's code base. There's no motivation for IBM to take developers off of a solid, reliable, proven project and move them to an experimental open source project where they'll have to reinvent the wheel. Sounds like a waste of everyone's time.
  • Okay then... Lets put your little pizza box up against this here IBM and see who can cut the mustard. Hell, I'll let you use a brand new Ultra and I'll still trash you with equipment from 1997.. I betcha I have a thousand times the IO bandwidth of that puny Sun! Oh, yeah.. Did I mention it's a ES/9000?

    Why is it some pompous little cretins never get the 'pick the platform right for your application' credo? For crushing twits, a 30,000 pound 9x2 sounds about right. Imagine the squish!

  • True Blue Big Blue (Score:5)

    by nullspace ( 11532 ) on Thursday February 03, 2000 @07:08AM (#1308506)
    It is very encouraging to see IBM donate their products to the community. It is also very encouraging to see that they release it under the GPL. It is very important to keep new products under the GPL since it is the more accepted license and allows for the greatest benefit to the user and those who wish to enhance the product.

    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!

  • Being GPLed, it's fair game to take components of it and join them with other GPLed code.

    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.

    • If it's merely a "source code dump" of the AIX code base, that's not immediately useful.
    • If it's a Linux kernel patch, that would be rather cool.
    • I wouldn't find it surprising if actually using it would require adding in components that aren't there.

      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.

  • So, the companies that are using Linux, and have iron-clad support contracts with third party support providers, like, say, Linux Care, are going to scoff at the notion when LinuxCare also say 'BTW, we've stamped version 1.2.1 of JFS to be solid, and we're willing to write that into our support contract'?

    Linux is slowly coming to equal Solaris in terms of honest-to-Gods enterprise features. And I'm talking the simple stuff, like being able to fsck a mounted drive, or change shm_max type params without recompiling your kernel. When things like that are in place, you'll see a lot of shops moving over to Linux.

  • The new currency in an Open Source World (Score:5)

    by Soko ( 17987 ) on Thursday February 03, 2000 @07:11AM (#1308510) Homepage
    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.
  • Stuff like moving around paging is LVM. You're moving a logical volume, that lv can contain different things like JFS or paging.

    I'm really hoping they'll port the whole LVM at some point. One of the things I like most about AIX is the LVM -- being able to do stuff like increase the size of the live filesystem is wonderful (that's sort of a LVM/JFS tag team).

  • Re:Journalling File Systems for Linux (Score:3)

    by Ticker ( 79929 ) on Thursday February 03, 2000 @07:17AM (#1308512) Homepage
    I'm a user of ReiserFS and I'm in love with it. It *is* metadata logging only right now, but that's good enough for most non-enterprise purposes.

    It's faster than ext2 too. It uses a b*tree and small files are packed together (less wasted space).

    For my purposes, I'm very happy using the ReiserFS devel over the ext2 release. Especially since I have lost several entire partitions with ext2.

  • Re:IBM gets it. (Score:3)

    by SoftwareJanitor ( 15983 ) on Thursday February 03, 2000 @07:22AM (#1308513)
    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.

  • Forgive me for being EE instead of CS, but how does a journaling file system differ from a regular file system? Why should I use it?

  • Re:huh? (Score:1)

    by tono ( 38883 )
    Choices are fine, I love choices. I'm just saying why not try to make one of them both corruption resistant AND fast. Granted I'm not a filesystem hacker but it seems to me like in the need for choices we sacrifice some quality. We wouldn't necessarily need 4 different choices if one of them was bullet proof and fast. Just my thoughts.
  • Last I heard that was a technology from our "friends" the Open Group. HP and IBM licensed there proprietary code and used it as there LVM. I think they would definately have issues with IBM opening up that code. Given that the lvm code base that already exists for linux has the same functionality, and even uses the same ideas of volume groups and logical volumes (hell even the same naming conventions for files). I wouldn't be surprised if we hear about a law suit about it in the near future.
    :-(
  • Here here! One excellent point of the Open Source movement is that as an ecology, it is not homogenous. Give us choices!

    However, i would also like to add that 3 or 4 solid options are better than 100 crappy options. KDe and GNOME, for instance: i have no problem with 2, or maybe a third if it is obviously technically superior. But to have a million choices, none of which stack up sucks.
  • The chip doesn't actually matter, whether it's 32 bit or 64 bit, the filesystems in AIX have the same limit. In AIX 4.2, the maximum size of a file was increased from 2 Gbytes to 64 Gbytes. This doe pale against some of the competing operating systems but I've not yet had a commercial customer complain. I've known some scientific customers who have hit the limit. And it probably is a good thing that Linux will access to some very good implementatons of journalled file-systems and a least a couple that have proved themselves over the years in some commercial environments.
  • Are you referring to the AdvFS? That thing gives me a proverbial woody. I would pay good money to be able to use AdvFS on my Linux boxen, and would personally lick the boots of Compaq's management if they open-sourced it.

    Of course, I'm not sure it actually belongs to Compaq...I seem to recall that Digital licensed it from another company that initially developed it, and this was clearly stated in the DU4.0 man pages... but perusing the Tru64 5.0 man page, I don't see any references, so it may be they actually own it now...((drool))...

  • Re:Pretty Cool; Hopefully some useful ideas (Score:5)

    by Mr Shark ( 18717 ) on Thursday February 03, 2000 @08:00AM (#1308522)
    I just downloaded the code and have had a quick look at it. It seems to contain
    • a dump of the AIX/OS2 code (or something close to it) as a reference implementation (also GPL)
    • a first grab at a "kernel patch" (its a tar ball that unpacks over the 2.2.12 tree).
    • directory containing source code for some utilities and something that looks like the implementation under os2 (#include :-) as a reference
    • Not much documentation except for the reference implementation, but then again code is the ultimate technical documentation:-)

    I would say that the only thing missing is something like the README on the web page in Documentation/fs/jfs.txt (hint, hint)

    Joy, JFS is a good fs, during the two years now that I have been working with AIX I have had one fs corruption, and that was fixed when we fastened the SCSI-1 cable

  • AFS (Do you mean the Andrew File System?) (Score:4)

    by Seanasy ( 21730 ) on Thursday February 03, 2000 @08:05AM (#1308523)
    I've heard muted rumblings that DE.. ooops, Compaq is thinking about porting AFS (which, by the way, is killer) to Linux as well.

    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 [cmu.edu]. There's already a beta of AFS for Linux and there should be an official version "real soon now" [transarc.com]. There's also a free AFS client implementation called Arla [snoopy.net].

    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 [cmu.edu].

    Sean
  • I spoke too soon. SGI have released another XFS tarball, bringing their code (according to them) up to 50% of completion. So, just one more year to go, before they're at the same point IBM are now.
  • I haven't used it, but it should be a reasonably well-developed technology. I understand that it was released in OS/2 5.0 last spring. If so, it's probably the most mature journalistic filesystem for Linux.

    - Bruce Byfield, Product Development, Stormix Technologies
  • You wait all year for a journalling filesystem and then three come at once.

  • Re:What is a JFS? How is it different? (Score:4)

    by otis wildflower ( 4889 ) on Thursday February 03, 2000 @08:17AM (#1308528) Homepage
    JFS == 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,

  • This is great (Score:3)

    by Amphigory ( 2375 ) on Thursday February 03, 2000 @08:21AM (#1308530) Homepage
    As someone who's administered quite a few RS/6000's, let me comment: JFS rocks. I repeat, JFS rocks. I have /never/ seen lost data from it (including hazardous environments with flakey power). It is fast, efficient. Reboots take minutes instead of hours. It works great as a substrate for large database files.

    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?)

  • I don't know about AIX, but the LVM used in IBM's OS/2 was written from the ground up and is an entirely new design. I was told by the guy who designed it that the version of LVM that was released in OS/2 is just a subset of what he designed due to budget and manpower restrictions. If IBM can't release the AIX LVM, then maybe they could release the OS/2 LVM, and the community could complete the full design!
  • JFS is not a Veritas derivative.

    In fact, no Veritas products are available on AIX, IIRC.
  • I'm running 2.2.15pre5 right now.. and the JFS breaks NFS.. it gets a conflicting types for 'buffermem'... DOH!

    Since I'm a perl hacker, and not a c hacker... this is not quite an easy fix for me..
    anyone out there got a fix... (besides turning off NFS)

    ChiefArcher

  • Yeah, they do seem to get the idea.

    I remember, about a decade ago, when IBM were the corporation for geeks to hate. Then Apple pulled their stupid patent case concerning the mouse, and took over that posistion breifly. Finally, in the early nineties, everybody suddenly noticed Microsoft, and just how scummy they were.

    IBM, after their many year long anti-trust case, seem to have reformed. They are giving the code away, not under their own license, but under the one and only GPL. They can't claim it back. That shows a lot of understanding, and the will to play this game on our terms.

    The hope here, is that now Chairman Bill is out of the hotseat at Microsoft, the other people with power there will follow the example of IBM, and clean up their act.

    OK, a lot off topic, but I don't know anything at all about journaling file systems, except from the phrase "they're cool and we want one" being bandied about the office...

  • Hey, check out my web page: http://www.skylab.org/~sabre/os/ [skylab.org]

    It talks about different OS interfaces, and has a very thorough section on filesystems available under linux, including several other JFS's...

    -Chris

  • what's wrong with diversity?

    maybe possible maintenance problems - of course this is alleviated by having common interfaces.
  • What did IBM do?

  • Too many choices are bad (Score:5)

    by Per Abrahamsen ( 1397 ) on Thursday February 03, 2000 @08:41AM (#1308543) Homepage
    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.
  • [ksparger@vaevictis ~]$ tar -zxvf jfs-0.0.1.tar.gz
    linux-2.2.12/Documentation/
    linux-2.2.12/Documentation/filesystems/
    linux-2.2.12/Documentation/filesystems/00-INDEX
    linux-2.2.12/Documentation/filesystems/jfs.txt
    linux-2.2.12/Documentation/Configure.help
    linux-2.2.12/arch/
    linux-2.2.12/arch/i386/
    linux-2.2.12/arch/i386/defconfig
    linux-2.2.12/fs/
    linux-2.2.12/fs/jfs/
    linux-2.2.12/fs/jfs/ref/
    linux-2.2.12/fs/jfs/ref/dprintf.c
    linux-2.2.12/fs/jfs/ref/fs_ioctl.c
    linux-2.2.12/fs/jfs/ref/jfs_acl.c
    linux-2.2.12/fs/jfs/ref/jfs_bufmgr.c
    linux-2.2.12/fs/jfs/ref/jfs_cachemgr.c
    linux-2.2.12/fs/jfs/ref/jfs_chkdsk.c
    linux-2.2.12/fs/jfs/ref/jfs_close.c
    linux-2.2.12/fs/jfs/ref/jfs_clrbblks.c
    linux-2.2.12/fs/jfs/ref/jfs_create.c
    linux-2.2.12/fs/jfs/ref/jfs_dasdlim.c
    linux-2.2.12/fs/jfs/ref/jfs_debug.c
    linux-2.2.12/fs/jfs/ref/jfs_defragfs.c

    etc, etc, etc

    Looks like a "patch" of some kind to me.
  • Does JFS support file attributes

    Hey, if it doesn't -- add 'em!

  • What IBM gets. (Score:3)

    by Eythain ( 120617 ) on Thursday February 03, 2000 @08:48AM (#1308546)
    I don't know much about... well, JFS for one thing. It would certainly be nice to get a journaling file system into the 2.4 kernel, but that might happen anyways.

    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

  • I believe Veritas just annouced full support for thier backup software and other product on linux to be coming out very soon.
  • it might be included optionally. the BSDs could distribute a GPLed jfs as an add-on like they do now (as in the ports directory). however, because of the license issues, i seriously doubt it could ever be the default fs.
  • Your argument is heard often, which is really scary, because it is based on the false premise of infinite developer ressources.
    The reason we don't have infinite choices is due to the lack of developer resources. The free market will determine which projects succeed and fail as it has always done. No amount of hot air will change the process.
  • Of course we all know the reason why IBM is porting JFS to Linux. Remember a little while back IBM stated that they are planning on supporting Linux on all of there hardware, well if you want people to switch there RS/6000's from AIX to Linux you had damn well better be able to read filesystems that AIX wrote. Now the big question is will IBM also port there Logical Volume Manager to Linux? Also will there be a port of SMIT(ibm's system management tool, which btw is very nice).
    I know I'd be using JFS and there LVM on any mission critical system I had...

  • From what I've read, JFS for AIX is insanely scalable and a good performer on the high-end. IBM also ported their JFS to OS/2 Warp, and made some adjustments to have it perform very well on lower end systems (and non servers) as well.

    To me, these sound like the ingredients needed for a main Linux FS (good on high and low end). Of course, JFS is NOT designed for small file systems (a la floppy disks, misc. removables), so it couldn't replace everything.

    This is great news.
  • This is great news! A Journaling File System is what Linux needs to push enterprise acceptance. With some recent power problems in my apartment, a JFS is exactly what I need too (that, and the APC UPS I recently bought).

    But, with several alternatives it would be nice to see a full analysis done of each of them, and an ongoing tracker of the current state of each. This would be a great article for Linux World, or one of the other Linux peridicals.

  • I hope SUN is watching.

    Apparently they are. Check this article, Sun releases NFS as open source [vnunet.com], or this one, Sun loosens its grip on NFS [infoworld.com]. Alas, it looks like it's going to be released under YAWSL (Yet Another Wacky Sun License), but it's apparently only for the Transport Independent Remote Procedure Call (TI-RPC) protocol.

    JimD

  • When I was in college (about 4 years ago) this was the official way to shut down the AIX workstations:
    1. Log out
    2. Give the machine a few seconds to sync
    3. Turn off the power
    Root? We don't need no stinking root!

  • mostly working, except for file management (Score:4)

    by Tim Pierce ( 19033 ) on Thursday February 03, 2000 @09:24AM (#1308559)
    JFS : Mostly working, from the sounds of it.

    How's that again?

    The JFS README file [ibm.com] 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.

  • tradeoffs (Score:4)

    by marcus ( 1916 ) on Thursday February 03, 2000 @09:25AM (#1308560) Journal
    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.
  • You are right about the fact there are finite Developer resources. Which is why you can never have too many choices.

    Journaling file systems are in their infance for the linux kernel. So we need to explore as many possibilities as possible. And because there are only finite developer resources, only the best ones will survive. It's called survival of the fitest and thats how the open source movement works.

    After all just think if there were only one journaling filesystem. Ever heard of the saying "too many cooks spoil the broth" ? So you have lots of people with different philosophies working on this single choice that you have. The results can only be horrifying. Just look at the BSD projects for an example. They have a great product, and they started with a single code base, but philosophical goals differed and eventually they evloved into many different varients. After much bad feelings is what I get from various conversations that I have followed on mailing lists and news groups.

    This is the reason that you have very few people working on the linux kernel itself, and only one who decides what goes in. His philosophy decides where the linux kernel goes. If you don't like this, work on something else. Like the hurd. Eventually the better/more practical philosophy will win. And there dosen't have to be a single winner even. Many can win. And although people will flame me for this, the opensource philosophy has already proven to be the better and more praticle way of developing the support infrastructure software. And it's winning. And there are many winners. Like GPL, lGPL, BSD, artistic, NPL etc. Even in these, the better ones will survive, and others will evolve to take on the good things from their betters.

    Besides, with all these codebases released under GPL/compatible licenses, you have the option of borrowing from each other to make a better product. And you have something to compare your product with. After all how would you know that there isn't a better way of doing things, if they were always done only one way and you've never even seen/thought about another?

    So you see variaty is the mother of evolution. Choice is good and let the best man win.
  • You point out the problems of too much diversity pretty well, but I think they are mainly short term.

    When diversity starts to cause problems (e.g. GUI toolkits) then it creates an automatic need to improve interoperability. Hence there is a movement towards standardisation, drawing from the best features of the existing options.

    I see the development of open source technology following something of a four stage process:

    Pioneer -> Diversity -> Consolidation -> Maturity

    It's an evolutionary model where the problems of the chaotic period eventually pay off by contributing to the base of code and experience that is needed for a mature open standard.

    Whoa.

    I've just written a pile of pseudo-scientific bullshit. I think I better stop now......
  • (anyone taking bets on whether IBM swallows redhat?)

    Sure, I'll take odds against you on that one. Red Hat does not own much in the way of proprietary technology. It does have a lot of developers, but IBM has more. Sure it would generate a lot of buzz, but most of it would probably be negative in the Linux community, and Wall Street would ask whether Red Hat's really worth the money.

    Buying Red Hat is the way Microsoft deals with competition in a closed-source world. IBM can do everything Red Hat does in-house, and a whole lot more.

    -cwk.

  • Re:The real reason why IBM is doing this... (Score:3)

    by Eric Smith ( 4379 ) on Thursday February 03, 2000 @09:39AM (#1308567) Homepage Journal
    Under AIX, all available memory that is normally free memory under other unixes, gets allocated to buffer cache for all filesystems on the box.
    Which is, of course, also how things are currently done in Linux. It's a better approach than the traditional fixed size cache, but your proposal to allow per-filesystem limits seems like a good idea to me. In fact, I've had some situations where I would have liked a per-file limit, so one disk-intensive application didn't throw everything else out of the buffer cache.

  • Enlightened self interest and the GPL (Score:4)

    by john rowe ( 126605 ) on Thursday February 03, 2000 @09:40AM (#1308568)
    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
  • If it is a port from AIX, it'll rock! JFS under AIX was the best part of the OS IMHO. Dynamic resizing for partitions, fast accurate recover after power outages! Now if IBM would only port SMIT, so we have a fantastic usable admin manager, life would be sweat.
  • When you start an open-source project, there is a very crucial first-step in which the basis of the project is created by a certain minimum core of developers. After this the project has the foundation required to attract and support new developers and developments.

    I think your argument is not exactly sound. If not enough developer mass is gained within this crucial first stage, then the project stagnates. To extrapolate, if many similar projects are started and concurrently compete with each other for developers at an early stage (in which none of them are well-defined) they will stunt each other and not be able to attract any substantive amount of developers, and it will be very hard to escape the stagnation. Eventually developers will get tired and bored and go away (not necessarily to other projects either).

    Jazilla.org - the Java Mozilla [sourceforge.net]
  • "Pioneer -> Diversity -> Consolidation -> Maturity"

    And that is how you develop excellently implemented but outdated technology. Don't flame, I'm not being a troll...but the path you cite takes /time/. According to this path, a Cathedral model would just start after the consolidation stage and finish faster (although it might be crappier code). This is a problem then...if you allow things to be too chaotic too early you end up with a /really/ long path like this, while all the Cathedral-goers will have already invented and implemented many new things.

    It's obvious that /too/ much diversity in the face of scarce developer resources is bad. There are no absolutes...this isn't an issue of the Bazaar being "absolutely" better than the "cathedral", because "diversity is categorically better under all circumstances".

    We should be more conscious of splintering and further fractioning developer resources, and stop being so arrogant as to think that spawning hundreds of identical projects isn't really going to hurt us. According to the path you describe, it will, because the consolidation period will be very long, at which point the Cathedral has just got a head start on us.

    Jazilla.org - the Java Mozilla [sourceforge.net]
  • JFS : Mostly working, from the sounds of it. The TODO lists logging as incomplete. Nothing on the web pages as to what type of logging is done, but I'm going to guess it's full journalling.

    Gleaned from http://www-4.ibm.com/softw are/developer/library/jfs.html [ibm.com]: JFS only logs operations on meta-data, for data consistency consider using syncronous I/O.

    That having been said, JFS is about as bullet-proof of a filesystem as I have ever used. This is a good thing.

  • At some point, whatever journalling "options" get officially supported will require some attention by the "senior kernel folk," whether that be Linus, Alan Cox, or (fairly likely!) Stephen Tweedy.

    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 [gnome.org] and KDE, [kde.org] 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 [fltk.org] 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.

  • Re:Journaling FS's and Window managers (Score:3)

    by Inoshiro ( 71693 ) on Thursday February 03, 2000 @10:56AM (#1308587) Homepage
    Ahh, but let's see what we will actually get:
    • Ext3 -- Still pre-alpha. Doubtful this will be in 2.4.x. Maybe 2.5.x +
    • ReiserFS -- The 2.3.x freeze means this might not make it into 2.4.x
    • XFS -- We've had a press release so far. Woo-frickin'-hoo.
    • JFS -- An interesting pile of code. What kernels does this work with? The 2.3.x series has had major changes to its buffer cache subsystem, so if this one doesn't already work on 2.3.x, it's doubtfull it'll go in either.

    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 :-)
    ---
  • There is already a project underway to get an LVM for linux. I've been successfully using it for approximately a year now. Take a look at http://linux.msede.com/lvm/ The command structure is very similar to HP-UX, and the theory behind it consitent with AIX's and HP-UX's LVMs.

    --Daniel
  • Reboots take minutes instead of hours.

    I administer many RS/6000s (S70s, H70s, S7a, etc.), several of them clustered. As a matter of fact, I've never been able to boot one to just the operating system in under 20 minutes.

    Most of the time, the IPL takes 35 minutes to an hour for the S7*s. Even with a fast IPL (which can no longer be done by software but requires touching the box (are you listening IBM?)), I'm gazing upon least 25 minutes.

    My Sun Enterprise servers can be booted in under six minutes. Every time.

    That said, I'd take AIX over any other operating system on the planet for a high-end server. Linux is great for unclustered single-service-per-box applications or many light services on a single box but, for 'real' work, AIX on RS/6000 is the way to go.

    As for AIX's JFS, it is amazing. Seven years, several disasters and not a single bit lost. Coupled with AIX's logical volume manager (LVM) and SMIT, well, there just isn't a better place to be.

    Init 'I Ain't Paid By IBM But I Would Carry Their Child' Zero

  • Actually, I'm using ext3 right now for all my filesystems. It works really well. Took a little hacking to get it to compile with 2.2.14, though. Actually, it does full journaling. According to the info, that's supposedly *easier* to implement than meta-data only! Anyway, I've had a number of outages recently, and not lost a thing thanks to ext3! It is a trifle slower than ext2 on writes, though...


    Supreme Lord High Commander of the Interstellar Task Force for the Eradication of Stupidity
  • I've heard a lot of respect for the solidness of IBM's JFS. I've also heard a lot of respect for the performance of ReiserFS. Once both of these are available with source code, will we be able to put their functionality together to get the best of both worlds, or does the way that they do things exclude each other?
  • yep. and group partitions together to form "domains". this should be implemented into linux at some time. it's just too handy.

    how hard is it to trash... don't really know. never intended to try it. :-))
  • CrosStor HTFS is Solaris (Sparc or ix86) only. There is no Linux version.
  • Probably not quite yet. This code appears to have been ported from OS/2's JFS, and JFS is not the "main" file system in use.
    You need to have at least a minimal HPFS partition because JFS is still not bootable.
  • Yeah, but if there's no particular technical reason why you can't consolidate your favorite features, then why not do so?
  • The thing that is relevant in the context of this discussion is not the backup software, but rather the Veritas File System, [veritas.com] which is used as the journalling filesystem by a number of vendors, notably including Sun.

    Reportedly there are other UNIX vendors integrating it, likely including SCO and HP.

    I was apparently wrong about there being a JFS dependancy on Veritas FS; there is, in any case, zero relevancy in this thread to their backup software.

  • We've also had problems with power crashes and a lack of AdvFS recovery using salvage. Then we resort to a tar backup of the good inodes, and trashing the domain, and recreating the domain. That is one royal pain in the butt, and has us seriously considering going back to UFS. At least it was consistently fixable.

    Another issue is that if we fill the file system we could get empty files and unbootable systems. That is no big deal if you can boot from other media and run a quick fdisk to mount a disk. Unfortunately, the AdvFS domains require a little more work to get mounted.

    I think there are some nice ideas in AdvFS, but I also think anyone who has administered it a lot will think that it is more trouble than an unjournaled FS.

    Another point about journaled file systems and linux. AFAIK, ext3 is the ONLY file system that works on something other than x86 systems.
  • SMIT -- the system management tool for AIX -- will make any Linux user very, very jealous of anything on the Linux side as far as admin tools go. (Hell, it'll make any Sun or SGI admin jealous, too.) It can do _everything_ for you, and it's not shitty like Solaris' admintool -- it tells you exactly what commands it's going to run so you can duplicate them on the command line yourself in case something fucks up. It makes managing dozens of AIX boxes a breeze rather than a horrible chore. I would do very questionably legal things for a SMIT lookalike and workalike on Linux.

    - A.P.
    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • File System Support and the Kernel (Score:3)

    by Cef ( 28324 ) on Thursday February 03, 2000 @07:45PM (#1308644)

    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.

  • I hope I'm not just stating whats been said already, because obviously, any vender, let alone IBM, releasing something for linux, and under the GPL! is good. However, this has more benefits then what immediately meets the eye.

    Linux has become a powerful and economical choice for a entry to midlevel server. However, you will find very few interested in using Linux for large scale, mission critical file serving when there are so many proprietary, Sun Servers, HP, IBM, Compaq Tru64... high end unix-based servers that have tried and true journaling file systems. With a GPLed journaling file system, Linux can begin to take notice from those who might have used proprietary systems. Which also hopefully will encourage other developments previously found only on such high end and proprietary servers (hot swappable NICS comes to mind, tho I think this may be more of a hardware feature then anything, I dunno, I've never tried putting linux on the compaq proliant at work, if only they'd let me :-) even that is technically a mid-level server).

    Anyway, for all of those who say, oh wow, journaling filing, i want that on my slashdot-viewing box. You don't really need it. A journaling file system is a complex and processor demanding file system. Linux runs faster with plain old EXT2, despite its shortcomings. But for server applications, transaction journaling is the only way to go.

    On a side note, does anyone know the status of XFS (another journaling file system) taking EXT2s place? I heard that that was a possibility. However, to me its unecessary to implement a full fledged journaling system (IBM or SGI) unless you really need it. But thats just my take on it.

    At any rate, thanks to IBM for supporting open source.

    Spyky
  • I have used JFS and ext2 side-by-side for several years. AIX ran on a succession of high-end IBM workstation with a fast SCSI drive, and Linux on a succession of mid-range IBM PC with IDE drive. Even given the disparity in hardware, JFS was never significantly faster than ext2, and for operations that created lots of small files, it was 3-4 times slower. And despite the promise of fast boots ("no fsck"), the AIX machines overall booted much slower than Linux. And, between the two, the AIX machine was the only one that I ever lost a file system on after a power failure.

    In fact, more generally, I'd be really hard pressed to think of anything I would want in Linux from AIX (maybe the Fortran 90 compiler).

    When it comes to systems like Irix, AIX, JFS, etc., you have to realize that a lot of smart people have worked on them for a long time. Some people may view that as an advantage. I don't. The motivation of those engineers was to be able to point to new features they implemented when their performance review came up every year, to do well on benchmarks, and maybe to write some papers for technical conferences. Leaving "good enough" alone was definitely not in their interest.

    And those engineers were backed by big software development organizations that debugged and tested that code for every release, and by big consulting and field support engineers that helped customers configure the zillions of options that those systems had, most of which hardly anybody ever needed.

    Linux keeps things simple. It gets good performance using comparatively straightforward code. That's a big win in my book, and I think it's the reason why so many people prefer Linux to proprietary systems. Let's not spoil that advantage by incorporating all those dusty decks from IBM, SGI, and other big companies that fit neither with the Linux code development infrastructure nor with the end user support infrastructure. The only party that benefits if Linux gets overly complex is companies that sell support.

  • Once a developer or team advances their program sufficiently for other projects (with similar needs) to notice how cool it is, these other lesser projects tend to be abandoned into obscurity.
    True, but if the developer ressources are spread out too thin, none of the projects may reach maturity, or it may take an ridiculous amount of time. It took 10 years before we got the current situation with two dominating free widget sets for X11. In the computer business, ten years are close to "never".

    This is why I think we should encourage young programmers interested in free software to think really hard before staring a new project. Aren't there some existing, related project they can contribute to instead?

    We don't see a lot of new widget sets coming out anymore.
    Actually, we do, but most of them are build "on top" op Gtk+. For example, there are currently four different C++ toolkits build on top of Gtk. True, they fill different niches, but each of the teams consist of just one or two core developers.
  • Developer resources are certainly finite, but remember that projects often don't scale too well beyond a certain number of developers, unless they are modularized into sub-projects.

    So we wouldn't necessarily get faster progress if everyone piled into one JFS, particularly not when version 1.0 hadn't been released. This way we get several to choose from and they can borrow features from each other.
  • How immediate would be to compile a good quality IFS of JFS to work with a normal OS/2 Warp 4 (not Aurora or WSEB)?
    I mean, how complete is the code provided compared to the OS/2 one provided with OS/2 Warp Server for e-Business?
    --
  • I don't disagree that if all the FSes got integrated in, there wouldn't be a big problem in keeping them maintained.

    But that wasn't my concern.

    My concern was, and is, that it is likely to be prohibitively difficult to get all of these filesystems integrated all at once into the official kernel stream.

    They all have somewhat differing expectations as to the interfaces used to get at such things as disk cache. This should not be a big surprise; they were designed independently, and thus have differing ideas as to how to interface with the kernel.

    The problem is that since they simultaneously require:

    • Quite tight integration, so that they can provide robustness and performance guarantees, and
    • Somewhat differing approaches to connecting to the rest of the kernel,
    this will make the integration of all of them at once a daunting task to Linus/Alan/Stephen.

    Note that namespace issues have already come up; ReiserFS and EXT2 had clashes due to trying to define functions by the same names. Other similar things are likely to happen.

    The point is that doing justice to integration of each FS will take time and effort.

    In contrast, doing justice to the wide world of Linux users that may have concerns other than just that of having cool filesystems may involve deciding that instead of working on JFS or XFS integration, they'll work on something else.

    Furthermore, the issue isn't necessarily of "justice to Linux users;" it may instead be that Linus will integrate in some FSes, and then decide that the notion of adding in more bores him, and say:

    **** off. I want to spend my time adding in USB drivers instead.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close