fedora-btrfs / project

#68 how to migrate users from space_cache v1 to v2
Opened by chrismurphy. Modified

Open
Close Issue

Background

  • Fedora 33 implemented btrfs by default
    • These file systems were created with btrfs-progs 5.14, (2021-SEP)
    • btrfs-progs-5.15 (2021-NOV) sets space cache v2 (free space tree) flag
  • Upstream kernel commit 1e7bec1f (since 6.11 upstream and 6.10 in Fedora) shows a warning if space cache v1 is in use:

BTRFS warning (device XXXX): space cache v1 is being deprecated and will be removed in a future release, please use -o space_cache=v2

Creating v2 on an existing file system involves either

  • Mounting RW with mount -o space_cache=v2; OR
  • Remounting RO to RW using mount -o remount,rw,space_cache=v2
  • Remounting RW to RW is not supported for creating a new free space tree

Additional notes on v2 creation

  • Mount doesn't complete until the free space tree creation is complete, on-disk, and v1 space cache is removed
    • Mount takes seconds (less than 1 minute) on typical system disks;
    • Could take minutes or hours on large file systems
  • Only the one-time mount is needed. A feature flag is set which makes v2 persistent on subsequent mounts.

  • Because Fedora initially mounts root file systems RO, we can't create v2 with a kernel command line option.

  • We can modify /etc/fstab which in effect becomes mount -o remount,rw,space_cache=v2

    • But then we ought to remove it from fstab; while not technically required, it's kinda sloppy to leave it behind

Questions

  • What's the time frame for deprecating v1 support?

Why wouldn't we automatically convert on mount? It seems reasonable to me if we're going to rip it out eventually that we need a step where detected filesystems are automatically converted.

I don't think upstream will automatically convert because of the potential for hours to days for creating free space tree for very large file systems - during which mount is in-progress but not completed so we don't even have read-only capability let alone read-write.

For us, it should be fast unless someone is using a single Btrfs for boot and for a lot of file storage. But we'd still need a way to trigger it and all I can think of is modifying /etc/fstab twice. That too is a big tricky.

Anyway I asked about another option upstream and we'll see what they say about all of it.

lazy free space tree creation, deprecation of space cache v1
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.