[0/4] Slightly how START_SYNC and WAIT_SYNC work

Message

David Sterba June 3, 2021, 3:20 p.m. UTC

The async transaction commit ioctl has a subtle semantics that used to
work for ceph. We need more straightforward semantics in progs (eg. when
waiting for commit after subvolume deletion) and otherwise the async
commit does a few annoying things.

Long explanation is in patch 3. I hope it works, but somebody please
double check. It's a minor change in the commit logic, but merely
removing some waiting, no other changes in state transitions.

David Sterba (4):
  btrfs: sink wait_for_unblock parameter to async commit
  btrfs: inline wait_current_trans_commit_start in its caller
  btrfs: replace async commit by pending actions
  btrfs: remove fs_info::transaction_blocked_wait

 fs/btrfs/ctree.h       |   1 -
 fs/btrfs/disk-io.c     |   5 +-
 fs/btrfs/ioctl.c       |  12 ++---
 fs/btrfs/super.c       |   1 -
 fs/btrfs/transaction.c | 103 +----------------------------------------
 fs/btrfs/transaction.h |   2 -
 6 files changed, 9 insertions(+), 115 deletions(-)

Comments

David Sterba June 4, 2021, 10:59 a.m. UTC | #1

On Thu, Jun 03, 2021 at 05:20:19PM +0200, David Sterba wrote:
> The async transaction commit ioctl has a subtle semantics that used to
> work for ceph. We need more straightforward semantics in progs (eg. when
> waiting for commit after subvolume deletion) and otherwise the async
> commit does a few annoying things.
> 
> Long explanation is in patch 3. I hope it works, but somebody please
> double check. It's a minor change in the commit logic, but merely
> removing some waiting, no other changes in state transitions.
> 
> David Sterba (4):
>   btrfs: sink wait_for_unblock parameter to async commit
>   btrfs: inline wait_current_trans_commit_start in its caller
>   btrfs: replace async commit by pending actions
>   btrfs: remove fs_info::transaction_blocked_wait

btrfs/011 hangs so no dice. I maybe pick the two first patches as
cleanups, and the rest will go to some future dev cycle.