Alf Wachsmann wrote:
Someone care to write a clarification:
http://lwn.net/Articles/162720/

On this list? Or posting there? I don't really want to create an account. Someone else can post the below if they wish... Or, its probably best if this list agrees on some points and then posts a link back to the list discussion or else it'll end up as just the opinion of some individual.

Its too bad the wiki is still down, b/c a "common misconceptions" page seems like a good use for it.

-----

From the article...
The only problem I have with it is that I have to
use Debian Testing versions because the
Debian Stable version sucks in a few different ways.

Thats not true. The Debian stable packages work just fine on x86, alpha, and powerpc at least. http://www.acm.uiuc.edu/~cclausen/props.jpg to whomever made the packages.

Also the afs volume size limit is 8 gigs,
which took me a while to figure out. It'll let you
copy more then 8 gigs to a volume, people have had
upwards of a 150 gigs and such.. but begins to crap
out in unusual manners and stuff like volume
management and that sort of thing gets funky.

Uhh, there is no 8GB volume size limit. Larger volumes do cause occational problems actually moving them around though, but that is dependant upon hardware.

OpenAFS has some funky not-quite-Posix-compatable
file system ACLs. They are more flexible then posix
for stuff, but you get situations. For instance normal
Unix file system commands work with ownershipe
read-write-execute permissons, but group and world
permissions are ignored.

That is somewhat true. There is also the fact that ACLs are per-directory, not per file.

OpenAFS doesn't support some special files like
named pipes and such, which break odd programs
like totem or whatnot that want to build pipes
and sockets in your home directory

Also true. Although having special files in one's home directory a rare thing, I did have some issues with screen on AIX. Had to compile it with some other options to get it to put things in non-AFS.

Also when using Gnome with OpenAFS you have the FAM
deamon, which will take a crap and cause 100% cpu usage
in a seemlingly random fasion and cause nautilus to puke

This is most certainly true. In Debian testing / unstable, the gnome packages are dependant upon FAMd being installed. You can't remove it without removing gnome as well. As a workaround, I simply do update-rc.d -f fam remove to prevent fam from being started at boot. Nothing terrible has happened yet. (I don't use gnome myself, so I don't know what this does in the long term...)

However Window's AFS support realy sucks

This is most certainly false. The Windows clients tend to recover quicker and better from changed network settings, respond quicker to file server outages, and IMHO are much easier to deal with b/c they aren't hard to stop and restart to make config changes. The Windows clients do seem to have slower max transfer speeds, but I think that is more b/c of Windows than b/c of AFS.

(and I think that OS X's support is still subpar also.)

This is true, but it is being worked on. I blame Apple for constantly changing things.

SAMBA rocks

Pfft. IMHO, SAMBA is not production ready and is a quick hack used to serve files between Windows and Linux. Now, if and/or when samba supports client access to domain MS Dfs roots, I might reconsider that statement.

-----

It seems that this was written by someone who mostly uses Linux. In the real world, there are other OSes that people need to use. I also assume that this author has never attempted to setup samba on AIX or IRIX or some other not-so-popular platform and ran into all kinds of problems. (Or ever rendered the ENTIRE campus domain useless with a misconfigured samba machine :-)

That guy is also comparing network, distributed, and cluster filesystems as if they all served the same purpose. One can't have users access a clusterfs through the internet and most ISPs already block the ports that CIFS needs. The remote access and real per-user authentication is a HUGE benefit of AFS over other filesystems.

<<CDC
--
Christopher D. Clausen
[EMAIL PROTECTED] SysAdmin
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to