IBM Open Sourcing AFS

Re:Lotsa licenses by barracg8 · 2000-08-17 03:31 · Score: 3

Opening up the code for anything (even if MS did it) is a good deal,

Amen halleluja to that, brother ;-)

Here is a link to the IBM public license.

I guess people keep having to come up with their own licenses all the time, as the GPL isn't GPL'd. :-) Anyways, I doubt that the IBM legal department would be all that happy if people just started releasing code under of the shelf licenses - aside from many concerns they may have about the license, it would make them rather redundant!

At a glance, the licence looks quite GPL-ish to me, ie if you redistribute you must make source available& the license, or an equivalent one, propagates.

IBM may publish new versions (including revisions) of this Agreement from time to time.

I guess one genuine reason that everyone needs their own license, is that everyone needs to state who it is who has the right to change the license at a later date. Remember: FSF retains copyright over the GPL.

cheers,
G

you probably don't want AFS by jetson123 · 2000-08-17 03:38 · Score: 4

AFS semantics are very different from UNIX file system semantics: permissions are associated with directories only, access is determined only by the containing directory, if multiple clients modify the same file, updates are lost, you can't have any special files in an AFS file system, etc. AFS uses its own authentication, it doesn't work well for big files, it always requires extra work to get it to work with daemons, and it has severe problems for scientific compute clusters. IBM has long ago moved onto DFS (unrelated to Microsoft DFS), which fixes many of the problems of AFS (but is itself big, even more complex than AFS, and hard to administer). Many places are trying to get rid of AFS because it's just too much of a hassle to run it (and converting back to a UNIX file system isn't easy because AFS encourages permissions and ACLs to mushroom unnecessarily).

AFS may be acceptable for specific applications (in fact, what it was designed for originally): a large untrusted user population, dedicated system management staff, and smallish files and problems (text file editing, small programming jobs). But for many environments where Linux is used--big software development projects, web servers, scientific computing, home networking--it just doesn't seem like a good fit.

If it's the security you care about, NFSv4 might be for you, although it clearly also has some problems. If you want something AFS-like, Coda might be an option (but I don't know how mature it is yet). MFS and GFS are options for compute clusters. Maybe we can get 9P or Styx up on Linux.

Re:you probably don't want AFS by Anonymous Coward · 2000-08-17 04:41 · Score: 3

> AFS semantics are very different from UNIX file system semantics: permissions are associated with
> directories only, access is determined only by the containing directory,

Think about hard links: that's why it works this way.

> if multiple clients modify the same file, updates are lost

That's not entirely true but I agree it's stupid. Anyway, it doesn't matter, if you don't use file locking you should expect corruption anyway.

> you can't have any special files in an AFS file system

I hope you don't expect your users to be able to create /dev/mem nodes in their home directories...

> AFS uses its own authentication

Yes, it's called Kerberos... ever heard of it?

> it doesn't work well for big files

It works reasonably well with big files, unlike Coda which unfortunately doesn't work at all with them. Anyway for huge amounts of data you shouldn't be creating massive files anyway, look into databases or steaming software.

> it always requires extra work to get it to work with daemons

You mean you want root on a given machine to have "root" in your whole enterprise?

> and it has severe problems for scientific compute clusters

What, rsh doesn't work? Just patch it and it works fine. Otherwise what's the problem?

> IBM has long ago moved onto DFS

No they haven't

> (unrelated to Microsoft DFS)

Thank god. But I'm glad Microsoft has finally invented the automounter.

> which fixes many of the problems of AFS (but is itself big, even more complex than AFS, and hard
> to administer).

And nobody uses it...

> Many places are trying to get rid of AFS because it's just too much of a hassle to run it

There really is no better alternative, though.

> (and converting back to a UNIX file system isn't easy because AFS encourages permissions and ACLs
> to mushroom unnecessarily).

You mean it encourages security? :)

> AFS may be acceptable for specific applications (in fact, what it was designed for originally): a
> large untrusted user population, dedicated system management staff, and smallish files and
> problems (text file editing, small programming jobs).

It lets you solve problems on a big scale. I hope the open source release will make it even better and more available for everyone to use.

> But for many environments where Linux is used--big software development projects, web
> servers, scientific computing, home networking--it just doesn't seem like a good fit.

Big software development is one of the first things AFS was used for. It's only recently, ironically, that local disks+Linux have outperformed network file systems so much.

