.

bigfile/file_zodb.py

@@ -27,10 +27,10 @@ data is changed, δ(ZODB) is proportional to δ(data).
 
 Being BigFile ZBigFile can be memory-mapped. Created mappings provide lazy
 on-read block loading and on-write dirtying. This way ZBigFile larger than RAM
-can be accessed transparently as if it was a regular array in RAM. Changes made
-to ZBigFile data will be either saved or discarded depending on current
-transaction completion - commit or abort. The amount of ZBigFile changes in one
-transaction is limited by available RAM.
+can be accessed transparently as if it was a regular data in program memory.
+Changes made to ZBigFile data will be either saved or discarded depending on
+current transaction completion - commit or abort. The amount of ZBigFile
+changes in one transaction is limited by available RAM.
 
 ZBigFile does not weaken ZODB ACID properties, in particular:
 
@@ -125,6 +125,8 @@ will be our future approach after we teach NEO about object deduplication.
 
 # ZBigFile organization
 #
+# TODO add top-level overview
+#
 # As file pages are changed in RAM with changes being managed by virtmem
 # subsystem, we need to propagate the changes to ZODB objects back at some time.
 #
@@ -145,7 +147,7 @@ will be our future approach after we teach NEO about object deduplication.
 # between virtmem subsystem and ZODB, and virtmem->ZODB propagation happens only
 # at commit time.
 #
-# Since, for performance reasons, virtmem subsystem is going away and BigFiles
+# Since, for performance reasons, virtmem subsystem is going away and BigFiles      XXX kill
 # will be represented by real FUSE-based filesystem with virtual memory being
 # done by kernel, where we cannot get callback on a page-dirtying, it is more
 # natural to also use "2" here.