看板 DFBSD_bugs 關於我們 聯絡資訊
:> :> Definitely worth uploading. : :Uploaded as ~y0nean1/crash/{kern,vmcore}.4 on leaf. This helps a lot. I think I see what is going on finally, the other fixes have made it more apparent. What is happening is that the record deletion updates the mirror_tid in the B-Tree recursively going upwards, during which the original cursor is unlocked. The unlocked cursor winds up getting moved to a parent (internal) B-Tree node which is fine, but then a new record is inserted before the cursor is re-locked. Because the cursor got moved to an internal node the new insertion can get in between the cursor's position and the original range that was being scanned. The unexpected record then causes the assertion. I'll have another patch for you to try in a day or two. I have several solutions in mind but I want to try to find the one that is minimally invasive for the release. Basically either (1) Unlocked cursors which have to be moved into a parent node can't track and require a relookup. Or (2) when moving an unlocked cursor into its parent the cursor's index in the parent must also be bumped to prevent insertions from being able to wiggle their way in. -Matt Matthew Dillon <dillon@backplane.com>