AFS makes sense on web servers for replicating site data and allowing many people to "upload" without the insecurity of FTP.

And I don't see why anyone wouldn't want to use AFS at home. Again, I hope the open source release will allow as many people to have real security in network filesystems as possible.

> If it's the security you care about, NFSv4 might be for you

Whenever that will be available...

> If you want something AFS-like, Coda might be an option (but I don't know how mature it is yet)

Coda is nice but not packaged well enough for everyone to start using it. It also chokes on big files much worse than AFS, unfortunately.

> MFS and GFS are options for compute clusters.

They're nice for high bandwidth to big files. But they give you no security... do you really want a root exploit on one machine in a cluster to destroy all data in the entire site?
Re:you probably don't want AFS by jetson123 · 2000-08-17 07:13 · Score: 3

If you want to keep a bunch of web sites synchronized over a WAN, rsync is much simpler to deploy (it's just a user program) and considerably more efficient than AFS. You also get much more control over what gets updated where and when.
For serious wide area, distributed authoring, no distributed file system, no matter how good, is going to be adequate by itself. Distributed authoring requires workflow support, version and revision control, support for disconnected operation, and other features. For that, something like WebDAV or CVS are more appropriate choices.
Don't get me wrong: AFS isn't all bad. Some of its core ideas are really great. But some of its practical aspects (e.g., differences in semantics from UNIX, simplistic caching strategy) make it a pain and rather inefficient in many real world settings. There are some areas where people can live with those limitations (e.g., university computer labs), but I think for most environments, NFS and SMB, despite their many warts, are still more practical systems.
Re:you probably don't want AFS by Gerdts · 2000-08-17 10:22 · Score: 3

The problems you mention with "not working well with daemons" is likely related to the fact that it uses Kerberos IV. If the daemon needs to have more access to AFS directories than you are willing to give to any other user on the system, there is a lot of work to do.
Specifically, you need to stash a password away such that the daemon can authenticate and periodically reauthenticate so that it does not lose the rights that it has.
AFS does allow you to have ACL's based on IP address. As such, if you are running a daemon on a machine than only system administrators have access to, it may not be a big deal to allow everyone on that machine to write to a directory. Other machines, though, may have read-only or no access to the directory.
NFS 4 will have the same problem, as a requirement for it is that Kerberos V is supported as an authentication mechanism. If you don't give world write to a file/directory, then you cannot write to it without a kerberos V ticket.
Re:you probably don't want AFS by jetson123 · 2000-08-17 12:18 · Score: 3

Your response is generally "well, AFS doesn't do this, but you shouldn't be doing that anyway".
The fact is that people do deal with gigabyte files over networked file systems (video editing, scientific datasets, server logs, etc.), they do run UNIX installations that don't use AFS Kerberos as their authentication method, they do need to create named pipes and UNIX domain sockets on networked partitions, and they do expect that UNIX access semantics are preserved when using remote files. AFS fails to deliver on all of those. The AFS designers simply thumbed at UNIX semantics and didn't give a damn.
NFS does deliver on all those points. For small and mid-size installations, NFS management is pretty simple, and NFS security is getting better and less of a problem with switched Ethernets anyway.
The suggestion that AFS is good for content distribution to web server farms also strikes me as silly. Installing AFS to achieve synchronization between web servers is like driving a truck to pick up a carton of milk. rsync and similar tools are much simpler to deploy and much more flexible.
People can get excited about whatever they want, and if AFS makes you happy, great! I have used AFS for many years, and my recommendation is that people should look at its incompatiblities and quirks very carefully. I think for most UNIX environments, it is not a very good choice.
But what this announcement may mean is that, after years of neglect, maybe people will roll up their sleeves and fix those rather serious problems that AFS has. Then, it could potentially become a good distributed file system. Until then, it is a solution that, in its own way, is as flawed as NFS, and quite a bit more work to manage.

Too little, too late? by qralston · 2000-08-17 04:32 · Score: 4

As someone who has worked with AFS for the past 8 years, I have to say that I greet this announcement with a somewhat more pessimistic view.

Namely: AFS is now officially dead.

I say "officially" because, IMO, AFS is already dead, and has been for years (ever since Transarc (now IBM Transarc Labs, but I'll refer to them as Transarc for brevity)) came out with DCE/DFS, really).

Oh, there were bouts of heavy maintenance and limited development. These periods were inevitably precipitated by Transarc's AFS customers becoming vocal and complaining. But when the complaints died down, so did Transarc's commitment.

Transarc has never treated AFS like a real product. Their "development" efforts have been limited to ports to new versions of the same operating systems, a few ports to new architectures, bugfixes, and very limited feature additions (mostly backports from DFS).

In fact, this year has seen Transarc's AFS support sink to a new low. From what I've been able to garner, all AFS development is being outsourced to India. Responses from Transarc's AFS hotline support (a support service which customers purchase!) have been inept. There was no Decorum (Transarc's yearly AFS conference) this year, nor even an announcement concerning it. It's been ages since anyone from Transarc has posted on the AFS mailing list.

So, why is Transarc (now IBM Transarc labs) open-sourcing AFS? For one simple reason: AFS is IBM's red-headed stepchild, and they don't know what else to do with it.

If you read the announcement at http://www.transarc.com/News/pre ss/opensource.html, you'll note this entry in the FAQ:

Is IBM still investing in AFS?

Yes. IBM recognizes that many of our customers will still want a commercially-supported version of AFS IBM AFS. IBM/Transarc will still sell, maintain, port (to new versions of currently-supported OS), support, and provide minor enhancements to "IBM AFS".

Good software grows or dies. AFS died a long time ago. I, personally, think this is tragic, because AFS had great potential. But Transarc never made a long-term commitment to anything other than keeping it on life support. Perhaps it can be resuscitated back to health, but I can't help but wonder if the Open Source community's effort would be better spent towards other distributed filesystems efforts, such as CODA (which I admittedly haven't investigated, but plan to).

--
Your bank is insolvent.
Taking Money Back

IPL & Linux by Amphigory · 2000-08-17 19:09 · Score: 3

My big concern is this: presumably, AFS includes some kind of kernel driver. If the IBM public license covers AFS, then will we be able to integrate AFS into the Linux kernel?

Incidentally: for those of you claiming that AFS is obsoleted by Coda, think again. There's no way I could get my employer (one of the biggest Internet providers out there) to buy into Coda at this stage of development. AFS on the other hand they would /definitely/ go for. The biggest problem has been that IBM doesn't really push it, so it's hard to get executive attention for it. If it's oss, I don't need executive attention -- I just do it.

--

--
-- Slashdot sucks.

Link to announcement by ColdN · 2000-08-17 03:02 · Score: 3

I found the announcement over at IBM Transarc Lab. I also includes a short FAQ.

Why this has so much potential for good. by jlrobins_uncc · 2000-08-17 04:47 · Score: 4

AFS is a very stable, tested, enterprise filesystem. It offers the following features:

Cross platform: Many UNIXen as well as NT as either client or server.
Secure: Uses Kerberos IV for user authentication.
Client-side caching: client machines use disk or virtual memory to cache MRU files, greatly reducing # trips down the wire on reads.
Unified naming scheme: names of files don't indicate what file server they're on. Makes moving of volumes from one fileserver (or drive on the same fileserver) to another a cinch, since no client-side changes need to happen.
Read-only replication: Make your application install directories replicated in each building on campus.

Now, it's not a perfect product, but it is way cooler than vanilla NFSv2 or NFSv3, especially on the server-side management side of things. It doesn't do disconnected operation (which CODA strives to do), byte-range locking, strict UNIX file semantics (data most recently written == data viewiable by all file handles to that file), or Kerberos 5, but it is a far simpler system to get running than DCE, which does address some of those issues.

One would hope to see the following things from this open sourcing:

*BSD client / servers.
MacOS X client (at least!)
Millineum / Win2K clients (NT clients exist currently).

If the MacOS X client happens, then there will be a secure, scaleable enterprise filesystem for the three major computer platforms -- Wintel, UNIX, and Mac, and it'll even be freely available! I don't believe that there are any products available today that offer secure, robust support for all three platforms (and no, I don't consider protocol translators, such as Samba or CAP, which require you to set up the clients to use cleartext passwords over the wire to authenticate (not to downplay in any way the role of either technology -- it's not their fault that you've got to set up the clients in that fashon to interoperate with AFS as it is now), or using NFSv2 or v3 on the UNIX end to talk to something like Novell 5 (which, AFAIK, doesn't talk at all to Macs anymore)).

This will give us one protocol on the wire, multiple server-side implementations (interoperable in the same cell!), multiple client-side implementations, WAN scalability, and secure authentication. A good day for the world!

IBM Public License vs. GPL by ddstreet · 2000-08-17 05:53 · Score: 3

As far as I can tell, the only substantial differences between the IBM Public License and the GPL are

Any contributions become IBM's property (Copyright IBM, All Rights Reserved)

You can charge $ for the program (although you must provide source) unlike the GPL (cannot charge for the actual code, only related services)

I know the main reason IBM doesn't like the GPL is the 'Viral Effect' where code that uses GPL'd code must be GPL'd itself (unless it dynamically links?), but it kinda (?) looks like the IBM Public License has the same problem...?

Lotsa licenses by Icebox · 2000-08-17 02:44 · Score: 4

Curious link...

Opening up the code for anything (even if MS did it) is a good deal, I'm just wondering about everyone wanting to write their own license. Until I followed this link I wasn't even aware that there was an IBM Open Source License. Why is it that the BSD license or the GPL wouldn't work? Even under those they could have kept the some parts of the code closed....or am I wrong somewhere?

--
Icebox

Excellent by drift+factor · 2000-08-17 02:42 · Score: 3

This is great news, even though we just bought AFS...oh well. I wonder what the guys at the arla project will do now?

This will be good news, if they do it by Hairy_Potter · 2000-08-17 02:45 · Score: 5

The IBM link is non-existent, it must have been retracted. I found this faq that explains AFS.

But when Linux incorporates this, it will be a lot easier to cluster servers, and share files. And maybe we can kiss of NFS forever.

As one of the architects designing DFS in IBM by gelfling · 2000-08-17 07:06 · Score: 4

We've always had a hard time selling DFS internally. In fact we've stopped trying to do that because there weren't enough internal customers. The hurdle costs were too high the skills were hard to find and expensive and customers still wanted SMB shares via Samba which drove the cost even higher. The client side DCE licence costs drove Samba since the per client cost was $65/seat in bulk. AFS as open source can only be a good thing since we can always find someone to pick up the development and maintenance and foregoing DCE-Kerberos is really not that big a deal from an internal perspective. In our environment the challenge was to collapse hundreds of LanServer domains. DFS or AFS fit the bill and the cost dynamics work very well compared to staffing 1 headcount/25-35 servers in the LanServer world. The problem anyone will find though is backup and storage management. butc or buta just don't scale very well even with multiple replicas of the fldb core so whoever tries to manage this, as we did, will be forced to write extensions to their storage management code, as we did with ADSM. Also you will find that Samba doesn't scale nearly as well as you want with only a few hundred accounts on a Samba server even if it sits on a huge Unix machine. This leaves you will a few hundred or more SMB gateways if you try to scale up to the huge numbers we did.

Once again AFS open source can only be a good thing - it will propagate a great technology into large sites where they would shied away from it previously.

Re: Lotsa licenses -- TMTOWTDI by InitZero · 2000-08-17 03:27 · Score: 3

I'm just wondering about everyone wanting to write their own license.

{sigh}

When Larry Wall notes 'There's More Than One Way To Do It', we cheer and write folk songs. When IBM says that the GPL isn't right for what they want to do, we get a bad feeling in the pit of our collective our stomach. Why?

Not everything needs to be GPL. Not everything should be GPL. Let's not make the license the issue. Let's talk about what a great product AFS is and how much a pain in the buttocks it is to configure it correctly.

InitZero

Re:Once again... by sirwired · 2000-08-17 02:52 · Score: 3

Why do you say that IBM is not giving away anything substantial? Have you even looked at what they are giving out? When commercial, low-level, products are "opened", it is quite common for some parts to be witheld because the company simply does not exclusively own the rights to everything in the code. It probably has nothing to do with corporate treachery or evil PR minions, just simple licensing rights over which the IBM Software Group has no control.

Re:Once again... by chris88 · 2000-08-17 02:53 · Score: 3

Dude, your talking about the company that's donating millions of dollars to the open source community, the company the continues to make damn impressive break-throughs with processors, and the company that's porting Linux to a good deal of their massive servers.

Them opening up this file system can be useful to everyone, despite the fact that this may not affect IBM one way or another.

But to mention IBM and Micros~1 in the same sentence is almost criminal.

18 of 96 comments (clear)