Commit d1a579b2 authored by Kirill Smelkov's avatar Kirill Smelkov

X another example of wc1 invalidation bug related to ZBlk pinning to #blk

This one is less exotic compared to format changes rewrite.
parent 48eb692f
......@@ -149,8 +149,13 @@ class ZBlkBase(Persistent):
# ZBigFile.storeblk() can change type of stored zblk - i.e. it rewrites
# ZBigFile.blktab[blk] with another ZBlk created anew.
# another example: a block may initially have no ZBlk attached (and
# thus it reads as 0). However when data in that block is changes - a
# new ZBlk is created, but information that block data has to be
# invalidated is NOT correctly received by peers.
# FIXME this assumes that ghostified ZBlk will never be removed from live
# objects cache (cPicleCache). However, since ZBlk is not doing
# objects cache (cPickleCache). However, since ZBlk is not doing
# anything special, and it actually becomes a ghost all the time (e.g.
# ZBlk0.loadblkdata() ghostifies itself not to waste memory), this
# assumption is NOT correct. Thus, if a ghost ZBlk will be removed from
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment