[OpenAFS] Extremely poor create & delete performance - revisit
Wed, 29 Jan 2003 07:44:52 +0000
There is a way for AFS deletes to be much faster than either NFS or
Here's what you do:
a) Create a volume. Let's call it "superfastdelete"
vos create $fileserver2 superfastdelete
b) Mount the new volume
fs mkm superfastdelete superfastdelete
c) Re-sync the RO copies of your root.cell
vos release root.cell -verbose
d) Create how ever many files you want in /afs/@cell/superfastdelete/
OK, now this is the really high performance delete bit:
e) fs rmm /afs/.@cell/superfastdelete
vos remove $fileserver2 superfastdelete
OK, you probably want to say that I am cheating?
My point is that you seem to be focussing on a single aspect of AFS
and not on the bigger picture. You stated in your original post
here that you wanted to find reasons why you might choose
AFS over NFS.
I think you should look at other issues besides "slow deletes".
There are many more factors to think about when deciding
if a distributed filesystem suits your requirements.
If it is _really important_ that you can delete files quickly
then you should be considering what would be the most effective
delete mechanism and that may not be the obvious "rm $file".
Robin Yamaguchi wrote:
>Hi Ruby et al,
>We've discussed a little on the openafs-info mailing list in regards to
>create and delete performance for AFS. Being that we are in simular
>situaions as admins of AFS, I was wondering if you've made any progess in
>Some suggested on the list that our performance issue might be related to
>network latency or other network-related problems. To test this, I
>installed an afs server and client on the same machine, ran bonnie and
>recieved the same results. I feel this is conclusive evidence that our
>lack of performance is a configuration issue. I've tried using ramcache,
>using all the client options in /etc/sysconfig/afs, changing my chunksize,
>yet all fail to result in any real performance gain.
>Again, I used bonnie++. While this benchmarking app has come into
>question in regards to how suitable it is for distributed file systems, I
>feel it still has merit in displaying my issue with AFS. I've updated my
>bonnie_results page to include testing AFS on a machine that is both
>server and client (named vanagon. robin results are client seperate from
>server), along with an assortment of different options that too are noted
>(but not very well documented):
>I've also posted my postmark benchmark results. robin <--> abrams is a
>dedicated AFS/NFS server to my linux desktop. shell <--> mcp was done on
>a NFS client that is in full production. We have less then a dozen NFS
>All benchmark results have AFS encryption turned off.
>Any more ideas?
>OpenAFS-info mailing list