mirror of
https://github.com/versity/scoutfs.git
synced 2026-08-22 15:16:51 +00:00
e227c6446ee8cf032432a821307f6598335b9a66
The btree writes its blocks to a fixed ring of preallocated blocks. We added a trigger to force the index to advance to the next half of the ring to test conditions where the cached btree blocks are out of date with respect to the blocks on disk. We have to be careful to only advance the index once all the live blocks are migrated out of the half that we're about to advance to. The trigger tested that condition. But it missed the case where the normal btree block allocation *just* advanced into the next ring. In this case the migration needs to occur to make it safe to advance *again* to the previous half. But it missed this case because the migration keys are reset after we test the trigger. This resulted in leaving live btree blocks in the half that we advance to and start overwriting. The server got -ESTALE as it tried to read through blocks that had been overwritten and hilarity ensued. This precise condition of having the trigger fire just as we wrapped was amazingly caught by scoutfs/505 in xfstests. Signed-off-by: Zach Brown <zab@versity.com>
Description
No description provided
7.5 MiB
Languages
C
86.4%
Shell
9.9%
Roff
2.5%
TeX
0.8%
Makefile
0.4%