Linked by Thom Holwerda on Thu 15th Jun 2006 15:36 UTC, submitted by user123
NetBSD "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."
Order by: Score:
Marvelous
by shadow_x99 on Thu 15th Jun 2006 16:34 UTC
shadow_x99
Member since:
2006-05-12

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!

Reply Score: 2

What about RPCSEC_GSS?
by EmmEff on Thu 15th Jun 2006 16:41 UTC
EmmEff
Member since:
2005-09-16

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.

Reply Score: 2

RE: What about RPCSEC_GSS?
by EmmEff on Thu 15th Jun 2006 21:11 UTC in reply to "What about RPCSEC_GSS?"
EmmEff Member since:
2005-09-16

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.

Reply Score: 3

It sure is different
by JacobMunoz on Thu 15th Jun 2006 17:01 UTC
JacobMunoz
Member since:
2006-03-17

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

Reply Score: 2

but...
by broken_symlink on Thu 15th Jun 2006 18:37 UTC
broken_symlink
Member since:
2005-07-06

can you setup diskless systems using afs? i have yet to find a file system that you can do that with other than nfs.

Reply Score: 2

RE: but...
by h_t_r on Thu 15th Jun 2006 19:48 UTC in reply to "but..."
h_t_r Member since:
2006-02-02

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.

Reply Score: 4

RE[2]: but...
by EmmEff on Thu 15th Jun 2006 20:18 UTC in reply to "RE: but..."
EmmEff Member since:
2005-09-16

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

Reply Score: 5

RE[3]: but...
by derekmorr on Sun 18th Jun 2006 20:00 UTC in reply to "RE[2]: but..."
derekmorr Member since:
2005-09-25

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.

Reply Score: 1

RE: but...
by koen on Fri 16th Jun 2006 01:36 UTC in reply to "but..."
koen Member since:
2005-11-15

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

Reply Score: 2

2GB Limit
by Murrell on Thu 15th Jun 2006 20:57 UTC
Murrell
Member since:
2006-01-04

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.

Reply Score: 2

RE: 2GB Limit
by derekmorr on Fri 16th Jun 2006 03:44 UTC in reply to "2GB Limit"
derekmorr Member since:
2005-09-25

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.

Reply Score: 3

porcel
Member since:
2006-01-28

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.

Reply Score: 2

afs is nice
by koen on Fri 16th Jun 2006 01:22 UTC
koen
Member since:
2005-11-15

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

Reply Score: 3

nifty
by macisaac on Fri 16th Jun 2006 02:39 UTC
macisaac
Member since:
2005-08-28

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

Reply Score: 2

apples/ oranges
by xxmf on Fri 16th Jun 2006 15:20 UTC
xxmf
Member since:
2006-06-15

I may be off base here but afs has different semantics (coherency) and thus 'can' overcome
certain deficiencies that nfs has....

Reply Score: 2