Slashdot Mirror

AFS is for distributed computing, GFS is for fault-tolerant cluster computing

ah. if you're right about that, then this is probably still not quite what i want.

i've been wanting a distributed, fault-tolerant filesystem to play with for a while now; NFS is getting old and clunky. i want something i can share between several machines, that would keep a local copy on each machine involved, and that could seamlessly tolerate disconnects/reconnects of machines in the cluster. ideally, i'd also like it to do security, authentication and encryption decently.

i haven't found anything. Intermezzo and Coda seem to come closest, but they're both more research project than solid product. OpenAFS seems stuck in the same niche, and all three of them are almost-but-not-quite POSIX compliant. (i'm not really sure if non-POSIX semantics would be a problem or not, but i'm a pessimist; i'd like to take on as few problems at a time as i can.)

GFS seems to hold a lot of promise, and its Sistina heritage is a good sign, but if it can't (easily) replicate files across a network for me, then it's not quite what i'm looking for. ah well, maybe that Unison thingy i heard about can be a poor man's substitute...

This was actually asked sometime ago, sort of - the answer is OpenAFS

You mean AFP (Apple Filing Protocol). Apple:AFP::Windows:SMB. AFS is something completely different.

There are patches for the AFS client to support disconnected operation. They haven't made it into the core distribution yet (lack of developer resources) but if this is a must-have for you you might want to check it out. This mailing list post is a good place to start.

These people http://www.ibm.com/linux/ can help. Worldwide, 24 hours a day, 7 days a week. Look at http://www.openafs.org/ , http://www.opendx.org/ , http://www.research.ibm.com/resources/news/2003111 4_bluegene.shtml if you want to be convinced they know what they are talking about; both on the 'giving' and 'receiving' sides of the coin.

This is an excellent question, and probably the primary point that the original submitter didn't cover.

Binary software distribution on Linux is a bitch. Unfortunately, many of the people that could improve the state of things are not in the least interested in doing so because "binary software isn't GPLed, and all software should be Free, so screw you". Frankly, this isn't a really feasible position to take, pleasant as it may be to say.

The LSB has helped a bit. It standardized the existence of (a *very* minimal set, mind you) certain libraries. The C ABI has been pretty stable, but the C++ ABI has changed several times in the past few years.

Basically, there are a number of problems.

First, shipping something in C++ is out. If you go back even a year, you're going to hit systems that won't run with your binary C++ software.

Certain interfaces, like DGA 1, have been deprecated. the X11 people seem to have little interest in backwards compatibility with DGA 1. Thus, software using DGA 1 tends to be flaky.

Some constants change and libraries and software are not capable of handling non-compile-time settings. I tried increasing HZ in my kernel a year or two ago, and discovered that it mucked up all kinds of timing stuff, probably due to glibc assuming that runtime and compile-time HZ were the same. It made the animation in Dominions (Well-maintained binary software game from Illwinter) run proportionally faster, for example. This means that even static linking is not a good answer.

Lots of libraries that folks might like to use are *not* always present. Frequently, systems include only one of GNOME or KDE. SDL is a common include now, but Clanlib, OpenAL, and Allegro are generally not included. SDL is not part of the LSB, so may not be relied upon (and as a matter of fact, old statically-linked versions of SDL have broken on newer systems).

I feel that Loki is probably one of the best packagers out there in terms of folks knowledgeable about the Right Way to do things on Linux and how to ship binary software. They've had extensive experience.

I have purchased or tried a number of titles. None of these was ported more than a few years ago, and were theoretically maintained by Loki up until they closed their doors, only one year ago. Of these, on my Fedora Core 1 system:

* Postal seems to work

* Alpha Centauri seems to work.

* Kohan when patched does not work, though the original version generally works, with frequent XFree86-hanging problems when doing things like resigning a mission.

* Soldier of Fortune does not work.

* Heavy Gear II does not work.

* Sim City 3000 does not work.

* Hereos of Might and Magic works.

* Railroad Tycoon seems to still work.

* Postal seems to work

These are not really great odds, and these games use *very* minimal libraries. SDL is the primary one, and Loki *maintained* SDL, so knew it damn well.

Folks that ship binary software that interact more with the system have generally fallen back to releasing many copies on a per-distribution basis, and only supporting some distributions. OpenAFS is open source, and produced by some very capable folks. However, IBM also provides binary packages with OpenAFS. They essentially support only a few Linux distros (particular versions of Debian and Red Hat) and have to provide builds for each release. Their distribution page is quite intimidating to any vendor considering Linux releases.

Illwinter ships their Dominions game and tries to be cross-distribution. The thing even uses 3d, but I'm also using it on a pretty mainstream (Red Hat) system. Not sure what problems might come up on a more oddball system.

Basically, you can safely say that:

* Linux software binary distribution is much, much more expensive and difficult than on Windows or Mac OS. There are many more targets to test and support.

And how many Unix systems have ACLs with [b]dynamic[/b] inheritance?

Any *nix that supports AFS, which is pretty much all of them, including Linux. NT's entire security model is basically a copy of VMS, which many users didn't like due to its complexity (features & complexity tend to yield errors in applying it properly). That said, I like ACLs, but they're only really sorely needed on networked file systems, such as AFS.

* OpenAFS doesn't run nicely (read: at all) on FreeBSD (tested with -STABLE on i386 and -CURRENT on sparc64). Doesn't matter if you're running it on Linux, of course.

How long has it been since you tried this? I seem to remember the OpenAFS team fixing a lot of their FreeBSD issues. I know OpenBSD recommends OpenAFS as a network file store. Even then you could try ARLA (?). Should be able to Google for it. IIRC Arla fully supports FreeBSD as both a client and a server.

* AFS uses it's own filesystem rather than riding on top of the O/S. That's fine, and better for security, but sucks if you want to do something fancy like distribute the same filesystem via samba, NFSv3 and AFS simultaneously.

Samba is supported somehow IIRC, but I KNOW that AFS over NFS is supported because it's in the docco... Appendix A. Managing the NFS/AFS Translator

The way we do it is that we have some underlying file store running on unix machines. At the moment we've got a couple Sun machines with large RAID arrays.

Then, to provide access to clients, we use Samba as a bridge to the Windows desktops and NFS for trusted linux clients; untrusted hosts can use SFTP or, if they just need read access, HTTP.

Having multiple storage nodes on multiple sites synchronized is a SAN, not client access, problem. NFS just doesn't provide multiple-node functionality. NFSv4 (link, link) may have some interesting features that could help; AFS was designed with multiple sites in mind and does intelligent caching and has other useful features over NFS but does have some limitations; and then there's things like IBM's Storage Tank which I haven't had a chance to look at properly yet.

Bottom line: If you have a flexible SAN infrastructure, you can use bridging nodes to provide access to the SAN tailored to whatever your clients require. The infrastructure is the hard part; with commodity packages like Samba client support is a much simpler seperate issue.

• OpenAFS
• arla

There are servers and clients for tons of operating systems, including every one you mentioned.

You'll be wanting a distributed cluster filesystem. There are several available, with their pros and cons. They are also all aimed at enterprise / HPTC installations. For home use you'll be better off with a set of RAID disks.


GPFS from IBM. This is free for academic use, but you pay for commercial use. Linux or AIX only.


GFS from sistina. Commercial offering. Linux only.


Lustre. This is beta quality code, but is freely available. It might work wonderfully, or it might eat your files.


(open)AFS. Works, but has limitations. It does not support large files and clients aren't available for all OSes.

OpenAFS

http://openafs.org/

AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for file sharing, providing location independence, scalability and transparent migration capabilities for data.

I've used AFS for a while now on Linux and various Unixes, and it does very well (even under "heavy loads", like moving a couple various gigabytes around at the same time). I know it works on the various Windows flavors that you have (although I've never used it on Windows), Linux support is there, and a glance at their download page shows that they have a Mac OS X package. Now whether it's stable or usable or not, I can't tell you. But if you can get satisfied with the Mac implementation, the rest ought to be a slam dunk. You'll still be out in the cold with the MacOS 9 box, however. A single FTP daemon on that machine might not be too great a concession.

