[OpenAFS-devel] truncating dcache entries "by hand", why not use afs_DiscardDCache

[Rainer Toebbicke]

Trying to understand a strange problem involving files bigger than the cache 
that were overwritten (as opposed to deleted/recreated), I noticed the 
following: afs_TruncateAllSegments() truncates all dcache entries but leaves 
them around, attached to the file, but empty.

While I see the point that in the common case of truncating a file in order to 
re-write it with roughly the same amount of data you might save a few cycles 
by simply "reusing" the previous entry, it creates additional strain when 
there is cache pressure and the files big:

the file in question was a 4GB DVD image, bigger than the cache, after the 
truncate hundreds of (empty) dcache entries remained in the cache. As globally 
segments had to be written out due to cache pressure, all those "obsolete" 
entries' DV numbers were busily updated in afs_StoreAllSegments.

My plan is to have afs_TruncateAllSegments place the entries on the "discard" 
list which will make the truncate happen in the background instead of 
synchronously, and reduce complexity a little bit. At the same time, make the 
unconditional truncate() in afs_GetDCache depend on f.chunkBytes: even the 
truncate of a zero byte file can take erratically long.

afs_GetDCache() has a bias for allocating new entries out of the "discard" 
list instead of the "free" list for writes (but not for reads). This is not 
intuitive so I wonder whether it is needed?

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel