On Wed, Aug 15, 2018 at 10:39:53AM +0300, Nikolay Borisov wrote:
> Here is a small series which aims to rectify the eye sore that delayed refs
> processing loop currently is. In fact, it's actually 2 loops in the guise of a
> single 'while' construct. All in all this should bring no functional changes
> and I've verified this with multiple xfstest runs with no problems.
>
> Patch 1 factors out the code which deals with selecting a ref head which has
> delayed refs pending and locking it.
>
> Patch 2 introduces a new function which comprises the internal loop aka
> processing delayed refs of a delayed head, which is more or less most of the
> code in __btrfs_run_delayed_refs copied. The only difference is that the
> function can return EAGAIN if we detect a delayed ref which has sequence number
> higher than what is currently in the tree mod list.
>
> Patch 3 Finaly makes the loop in __btrfs_run_delayed_refs use the function
> introduced in the previous patch, meaning deleting most of the code and
> changing the loop to a 'do {} while' construct. I strived to retain all the
> semantics of the old code so there should be no surprises.
>
> Nikolay Borisov (3):
> btrfs: Factor out ref head locking code in __btrfs_run_delayed_refs
> btrfs: Factor out loop processing all refs of a head
> btrfs: refactor __btrfs_run_delayed_refs loop
Added to misc-next. It's been in next for some time and I haven't
noticed problems related to that patchset.
