[OpenAFS] Linux Weekly News article comments
Christopher D. Clausen
Fri, 16 Dec 2005 12:36:10 -0600
Alf Wachsmann wrote:
> Someone care to write a clarification:
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
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
> 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
> 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
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.
Christopher D. Clausen