Re: [PATCH v2 2/2] btrfs: account for new extents being deleted in total_bytes_pinned

[David Sterba <dsterba@suse.cz>]

On Wed, Dec 16, 2020 at 11:46:54AM -0500, Josef Bacik wrote:
> My recent set of patches to reduce lock contention on the extent root by
> running delayed refs resulted in a regression in generic/371.

As you write that often in patches, I want to point out that references
to 'my recent patches doing something' are too vague and don't stand the
test of time. Reading the patch in a year won't give me much clue what
patches are that. Also as patches don't get merged in the order they've
sent, 'recent' could be referring to something that would be in fact
committed after this patch, making it more confusing and hard to find.

If the patches are yet to be merged, referencing by subject should be
sufficient, Filipe has been doing that and I find it really convenient
to get more background to understand the changes or put them to context
in case there's some dependency.

> This test
> fallocate()'s the fs until it's full, deletes all the files, and then
> tries to fallocate() until full again.
> 
> Before my delayed refs patches we would run all of the delayed refs

And another one. If there's a hard patchset-to-patchset dependency and
they get merged in that order, that's fine to refer to it like that and
we've been doing that. The difference is that the patches are serialized
in git and going back in git history will end up in the referred patches
eventually. Unlike when it's still in the mailinglist, but still a more
specific reference is better.