[OpenAFS] Extremely poor create & delete performance - revisit

Paul Blackburn mpb@est.ibm.com
Wed, 29 Jan 2003 07:44:52 +0000


Hello Robin,

There is a way for AFS deletes to be much faster than either NFS or 
local filesystem.
Here's what you do:

a) Create a volume. Let's call it "superfastdelete"
     vos create $fileserver2 superfastdelete
b) Mount the new volume
     cd /afs/.@cell
     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".
--
cheers
paul                               http://acm.org/~mpb

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 
>improving performance.
>
>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):
>
>http://www.physics.ucsb.edu/~rhy/bonnie_results.html
>
>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 
>clients.
>
>http://www.physics.ucsb.edu/~rhy/postmark_results.txt
>
>All benchmark results have AFS encryption turned off.
>
>Any more ideas?
>
>cheers,
>Robin Yamaguchi
>
>
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info
>  
>