There might be a slight learning curve to overcome in getting it all set up and ready to use, but once you get it where you like it, you shouldn't have to worry about it anymore. And it sounds like your needs are not quite enterprise-level, so you likely wouldn't need to expose yourself to its entire feature set anyway. I'd say given the diverse hardware in your office/lab it fits the bill pretty closely.

-B

AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for file sharing, providing location independence, scalability and transparent migration capabilities for data.

I've used AFS for a while now on Linux and various Unixes, and it does very well (even under "heavy loads", like moving a couple various gigabytes around at the same time). I know it works on the various Windows flavors that you have (although I've never used it on Windows), Linux support is there, and a glance at their download page shows that they have a Mac OS X package. Now whether it's stable or usable or not, I can't tell you. But if you can get satisfied with the Mac implementation, the rest ought to be a slam dunk. You'll still be out in the cold with the MacOS 9 box, however. A single FTP daemon on that machine might not be too great a concession.

There might be a slight learning curve to overcome in getting it all set up and ready to use, but once you get it where you like it, you shouldn't have to worry about it anymore. And it sounds like your needs are not quite enterprise-level, so you likely wouldn't need to expose yourself to its entire feature set anyway. I'd say given the diverse hardware in your office/lab it fits the bill pretty closely.

-B

Of course, this sort of key issue has already been recognized and solved by the open-source community. You should at least take a look at the Andrew Filesystem which would provide one file sharing system across all your machines. Another good and reliable alternative it to use a Macintosh as a central file repository, since MacOS now comes pre-configured with Samba, NFS, and AFP file sharing.

