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

[David Sterba]

On Mon, Oct 12, 2026 at 12:28:12PM -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 fixes a pre-existing leak in the cleanup path, where a crash
> before the delayed iput evicts a cache inode left it unreachable with
> its link count still set.
> 
> Patch 2 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. There are two
> ways to fix this failure:
> 
> 1. Convert to the free space tree during mount (the recommended
>    conversion), but this could fail for the same reason.
> 
> 2. Run 'btrfs rescue clear-space-cache v1' on an unmounted filesystem.
> 
> Patches 3-7 remove the write path, 8 and 9 the load path and
> disk_cache_state, and 10 and 11 the SPACE_CACHE flag and the unused
> half of the cleanup helper. Patches 12-17 remove the trimming ranges
> and the free space inode special cases in the write path, which only
> the v1 writer used. Patch 18 removes TRANS_JOIN_NOLOCK, which the space
> cache was the only user of.
> 
> 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.
> 
> This also removes the page-based I/O in the free space code.
> btrfs_io_ctl used a struct page array and was one of the last users
> of clear_page_dirty_for_io().
> 
> Tested with fstests (btrfs and generic quick groups), with and without
> the free space tree, with no regressions against the base kernel.
> Upgrading from a filesystem with an existing v1 cache written by a 6.8
> kernel was also tested. The cache is removed on the first read-write
> mount and on remount from read-only, and the resulting filesystem is
> clean under btrfs check and still mountable by the old kernel.
> 
> Based on the misc-next commit in btrfs for-next (a5c77fde6730).
> 
> [1] https://lore.kernel.org/linux-btrfs/e1dd5a75-9a67-4bc6-b8d8-bfff79b5b907@xxxxxxxx/
> 
> ---
> Changes in v4:
> - Patch 1 (new): Write the zero link count when removing a free space
>   inode, so an interrupted cleanup can't leak it.
> - Patch 2: Clear FREE_SPACE_TREE in btrfs_reconfigure() whenever the
>   free space tree is not on disk, so a remount that only warns about
>   the free space tree no longer leaves the option set, per Sashiko.
> - Patch 2: Dropped review tag.
> - Patch 16: Also drop the tree root check from the delalloc metadata
>   release.
> - Patch 18: Redo against the TRANS_* flag cleanups in for-next.
> - Link to v3: https://patch.msgid.link/20260916-btrfs-remove-v1-space-cache-v3-0-10ebde03b96f@xxxxxxxxxxxx

Thanks, unfortunatelly this did not make it into the 7.4 pull as the
freeze was yesterday and I was not able to process the v3 last week.
The v4 still has some issues reported by sashiko. It could be still
possible to send that separately as 2nd pull to 7.4 because the code has
been in linux-next, small fixups would be possible, and it's code
removal.