Re: [PATCH 0/3] Refactor delayed refs processing loop

[David Sterba <dsterba@suse.cz>]

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.