.

bigfile/_file_zodb.pyx

@@ -22,7 +22,8 @@
 # cython: language_level=2
 # distutils: language=c++
 
-"""XXX"""
+"""Modules _file_zodb.pyx complements file_zodb.py with things that cannot be
+implemented in Python."""
 
 from __future__ import print_function, absolute_import
 

bigfile/file_zodb.py

@@ -97,7 +97,7 @@ To represent BigFile as ZODB objects, each file block is represented separately
 either as
 
     1) one ZODB object, or          (ZBlk0)
-    2) group of ZODB objects        (ZBlk1)     XXX wcfs loads in parallel
+    2) group of ZODB objects        (ZBlk1)
 
 with top-level BTree directory #blk -> objects representing block.
 
@@ -112,7 +112,7 @@ For "2" we have
     - low-overhead in terms of ZODB size (only part of a block is overwritten
       in DB on single change), but
     - high-overhead in terms of access time
-      (several objects need to be loaded for 1 block)
+      (several objects need to be loaded for 1 block(*))
 
 In general it is not possible to have low-overhead for both i) access-time, and
 ii) DB size, with approach where we do block objects representation /
@@ -122,6 +122,10 @@ On the other hand, if object management is moved to DB *server* side, it is
 possible to deduplicate them there and this way have low-overhead for both
 access-time and DB size with just client storing 1 object per file block. This
 will be our future approach after we teach NEO about object deduplication.
+
+
+(*) wcfs loads ZBlk1 subobjects in parallel, but today ZODB storage servers do
+    not scale well on such highly-concurrent access.
 """
 
 # ZBigFile organization