Re: [PATCH 00/15] btrfs: remove the v1 space cache

[David Sterba]

On Mon, Sep 07, 2026 at 09:19:15PM -0400, Tal Zussman wrote:
> Since commit 545e560a5b0f ("btrfs: disable v1 space cache") the mount
> options can't select the v1 space cache anymore, but the code is all
> still there, and a filesystem with an old cache and no free space tree
> still enabled it from the superblock. Qu suggested removing it rather
> than converting its page handling to folios [1].
> 
> Patch 1 stops enabling the cache from the on-disk state, so an existing
> cache is cleaned up on the next read-write mount, as -o nospace_cache
> already did. This is the one user-visible change: the cleanup is now
> unconditional, and a read-write mount fails if it fails.

In case it fails there are 2 ways how to fix it:

- convert to free space tree during mount (the recommended conversion
  from v1 to v2) but it could fail for the same reason

- on unmounted filesystem do 'btrfs rescue clear-space-cache v1'

> Patches 2-5
> remove the write path, 6 and 7 the load path and disk_cache_state, and
> 8 and 9 the SPACE_CACHE flag and the unused half of the cleanup helper.
> Patches 10-15 remove the trimming ranges and the free space inode
> special cases in the write path, which only the v1 writer used.

The piecemeal removal is good, makes it clear what's still needed, as
listed below.

> What's left is what's needed to find and delete the cache inodes of an
> existing filesystem:
> 
> 1. lookup_free_space_inode(), btrfs_remove_free_space_inode(), and
>    btrfs_cleanup_free_space_cache_v1(), which runs on the first
>    read-write mount and zeroes cache_generation in the super block.
> 
> 2. btrfs_truncate_free_space_cache() and delete_v1_space_cache(), which
>    relocation uses to get a cache inode's extents out of a block group.
> 
> 3. btrfs_is_free_space_inode(), for the evict and inode update paths.
> 
> 4. The on-disk definitions: cache_generation in the super block,
>    BTRFS_FREE_SPACE_OBJECTID, and the free space header and entry
>    items.
> 
> space_cache and space_cache=v1 still fall back to nospace_cache with a
> warning.

The sperblock::space_cache will remain unused and the only valid value
is 0. Repurposing it in the future is possible but we need a long period
in between.

The points listed above for the code that will be still needed seem
minimal. It could be removed eventually leaving only the unmounted
clearing.

I'll add the series as topic branch to linux-next. The mentioned change
to tranaction NOJOIN is simple and no-op in the code so it'll get
updated for the final merge.