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.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: [...]
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 balancedi 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?)?
% xstat_cm_test localhost -once 0 | egrep 'osi_UFSOpen|osi_Close'
344299 osi_UFSOpen
344298 osi_Close
p7sPtrMlNIeEj.p7s
Description: S/MIME cryptographic signature
