| Message ID | 20200406145905.112078-1-josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: fix improper generation setting in parent node | expand |
On 4/6/20 10:59 AM, Josef Bacik wrote: > With the delayed ref throttling patches I started getting a lot of > "parent transid mismatch" messages when running my snapshot+balance > torture test. This turned out to be because we will unconditionally set > the generation of a relocated tree block to the current transaction. > > This is generally true, but especially for mid-tree nodes we could have > cow'ed the block in a previous transaction, and only actually update > it's parents in a completely different transaction. Thus we end up with > a parent transid that is in the future of the actual block. Fix this by > using the generation for the extent buffer we're pointing to. > > Fixes: 5d4f98a28c7d ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") > Signed-off-by: Josef Bacik <josef@toxicpanda.com> Dave hold off on this, there's something odd happening that I need to figure out. Thanks, Josef
On Fri, Apr 10, 2020 at 11:44:43AM -0400, Josef Bacik wrote: > On 4/6/20 10:59 AM, Josef Bacik wrote: > > With the delayed ref throttling patches I started getting a lot of > > "parent transid mismatch" messages when running my snapshot+balance > > torture test. This turned out to be because we will unconditionally set > > the generation of a relocated tree block to the current transaction. > > > > This is generally true, but especially for mid-tree nodes we could have > > cow'ed the block in a previous transaction, and only actually update > > it's parents in a completely different transaction. Thus we end up with > > a parent transid that is in the future of the actual block. Fix this by > > using the generation for the extent buffer we're pointing to. > > > > Fixes: 5d4f98a28c7d ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") > > Signed-off-by: Josef Bacik <josef@toxicpanda.com> > > Dave hold off on this, there's something odd happening that I need to figure > out. Thanks, Understood. The patch hasn't been in any of the development branches so far.
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 3ca98d7e4896..d4734337127a 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -2303,7 +2303,7 @@ static int do_relocation(struct btrfs_trans_handle *trans, btrfs_set_node_blockptr(upper->eb, slot, node->eb->start); btrfs_set_node_ptr_generation(upper->eb, slot, - trans->transid); + btrfs_header_generation(eb)); btrfs_mark_buffer_dirty(upper->eb); btrfs_init_generic_ref(&ref, BTRFS_ADD_DELAYED_REF,
With the delayed ref throttling patches I started getting a lot of "parent transid mismatch" messages when running my snapshot+balance torture test. This turned out to be because we will unconditionally set the generation of a relocated tree block to the current transaction. This is generally true, but especially for mid-tree nodes we could have cow'ed the block in a previous transaction, and only actually update it's parents in a completely different transaction. Thus we end up with a parent transid that is in the future of the actual block. Fix this by using the generation for the extent buffer we're pointing to. Fixes: 5d4f98a28c7d ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") Signed-off-by: Josef Bacik <josef@toxicpanda.com> --- fs/btrfs/relocation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)