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

[David Sterba]

On Thu, Oct 15, 2026 at 10:43:13AM -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 bug in the ordered extent error path: a
> truncated ordered extent that fails to complete kept the extent maps for
> its written part while the extent itself was freed.
> 
> Patch 2 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 3 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 4-8 remove the write path, 9 and 10 the load path and
> disk_cache_state, and 11 and 12 the SPACE_CACHE flag and the unused
> half of the cleanup helper. Patches 13-18 remove the trimming ranges
> and the free space inode special cases in the write path, which only
> the v1 writer used. Patch 19 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 btrfs for-7.4.
> 
> [1] https://lore.kernel.org/linux-btrfs/e1dd5a75-9a67-4bc6-b8d8-bfff79b5b907@xxxxxxxx/
> 
> ---
> Changes in v5:
> - Patch 1 (new): Drop the extent maps of the written part when a
>   truncated ordered extent fails to complete, per Sashiko.
> - Link to v4: https://patch.msgid.link/20261012-btrfs-remove-v1-space-cache-v4-0-f125bd8c07f9@xxxxxxxxxxxx

Thanks for the update, I've moved the patchset to for-next. Current plan
is to send it as a separate pull request for 7.4.