On Tue, 22 Nov 2005, Joe Buehler wrote:
- AFS has a single namespace: the content of /afs is the same on all machines (or under whatever drive letter(s) you pick for Windows).
The biggest win to me over NFS is a single global namespace which is *location independent*. The location independence is pretty crucial. With NFS you eventually hit a limit where a single fileserver becomes unweildy and it may take weeks to do a backup and restore. It is better to split your data into multiple smaller fileservers, but all the options of how to manage this are bad with NFS and are not location independent. So inevitably what occurs is a system of managing symlink farms which point to paths containing the mountpoints of the NFS servers, to try to produce location independence on top of NFS. This is just a cheap hacky way of producing something like AFS's VLDB on top of NFS (mapping paths to locations via a symlink 'database'). It inevitably fails. AFAIK, NFSv4 is simply better at clustering and better at doing autofs/automounter and does not have any support for a location database and therefore it isn't comparable to AFS and will therefore inherantly fail to scale.
Replication also gets highly amusing with NFS. With two replicas you may be okay, but when it comes to multiple replicas in multiple datacenters and the requirement that all of them be up-to-date, then you usually wind up with N single-points-of-failure on replication. Queueing writes and having filservers be able to do "journal replays" when they come up in order to catch up can be done, but it is complicated and usually you'll get corruption that creeps in over time so that your replicas aren't truely replicas.
One other comment is that AFS can be a truely global and location independent filesystem, but you do need to abandon the /afs/<cellname> convention and dynroot. Otherwise you are merely reinventing location dependence and/or autofs at the level of cells rather than fileservers. I don't know why the AFS community continues to support this convention which breaks location independence. *shrug*.
_______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
