On 11/26/2014 11:07 AM, Jan Iven wrote:
On 11/26/2014 10:51 AM, Hans-Werner Paulsen wrote:
Hello,
this is on Linux 3.14.8 x86_64, and OpenAFS 1.6.9. The machine is
running normally for several months, and then accessing a specific R/O
volume (e.g. ls -lR <large_volume>) becomes slow. Accessing the R/W
version of this volume works normally. Accessing other R/O volumes,
which have the same size and number of files, works normally. Accessing
the R/O version of the problem volume from other clients works normally.
The command "fs flushall" does not solve the problem. The (second) "ls
-lR" command needs 10 seconds on the R/O, and 2 seconds on the R/W
version of this volume.
Accessing the R/O version from other fileservers (using fs
setserverprefs) does not change anything.
Checking the machine I see more than 5 million of afs_inode_cache slab
entries. Is this normal? Any hint how to proceed?
suggest to check for local disk errors (incl SMART reallocation) on
the partition hosting your AFS cache.
Cheers
jan
Thank you for your help, but:
No, there are no local disk errors. We had the same problem (but did not
further analyse it) a few months ago. Rebooting solved that. And if
there is a failure with the local disk, we should see slow performance
with other volumes, too.
HW
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
