--On Friday, April 15, 2005 07:55:37 PM -0400 chas williams - CONTRACTOR <[EMAIL PROTECTED]> wrote:

In message <[EMAIL PROTECTED]>,Chaskiel M
Grundman writes:
afs does not hold cache files open. Most calls to afs_CFileTruncate
are=20 immediately followed by afs_CFileClose (which is osi_UFSClose,
which calls=20 release_file).

that's not my impression. /cache is an ext2 filesystem: [...]
I'm not claiming there isn't a problem. I'm claiming that whatever problem exists is not preallocs that are not being discarded because of the truncate optimization.

i didnt include getcacheparms but it only thinks the cache increased by 1k
but in reality it went up by 8k.  isnt there a list of open/active cache
files (dcache slots?)?
afs holds one file open: the CacheItems file (on bsd's, it holds two files open: the CacheItems file and the VolumeItems file). That's it. other calls to afs_CFileOpen/afs_CFileClose are balanced

% xstat_cm_test localhost -once 0 | egrep 'osi_UFSOpen|osi_Close'
           344299 osi_UFSOpen
           344298 osi_Close

Attachment: p7sPtrMlNIeEj.p7s
Description: S/MIME cryptographic signature



Reply via email to