Here're two AFS projects:
Arla
OpenAFS

Anyone know if there is there a filesystem out there for Linux that has that level of rights?

Well, in my operating systems class, my professor often mentioned the Andrews FS, which lets you have acls in linux.. Google gave me this info about AFS permissions

I had more or less the same basic requirements and I opted for AFS.

My needs were a little more demanding (had to be implemented in GNU/Linux, Solaris, AIX, HP-UX and as an extra Windows 2000) and grocking AFS can be difficult at first but it was the best choice by far. Stable across all the Unices, very secure (this was another requirement) and integrates perfectly with our Kerberos Domain and LDAP accounting info. It provides a unique namespace that can span multiple servers transparently, does replication, automatic backups and read-only copies, client-side cache with callbacks, has a backup (to tape) system that can be used stand-alone or integrated with existing backup structures (Amanda, Legato, TSM) AND was the basis for the DCE filesystem, DFS (as a side note I find it interesting - and sad - that most things people try to emulate this days are present in DCE , and Windows 2000 got many of the "new features" from a technology initially made for Unix :DFS, DCOM, Directory Services, SSO, DCE-RPC, etc.)

AFS is amazing and much more robust than any distributed filesystem I know of; it has shortcomings when servers time out, but apart from that it's really an excellent solution; an example I generally use to give an idea of some of the good features of AFS is a relocation of a home directory to another server. The user doesn't even notice that his home directory was moved to another server *even if he was using it and was writing stuff to disk*; at most all writing calls to his home dir have a small delay (a couple of seconds) even if his/her home dir was 5 Gb worth.

Kerberos integration is an added bonus, if you can you can use this as an excuse to kerberize your systems and form a Kerberos Domain. If you don't want to just stick with the standard AFS KA server.

In my setup I have Windows users accessing their home dirs in AFS using the Kerberos tickets they have from the Windows login and the fact that a cross-realm trust was made between the Unix DOmain and the AD; the can edit all the files they are entitled to with that ticket, and the system is so secure that Transarc used to put the source code in it's public AFS share and added the customers that bought the source to the ACL of the directory that contained it.

With all this features it would be hard not to vivedly recommend OpenAFS as the best solution for a unified, distributed filesystem. Bandwidth utilization is, in my experience, at least half of what NFS uses, which is an added bonus.

cheers,

fsmunoz

Since openafs forked from the old transarc/IBM codebase, it looks as if it has a real future. It's used by a load of educational and research institutions (notably CERN), as well as Wall Street firms.

Ever been frustrated because, in windows, if someone sets permissions on a directory they own, and says administrator can't access it... when administrator tries to access it, he gets denied? In unix, of course, root just ignores said permissions.. or changes them.

To be more precise that depends on the filesystem; one of the strong points of AFS is that not only root cant access the files but it can't also change the permissions of the shared AFS namespace. Since it uses Kerberos only users with the proper ACL can change things (of course you could give root the ability to change everything but that's a very bad idea in a distributed filesystes).
Also, from what I red, RSBAC does exactly what you mentioned and more.

cheers,

fsmunoz

My shop uses AFS - www.openafs.org - for a central filesystem; you can create RO and backup images of your data, which are dumped to tape (or disk if you prefer).

OpenSource, so you can see what's in it, and server and client are available for most popular *nix's, including Linux.

Enjoy.

• a single source for authentication (login) and profiling (groups, home dirs location, etc.); study pam a bit, a good option is to store everything in ldap and use pam_ldap; if security is a primary concern, consider kerberos
• network file sharing; you don't want your users' data scattered around on every desktop (your management costs will increase dramatically, and your backup strategy will be much more complex); nfs is quick and easy, but offers only decent performance and poor security; a good (but complex) alternative is openafs or IBM's DFS (which is the evolution of afs
• centralized backup on a single server, possibly running amanda so that you can backup different servers on a single medium; mondo rescue is a good option to backup systems periodically on bootable cds for quick recovery;
• standard distro, eg pick Redhat or Debian or whatever, based on a number of factors like ease of automating installation, software distribution and package management options, etc., and stick with it; reme,ber that you have to know your patricular distro well to handle emergencies (and emergencies DO happen);
• standard desktop, eg pick one of gnome or kde, develop suitable policies and management strategies, and stick with it; one of the factors in deciding a desktop is the toolkit used and its licensing, if you intend to develop custom software in the future;
• software distribution strategy, plan or at least try to learn a bit about possible ways to handle updates and software installation on your desktops (and servers); you can automate package management (apt or rpm) or enterprise software (red carpet or rhn);
• printing system, again for printing you have different options: lprng, cups, etc; check what printers/plotters you already have in house and if they're supported by printing systems;
• 
  Just a quick overview, to sum it up I would second the advice somebody else gave you in a previous posting: hire a decent sysadmin and plan things with him.

Are you talking about http://www.openafs.org? I guess I'm just karma whoring with the link since you didn't include it.

There are no free software, open source, or non-crippled NFS clients for Windows

Yup. But if you're willing to use AFS instead of NFS, there's OpenAFS , an AFS client that's available for Windows, MacOS X, Linux, and just about every platform out there. It's free and open source, plus pretty well designed. IBM pushes and supports it, and MIT and CMU (plus a lot of other places, but it gives you an idea of how much approval it gets from people in the know) both use it for their storage system.

AFS will also buy you a seriously secure system and better performance (thanks to leases and other good design features) than you'll get from CIFS (Windows filesharing). I'm pretty sure that NFS, despite the large number of changes in recent versions, is still outperformed by AFS.

It can be more a bear to set up, since you'll probably want to also set up a dedicated KDC, but at least you're doing things the Right Way.

Coda is supposed to be the successor to AFS, but I really haven't heard of people using it much, and Intermezzo doesn't have the backing that AFS does.

Oh, yes. AFS can do distributed storage, so it can (magic boss-exciting word approaching) *scale* really well. :-)

The good folks at the OpenAFS project had to deal with some of these changes as RedHat started introducing them into their builds of the 2.4 kernel. Their experience may be somewhat instructive -- they found a way around several attempts to prevent them from adding syscalls.

The good folks at the OpenAFS project had to deal with some of these changes as RedHat started introducing them into their builds of the 2.4 kernel. Their experience may be somewhat instructive -- they found a way around several attempts to prevent them from adding syscalls.

OpenAFS. Click that link.

Look at OpenAFS.

Hi. I'm one of the support people at CMU. My specialty? Our linux distribution. Disclaimer: I'm speaking for me and me alone. I haven't cleared this with anyone. Don't assume that I'm speaking for CMU or Computing Services or anyone else.

There's no real secret about it. mwm is going away at long last. We'll be using fvwm2 in a configuration that is (hopefully) more novice-friendly without annoying power users too much (if you're interested in testing, drop me a note). For political reasons, we'll probably not change any existing accounts for a while, but we'll offer fvwm2 for new accounts.

Why are we still using mwm? We roll our own distribution. The Andrew Unix environment was conceived back in the 80s when a workstation cost $10k+ and a 100 megabyte disk drive was really quite large (and expensive). It was a way to have standard commands and hundreds of apps across whichever underlying unix flavor you had. Things like AFS came out of this project.

Since then, the goal has been standardization, not innovation. As new flavors of unix appeared, they were dissected and made to resemble the existing Andrew systems. mwm was hot stuff a decade ago, so we're still using it. Why? Mostly, it was money. Porting old stuff is easier (thus, cheaper) than testing, deploying, and supporting new stuff. Plus (and this really shouldn't be underestimated), some of the key decision-makers have been using the old system for a long time and they saw no reason to change it.

We've known that we needed a new WM for a while. Last year, we were mired in a huge and unproductive GNOME vs. KDE flame war. GNOME has awful documentation and changes a lot with each release. It's unsupportable without spending a lot more money. However, the Stallman-worshippers weren't going to tolerate KDE because it had been conceived with impure thoughts of not-sufficiently-free libraries (Guess which side of the debate I was on ;). We were finally able to reach a compromise with fvwm2, so we're testing that now and hope to inflict it on people soon.

Now, management is finally starting to realize that 1) demand for Linux is going up and 2) the version that we offer is inadequate and has been for a while.

There'll be the usual vicious politics for a while, but I'm optimistic. We might finally have support from above to make our version of Linux suck less. Failing that, maybe we can start offering limited support for Red Hat or something else.

Carnegie Mellon also provides accounts to everyone on campus on their distributed AFS/Kerberos based system. In fact, AFS was developed as part of "Andrew", Carnegie Mellon's campus-wide computing system.

In the NFS scenario, the physical location of accounts is totally decentralized and distributed across all the machines that users actually work on.

This is not a requirement of NFS. In fact, I've never seen a setup like this anywhere. In every case where I've seen NFS used on a large scale, the NFS servers are kept in a central location, with physical access controlled.

However, AFS is harder to maintain, and you probably have to pay Transarc for a commercial version.

AFS is no harder to maintain in the long run than NFS. AFS generally has a steep learning curve, but once you have it set up, maintaining the system is no harder than on any other system. Also, you don't have to pay Transarc for anything. Check out the OpenAFS project for a free implementation (both client and server).

Given that DJB already has implementations of DNS and SMTP around that are heavily focused on security, it wouldn't suprise me if he went into looking at securing NFS (the file system)

Not specifically about DJB, but since you refer NFS and security... I had to responsability in desigining a (small) Unix network, including authentification and shared filesystems. NFS main strenght is that it's bloody simple to use (in Solaris the 'share' command is all that it takes, and the other Unices have more or less similar mechanisms), but security-wise it's a no-no.

I then discovered AFS; it was exactly what I needed. Kerberos authentication builtin, support for every OS, very solid and comes with several interesting concepts of it's own. All in all AFS has proven to be a secure alternative to NFS (AFS can also scale incredibly well).

Just my 2 euro cents,

fsmunoz

Your best approach is to use Samba with Dave/Xsamba/Sharity or the SMB client in MacOS X 10.1 (?) on the Mac. Dave is for old, pre-MacOS X MacOS-es. Smbclient/smbmount on the Unix machines (which seems kind of slow). Or you could install OpenAFS which is a distributed filesystem with caching, crypto authentification (something like Kerberos), disconnected operation, etc. The sad part is that it wasn't ported on any of the BSDs yet, except Darwin/MacOS X. They are working on ports though and the server has been ported to FreeBSD and OpenBSD and the cache manager is in the works I believe. It works fine on Linux, Windows NT/2k, Solaris and a buch of other platforms.

