Slashdot Mirror
IBM Open Sourcing AFS
Erik from IBM wrote to us to confirm that IBM will be a "open sourcing" AFS. What's actually going is that they are forking the code, as not all of the code can be opened for "technical or licensing reason". So, there will be IBM AFS, which they will support, and Open AFS which will be the open code. The license is going to the be the IBM Public License which is an OSI approved license. Overall good news for a very scalable, secure file system.
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.
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:
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
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:
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!
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
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.
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.