Re: [PATCH v7 00/10] btrfs: free space tree mounting fixes

[Boris Burkov <boris@bur.io>]

On Fri, Nov 20, 2020 at 10:32:22PM +0100, David Sterba wrote:
> On Wed, Nov 18, 2020 at 03:06:15PM -0800, Boris Burkov wrote:
> > This patch set cleans up issues surrounding enabling and disabling various
> > free space cache features and their reporting in /proc/mounts.  Because the
> > improvements became somewhat complex, the series starts by lifting rw mount
> > logic into a single place.
> > 
> > The first patch is a setup patch that unifies very similar logic between a
> > normal rw mount and a ro->rw remount. This is a useful setup step for adding
> > more functionality to ro->rw remounts.
> > 
> > The second patch fixes the omission of orphan inode cleanup on a few trees
> > during ro->rw remount.
> > 
> > The third patch stops marking block groups with need_free_space when the
> > free space tree is not yet enabled.
> > 
> > The fourth patch adds enabling the free space tree to ro->rw remount.
> > 
> > The fifth patch adds a method for clearing oneshot mount options after mount.
> > 
> > The sixth patch adds support for clearing the free space tree on ro->rw remount.
> > 
> > The seventh patch sets up for more accurate /proc/mounts by ensuring that
> > cache_generation > 0 iff space_cache is enabled.
> > 
> > The eigth patch is the more accurate /proc/mounts logic.
> > 
> > The ninth patch is a convenience kernel message that complains when we skip
> > changing the free space tree on remount.
> > 
> > The tenth patch removes the space cache v1 free space item and free space
> > inodes when space cache v1 is disabled (nospace_cache or space_cache=v2).
> > 
> > The eleventh patch stops re-creating the free space objects when we are not
> > using space_cache=v1
> > 
> > The twelfth patch fixes a lockdep failure in creating the free space tree.
> 
> Is this fixing a problem caused by some patches in this series? Because
> if yes, the fix should be folded there. A standalone patch makese sense
> in case we can't fold it there (eg. after merging to Linus' tree),
> otherwise the merged patchsets should be made of complete patches,
> without fixes-to-fixes. Even if the patchset is in misc-next, fixups are
> still doable.

The new 'needs_free_space' patch (#3) fixes the bug in this series that
you caught, so if I understand correctly, I should appropriately fold
that one into one of the existing patches.

The lockdep issue exists in misc-next as far as I can tell, so I think a
standalone patch makes sense.

Let me know if I misunderstood you on either of those.

Thanks,
Boris