vancer@oakhill.sps.mot.com (Vance R. Fields III) (06/19/91)
I've noticed that, during the course of my last nine
major headaches of which NFS has been responsible for
eight, the topic of AFS (Andrews File System) has been
appearing with increasing regularity, and I just could
not help but imagine that a more efficient scheme's time
had come.
Today, while perusing the unix.wizards postings, I saw
at least one out-and-out recommendation for the use of
AFS, and did not have much trouble convincing myself
that both the user community as well as the admin group
stood to benefit from an inquiry into the yeas and nays
of AFS vs NFS (presuming, of course, that this comparison
is a valid one).
I sure would appreciate it if anyone out there who has an
ideological/operational familiarity with AFS as it relates
to NFS would kindly email me or (should this info prove
beneficial to a sufficient number of readers) post their
contributions to this group.
Thanks, in advance,
Vance
"As for me and my house, we will serve the Lord."
Joshua 24:15
/**************************************************************
* Vance R. Fields III | Motorola SPS *
* ----- *
* System Administrator | Austin, TX 78735 *
* | *
**************************************************************/jik@cats.ucsc.edu (Jonathan I. Kamens) (06/19/91)
(Vance: The Distribution line of your posting, "comp.unix.admin info.sun-managers", was invalid.) This seems like a subject that is of general interest, so I'm posting my response rather than mailing it. A while back, I recommended AFS in a short tangent in one of my postings, saying that it had a lot of advantages, but that I "wouldn't go into the problems" in my posting. Someone wrote back and asked me to go into the problems :-). I've appended to the end of this message the conversation I had with him (with names omitted, since it's E-mail, after all) in E-mail. It sheds light on many of the strengths and weaknesses of AFS, as well as how it compares to NFS. I suspect that TransArc has PR documentation which discusses the advantages and disadvantages (well, maybe their PR documents don't discuss the disadvantages :-) of AFS, but I don't know what the E-mail address is to ask for it. I'm currently finding out what that address is, and will post it once I get it if there is sufficient interest in this thread. Oh, by the way, it's "AFS", not "A.F.S." That's official TransArc party line. Sort of like how it's "the X Window System," not "X Windows." :-) -- Jonathan Kamens jik@CATS.UCSC.EDU -- In article <1991Apr29.042058.2460@athena.mit.edu> you write: [...] > Obviously, you can see that I think AFS does do some things right. I won't >go into the problems I think it has. :-) I wish you would; we will be getting AFS soon, and I would like to know what to avoid, or expect AFS not to do. (but I understand if time, or other constraints prvent you from doing so) ************************* Here are a few that I can think of, right off the top of my head: 1) It doesn't have per-file ACLs, just per-directory ACLs. I think this is fixed in AFS 4.0, but I'm not certain. 2) It does not deal well at all when the partition on which the AFS cache resides fills up. It should be smart enough to notice that the partition has filled up, and reduce the size of the AFS cache accordingly. 3) Access control for administrative functions is limited. For example, if I make modifications to the read-write copy of a locker which I administrate, I should be able to "release" the volume, which is the operation that copies it to the read-only versions of the volume (which is what people usually access by default). However, right now, only system administrators can perform volume releases. This function, and other similar functions, should have more fine-grained control. 4) RCS locking doesn't work properly. Since the owner of a file is irrelevant as long as the owner-bits give write permission, if one user checks out an RCS file locked, another user can write to it anyway. This might be fixed in 4.0 with the per-file ACL's. 5) It still deals a little bit badly with the partitions filling up on the server, although it's gotten much better at it. 6) The AFS server processes can't be killed. The AFS client workstation processes can't be killed. 7) It works really badly (in some cases, not at all) over slow network links. I suspect that 4.0 will fix many of these problems, although I don't know that for certain or know when 4.0 will be released. Also, even as it is now, the advantages far outweigh any problems I can think of. Choosing AFS over NFS is, in my opinion a big win. Do you use diskless workstations? Since AFS uses a local cache, I'm not sure if it works on diskless workstations. ************************* "Jonathan I. Kamens" said: >Here are a few that I can think of, right off the top of my head: Thanks! [...] > 4) RCS locking doesn't work properly. Since the owner of a file is >irrelevant as long as the owner-bits give write permission, if one >user checks out an RCS file locked, another user can write to it >anyway. This might be fixed in 4.0 with the per-file ACL's. I'm not sure what this means. If an RCS ,v file is owned by UID RCS (RCS can operate that way, right? We don't do that yet, so I am a bit fuzzy on details) can someone user baz do a check in? > 5) It still deals a little bit badly with the partitions filling up >on the server, although it's gotten much better at it. Does this mean writes fail silently, and/or files get truncated? What about filespace quota's? [...] > I suspect that 4.0 will fix many of these problems, although I don't >know that for certain or know when 4.0 will be released. Also, >even as it is now, the advantages far outweigh any problems I can >think of. Choosing AFS over NFS is, in my opinion a big win. Well, you have alot more cables to go over then we do... I hope it turns out this way for us as well. > Do you use diskless workstations? Since AFS uses a local cache, I'm >not sure if it works on diskless workstations. Less then 20 out of the 600 are diskless (unless you count the X-Terminals). 10 of them are likely to stop being diskless workstations within a year. ************************* RCS: In AFS directories, the *owner* of a file is ignored. The only thing that matters is whether the owner write and read bits are set. Therefore, if I check out a file locked into an AFS directory, the file has its owner write bit set, which means that *anybody* with write access to the directory can modify it. Cache partition filling: When the cache partition fills up, programs start failing, but they find out they've filed (no data is silently lost). The reason this behavior is suboptimal is because it doesn't have to happen. Let me explain.... AFS has a local cache in which it keeps local copies of files. The cache is limited in size by a settable parameter. For example, I can tell AFS to keep its cache size below 5 meg, and it will do so. The problem is that it should *also* be smart enough that if the partition on which the cache resides fills up, it should reduce its maximum cache size, removing files from the cache, until the partition is no longer full. It *is* possible for it to do this, but it doesn't. I've solved this problem by putting my cache on a separate filesystem with nothing else that grows on it, so nothing will ever take up AFS's space. But it shouldn't be necessary to do this. Quotas are a completely separate issue. They are handled on a per-volume basis, and work quite well. In addition to quotas, you can set the minimum size of a filesystem, which means that you can reserve an amount of space on a filesystem for a volume, and there will always be at least that much space on the filesystem for that volume. Nifty.
jik@cats.ucsc.edu (Jonathan I. Kamens) (06/19/91)
Here's the response I got to my query about the address to use for queries to Transarc about AFS: |> You can direct people to afs-sales@transarc.com, which gets directed to |> our marketing staff. This address also works for requests for marketing |> literature or general information about AFS. -- Jonathan Kamens jik@CATS.UCSC.EDU