.

wcfs/notes.txt

@@ -55,6 +55,22 @@ of a file this way would be potentially slow.
 -> we took the approach where we send invalidation to client about a block
 lazily only when the block is actually accessed.
 
+XXX building δFtail lazily along serving fuse reads during scope of one
+transaction is not trivial and creates concurrency bottlenecks if simple
+locking scheme is used. With the main difficulty being to populate tracking set
+of δBtree lazily. However as the first approach we can still build complete
+tracking set for a BTree at the time of file open: we need to scan through all
+trees but _not_ buckets: this way we'll know oid of all tree nodes: trees _and_
+buckets, while avoiding loading buckets makes this approach practical: with
+default LOBTree settings (1 bucket = 60·objects, 1 tree = 500·buckets) it will
+require ~ 20 trees to cover 1TB of data. And we can scan those trees very
+quickly even if doing so serially. For 1PB of data it will require to scan ~
+10⁴ trees. If RTT to load 1 object is ~1ms this will become 10 seconds if done
+serially. However if we load all those tree objects in parallel it will be
+much less. Still the number of trees to scan is linear to the amount of data
+and it would be good to address the shortcoming of doing whole file index scan
+later.
+
 
 Changing mmapping while under pagefault is possible
 ===================================================