Use AFS and kerberos. Works for mit.edu, Ericsson, kth.se and MANY others so it should work for you too.

http://www.openafs.org
http://www.pdc.kth.se/heimdal

You might want to check out the CODA Filesystem. Its a secure network filesystem like AFS and it has transparent replication support for offline access. Also, there's AFS, but that doesn't provide offline access, but I believe it supports more operating systems than CODA is currently ported to.

...SMB will have to go away.

Micro$haft is the main company working on Windows networking protocols, and as has always been the case they don't seem to encourage standards or interoperability.

I'm thinking a better solution would be to use OpenAFS. It works on Windows and Linux just fine, and its not going to have interoperability problems because all of the stuff is open source.

I believe its only a short time, maybe a year or four, before M$ doesn't have anything to do with network interoperability software, unless they change their policy.

A saying comes to mind:
"The more you tighten your grip, the more star systems will slip through your fingers."

The costs of diverse and incompatible documents (e.g. different versions of MS-Office) is still high even if you're in a shop where the management buys into single platform (e.g. All-Shall-Be-Microsoft) myth. Take MS-Word, the new versions usually have difficulty with the next most recent version until the patch / upgrade is installed. It often takes a bit of gymnastics to make the conversion successfully especially if you're an early adopter. Powerpoint is even worse. Quite often only one or two presentations will fit on a 3.5" floppy, so that means bringing two or three floppies to conferencs to make sure I can use the conference locale's version of PowerPoint.

Here comes the cost: Imagine nearly everyone in a 120 person organization learning that the hard way, either for their own work or by trying to help some one else. The actual salary is often only 50% of what the employer has to shell out per employee.

It gets more expensive with e-mail attachements. It used to be whenever I got an MS-Office document as an attachment, it was a virus from a stranger. Everyone I actually knew, back then, used file sharing. Now that most shops don't have file sharing, these must be sorted by hand, at least in a MS-Windows environment.

And that's just the cost now. 3 or 4 years from now you have the added issue of trying to identify and read the old formats. So in reality the interoperability part the oft-cited cost benefit of running all MS products hasn't been there.

No need for new projects -- already good distributed filesystems that you can set up big servers with
afs? (or here)
coda?
intermezzo?

CMU, for example, uses AFS campus-wide. Your login scripts and dotfiles and whatnot all reside in your home directory (on AFS) so preferences migrate with you.

You can make things world-readable, and because AFS has a global namespace, anyone can see them. If I do research at MIT as well, I just need to grab a Kerberos ticket from their KDC and start using my files over there.

Just plonk a server in place, put an array of 100GB drives in place, make things readable by whomever you want, and you're good to go.

If you want a system designed with fancy automated caching that people can use without dicking around with Kerberos, freenet's a good choice. Of course, there's no guarantee that the data will stay around, but cest la vie.

It can be used to authenticate logins on Windows 2000 (and probably XP), Unix (use PAM on Linux, Solaris etc., SIA on Tru64 and hack the XDM on others).

Use it to authenticate telnet and ssh logins. There are clients for MacOS, Windows, and Unix. Use it for authenticated X11 forwarding. Use it for FTP. Use it for POP3 and IMAP4 with Kerberos authentication or SSL-encrypted passwords (cyrus-imapd). Use it for AFS to replace the insecure NFS and to allow your users to access their home directory from home. Clients exist for most Unix variants (including MacOS X) and Windows 95/98/2000/XP.

Kerberos has single sign-on.

Why Kerberos instead of LDAP? Because Kerberos is an authentication scheme, not a password database.

Yes, it's called AFS, and actually it's a much better network filesystem than SMB or CIFS (or NFS for that matter).

Gah! Why, oh why would you want to re-implement SMB for Windoze?!?!?!

M$ has already got the most compatable (in the bug-for-bug sense) implementation of SMB. If you're being bitten by the high cost of client access licenses, then just implement Samba.

And if you want a better and more secure distributed filesystem for Windoze, then why not just implement AFS?

Here's something to take a look at- OpenAFS is an interesting filesystem that my school uses on its linux machines to allow for distributed and redundant file storage. This seems like it could be a good option for the distribution and replication of data.

More information is available at http://www.openafs.org

• Heimdal Kerberos 5
• KTH Kerberos 4

AFS is a really cool distributed filesystem and is used widely at many universities, I would like to see it used more in enterprise enviroments.

A good free AFS implementation is Arla. Another one is, as a previous poster pointed out, OpenAFS

You might try looking at OpenAFS. It has many of the properties that you're wishing for above.

AFS is good. The volume management is great, and you get real access control lists with groups. How about moving a users home directory to a different server, while the user is logged in? It's completly transparent. Or how about letting people create their own groups? That is useful. And there's proper authentication.

Random advice:

• Use Heimdal Kerberos 5 KDCs (plural for redundancy). Do not use the kaserver that comes with AFS.
• Put Heimdal and KTH-KRB (kerb 4) on all clients.
• Use OpenAFS servers.
• Use OpenAFS clients for Solaris, and Arla AFS clients for Linux 2.2.x. For Linux 2.4.x, OpenAFS clients might work better. I don't know, and probably it depends.

The latest OpenAFS client work really well in the latest versions of Windows, including XP.

Hell yeah
OpenAFS baby!

Rather, the needs of the Linux user is secondary to the needs of IBM's R&D. File systems that most Linux users have never heard of such as GPFS and Episode are accepted as valid file systems for IBM backup while more frequently used file systems such as Ext3 and xfs are ignored. Even more common true blue file systems such as jfs and AFS are skipped by the IBM backup "solution."

So... IBM is now enlisting the help of Red hat? So what?! At the end of the day, will I be able to restore the latest files from my Red hat v7.2 Ext3 fs which *should* have been backed up to TSM? Will Red hat be able to assist me in getting TSM running on a pSeries F50 running Linux?

The bottom line is that several departments of IBM such as Tivoli are still treating Linux as an expiermental operating system (not production) and treating IBM R&D as the only supported users. Real users, production users of ext3, xfs, jfs and afs as opposed to users of expiermental file systems are finding that True Blue does not care about the integratity of their daily incremental backups. Those that listen to Red hat about the advantages for a non-destructive upgrade to Ext3 during an upgrade to v7.2 will still find that the same file systems that used to back up fine before the upgrade are now being purposily ignored. Users that listen to IBM DeveloperWorks that JFS is now at v1.0 and is production ready are also stuck in the same sinking ship. And while YellowDog Linux runs fine on some pSeries RS/6000s, Tivoli has yet to provide a single client for Linux PPC.

So, now that Red hat is contracted with IBM, what type of improvement in support for IBM departments such as Tivoli should we expect? NONE. True Blue PATHETIC support. It isn't up to Red hat to get Tivoli support into shape, it is up to IBM and they continue to do a half ass job of it. I'm putting in just as much work, if not more, in monitoring TSM failling backups as I did when running ADSM v2 under Linux emulation of SCO. Nothing has changed and it is still up to the individual Linux users to make choosen true blue "solutions" truely "work."

Give me the source code to the TSM client. Then we can discuss your "support" options. Until then, IBM is the last company you want to do business with for Linux. "LOVE-PIECE-LINUX" isn't going to get your files back when you figure out that your Red hat v7.2 server was never backed up since you upgraded! "eServers from IBM running Linux" will NOT save you a bundle of money when you need to recreate all your lost work that wasn't backed up since you upgraded to Red hat v7.2.

Backups are a *BASIC* part of supporting a Linux server. Until you get that part right, all that is being done is hot-word compliant marketting, not *support*.

If your home computer is online 24/7 (which is presumably is if you're on broadband) t's cooler to use SAMBA, AFS (or here), Coda, InterMezzo, NFS, or the unfinished Lustre. If you're not big on effort, set up an http or ftp (or gopher!) server. That way, you have an automatically up-to-date menu of your mp3s, where you can access all your music any time you can connect to the 'Net.
This box is just itching to be a Coda server.

AFS for linux exists in both a Transarc (read: IBM) version and as OpenAFS which is a fork off the transarc client source.