On Fri, Sep 14, 2012 at 02:58:04AM -0600, Liu Bo wrote:

In some workloads we have nested joining transaction operations,
eg.
  run_delalloc_nocow
      btrfs_join_transaction
      cow_file_range
         btrfs_join_transaction

it can be a serious bug since each trans handler has only two
block_rsv, orig_rsv and block_rsv, which means we may lose our
first block_rsv after two joining transaction operations:

1) btrfs_start_transaction
      trans->block_rsv = A

2) btrfs_join_transaction
      trans->orig_rsv = trans->block_rsv; ---> orig_rsv is now A
      trans->block_rsv = B

3) btrfs_join_transaction
      trans->orig_rsv = trans->block_rsv; ---> orig_rsv is now B
      trans->block_rsv = C
   ...

I'd like to see the actual stack trace where this happens, because I don't think
it can happen.  And if it is we need to look at that specific case and adjust it
as necessary and not add a bunch of kmallocs just to track the block_rsv,
because frankly it's not that big of a deal, it was just put into place in case
somebody wasn't expecting a call they made to start another transaction and
reset the block_rsv, which I don't actually think happens anywhere.  So NAK on
this patch, give me more information so I can figure out the right way to deal
with this.  Thanks,

Josef