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): ...@@ -149,8 +149,13 @@ class ZBlkBase(Persistent):
# ZBigFile.storeblk() can change type of stored zblk - i.e. it rewrites # ZBigFile.storeblk() can change type of stored zblk - i.e. it rewrites
# ZBigFile.blktab[blk] with another ZBlk created anew. # 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 # 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. # anything special, and it actually becomes a ghost all the time (e.g.
# ZBlk0.loadblkdata() ghostifies itself not to waste memory), this # ZBlk0.loadblkdata() ghostifies itself not to waste memory), this
# assumption is NOT correct. Thus, if a ghost ZBlk will be removed from # 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