“Network attached storage has been known to Unix users for a very long time with NFS. NFS is reliable, performs well on the performance front, but it is infamous for its security. The biggest problem with NFS is that the client is responsible for controlling user file access. The NFS server just accepts file system operations on behalf of a given UID and enforces nearly no control. NFS require you trust your clients, something that may not be adequate. Andrew File System is an alternative network file system. In this interview, I ask Ty Sarna about his experience with AFS. Ty Sarna has been an AFS user since 1992 and is a NetBSD developer since 1998.”
AFS: Network Filesystem Beyond NFS’s Weaknesses
About The Author
Follow me on Twitter @thomholwerda
2006-06-15 9:11 pmEmmEff
Replying to my own post…
I just looked it up. According to the co-designer of RPCSEC_GSS (Mike Eisler), Secure NFS using Kerberos 5 has been available since 1998.
I’ve been working with AFS for almost a year, and after the initial setup – it really is a nice system. My only peeves are with the Mac ‘Finder’ integration with the system, as there still seem to be some minor issues. Sometimes it appears that Finder is ‘lost’ and hangs somewhat fatally. It’s not often, but if your credentials don’t allow you to enter a folder you can get into some minor trouble getting items to display again in the Finder windows. I know there are extra file permissions (I believe there are 8 (a-h) custom attributes, four directory permissions, and three normal Unix ones (rwx)) and some of these don’t seem to be available in Finder as of yet (not that they do in any gui as far as I know), so there is some integration compatability to be done. It does get implemented somewhat differently on platforms (like Windows which assignes a drive letter to it, versus Mac and Linux which mount it at /afs) so it’s not completely universal – but I doubt there’s a happy way to avoid drive letters in Windows, so that’s only a minor difference. Give this system a little more time to incorporate better platform integration and it could get some real heavy public use (which I hope wouldn’t be too detramental to the server system).
can you setup diskless systems using afs? i have yet to find a file system that you can do that with other than nfs.
2006-06-15 7:48 pmh_t_r
root_fs using AFS? no.
AFS is powerfull, but not for all uses.. a great part of it features is useless to the common geek/sysadmin..
NFS is integrated in every *nix and do almost everything.. rootfs, fast file transfer, coffee…
NFSv4 is _the_ network filesystem: secure, faster, reliable… maybe perfect.
2006-06-15 8:18 pmEmmEff
NFSv4 will be _the_ network filesystem as soon as everybody supports it and LIPKEY is implemented across the board (eliminating the need for the Kerberos security infrastructure).
2006-06-18 8:00 pmderekmorr
There are a great many features that NFSv4 does not support, such as read-only replicas, a unified namespace, volume migration, etc. NFSv4 is not a replacement for AFS.
2006-06-16 1:36 amkoen
yes, i have an embedded dhcp+http/ftp-proxy which pxeboots a ramdiskkernel that sets up ipsec+afs and fetches userland from compact flash, solely for putting logs and some configuration files which i need to change without any hassle, on a centralized afs cache. it’s sheer convenience
I looked at AFS a few years ago when I was deploying the current NFS infrastructure, and it’s main problem seemed to be that it had a 2GB file size limit. Does anyone know if this has been fixed? If so, it might be time to take another look.
2006-06-16 3:44 amderekmorr
It’s been fixed on most Unix platforms (Linux, Solaris, AIX and HP-UX; I don’t know about Irix). Windows still has the 2 GB file limit.
AFS seems very interesting and powerful, but maybe a bit overdesigned. I wish someone with a clue would bring the necessary glue and GUI to make configuring something like AFS effortless and simple for overworked sysadmins.
I have meant to look into AFS and Coda for years, but I simply have not had the time.
i run openbsd arla clients + netbsd openafs server for a small year at home, and it just works; it’s a bit slow though on 100mbit for music and movies around a whole house with many clients, but you can tune local caches somewhat (“buy more ram” – afs is not very tunable). openbsd has a very nice openafs server and client lkm for a while now, which i’ve yet to try. i used gentoo openafs clients in the same setup for about a month, and it never failed either. for easy-access storage, i really like the combination of netbsd’s cgd, ufs2 and afs… netbsd has coda in ports too, i think, but coda seems like some neverending university hobby horse.
the downside of any afs implementation is the whole kerberos mess – though it’s nice it works out-of-the-box on open/netbsd
since I’m one of the admins at CMU, it does hearten me gladly to see an article about AFS here on osnews 😉
(no, I’m not one of the smart folk who actually invented the thing (haven’t been working there _that_ long.) but it is what I live in day in day out at my work, unsurprisingly it is a very core part of our infrastructure, brilliant stuff really once you get over the initial learning curve.)
I may be off base here but afs has different semantics (coherency) and thus ‘can’ overcome
certain deficiencies that nfs has….
I’ve been using AFS at my current job for 1 year now and I must say that I am really impressed with the quality of the FileSystem. If you ever thought that NFS was fast, you never used AFS! Once you go AFS, you never go back!
It’s still slower than hard-drive access, but it’s the next best thing!
NFS on Solaris has had RPCSEC_GSS support for several years now. Support on Linux has been added recently and does work. Of course, it requires the addition of a Kerberos KDC on your network but RPCSEC_GSS does add much-needed security to NFS.