Zach Brown d16b18562d scoutfs: make sure forest sees dirty log tree
Item writes are first stored in dirty blocks in the private version of
the mount's log tree.  Local readers need to be sure to check the dirty
version of the mount's log tree to make sure that they see the result of
writes.  Usually trees are found by walking the log tree items stored in
another btree in the super.  The private dirty version of a mount's log
tree hasn't been committed yet and isn't visible in these items.

The forest uses its lock private data to track which lock has seen items
written and so should always check the local dirty log tree when
reading.  The intent was to use the per-lock static forest_root for the
log tree to record that it had been marked by a write and was then
always used for reads.

We used storing the forest info's rid and testing for a non-zero
forest_root rid as the mechanism for always testing the dirty log root
during read.  But we weren't setting the forest info rid as each
transaction opened.  It was always 0 so readers never added the dirty
log tree for reading.

The fix is to use the more reliable indication that the log root has
items for us by testing the flag that all the bits have been set.  Then
we're also sure to always set the rid/nr of the forest_info record of
our log tree, and the per-lock forest_root copy of it whenever we use
it.

This fixed spurious errors we were seeing as creates tried to read
the item they just wrote as memory reclaim freed locks.

Signed-off-by: Zach Brown <zab@versity.com>
2020-04-29 12:02:47 -07:00
Description
No description provided
9.1 MiB
Languages
C 86.2%
Shell 10.2%
Roff 2.5%
TeX 0.8%
Makefile 0.3%