Edward Moy wrote:
Yes, it is true that fast read performance should be a higher priority. But if I want to read a 1 GB file from AFS, I have to write it there in the first place.
Look at the times to read that same 1 GB file:
nfs 0.050u 18.050s 2:25.59 12.4%
afs 0.5GB cache 0.030u 10.300s 2:29.26 6.9%
afs 2GB cache 0.030u 11.250s 2:32.67 7.3%
Within the normal fluctuations in the network itself, AFS is very close to raw NFA, for first-time reading. But also note that even when the cache is smaller than the file, one does not see the poor behavior exhibited in the write case.
Hi Edward,
I think you have succintly made the point that you need to size your AFS cache appropriately for your workload. If you plan on working with 1gb files often and writing 1gb files into /afs/@cell/$whatever/ then you better configure a big enough AFS cache. I think that "cache thrashing" is similar to "page thrashing" in virtual memory operating systems. It is a situation that occurs when there is not enough resource allocated (eg cache too small) for the workload applied to it. Remember also that with AFS, you have a choice of disk cache or RAM cache. So if you have enough installed RAM, you will see faster access using AFS RAM cache (than using disk cache).
It takes 2 1/2 minutes to read the file, and 4 minutes to write it when there is enough cache. But as a user, when that goes up to 10 minutes, and uses 80% of the processor, my first reaction would be that something is wrong.
From other comments I've seen, it appears that this is "expected" (though hopefully not desirable) behavior. I just wanted to point out that there is room for improvement in this area.
You are absolutely right to point this out. If there is something "not working right" with AFS write function then this is a good place to discuss it and propose solutions. -- cheers paul http://acm.org/~mpb _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
