On 9/9/26 4:08 AM, David Sterba wrote:
> 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'
>
Thanks, I'll add this to the cover letter.
>> 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.
>
Great, thank you! I'll send a v2 with the transaction split in a couple
days.