Can't mount a new Btrfs filesystem the second time: cannot disable free space tree

[unfa]

Recently I've been trying to make a new Btrfs filesystem for rolling Borg backups.

Unfortunately after creating a new filesystem I can mount it, but then after unmaount it on for the first time, it's impossible to mount the second time. dmesg says this:

[pią mar 18 22:46:22 2022] BTRFS info (device sdf1): flagging fs with big metadata feature
[pią mar 18 22:46:22 2022] BTRFS info (device sdf1): enabling disk space caching
[pią mar 18 22:46:22 2022] BTRFS info (device sdf1): setting incompat feature flag for COMPRESS_ZSTD (0x10)
[pią mar 18 22:46:22 2022] BTRFS info (device sdf1): force zstd compression, level 3
[pią mar 18 22:46:22 2022] BTRFS error (device sdf1): cannot disable free space tree
[pią mar 18 22:46:22 2022] BTRFS error (device sdf1): open_ctree failed

I have never had this kind of problem before - I assume this is a bug that was introduced in a recent kernel update on Arch Linux (I'm running kernel 5.16.15-arch1-1 right now).

I really hope this can be resolved quickly, as all my data is stored on Btrfs filesystems and having something like this happening is quite unnerving.

What can I do about this?

[unfa]

I've tried adding a mount option clear_cache. I don't really know what it does, but if it will let me mount a filesystem that'd already be some progress.

dmesg output when trying to mount:

[pią mar 18 22:55:10 2022] BTRFS info (device sdf1): flagging fs with big metadata feature
[pią mar 18 22:55:10 2022] BTRFS info (device sdf1): force clearing of disk cache
[pią mar 18 22:55:10 2022] BTRFS info (device sdf1): setting incompat feature flag for COMPRESS_ZSTD (0x10)
[pią mar 18 22:55:10 2022] BTRFS info (device sdf1): force zstd compression, level 3
[pią mar 18 22:55:10 2022] BTRFS info (device sdf1): using free space tree
[pią mar 18 22:55:10 2022] BTRFS info (device sdf1): has skinny extents
[pią mar 18 22:55:11 2022] BTRFS info (device sdf1): clearing free space tree
[pią mar 18 22:55:11 2022] BTRFS info (device sdf1): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)
[pią mar 18 22:55:11 2022] BTRFS info (device sdf1): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)
[pią mar 18 22:55:12 2022] BTRFS info (device sdf1): creating free space tree
[pią mar 18 22:55:13 2022] BTRFS info (device sdf1): setting compat-ro feature flag for FREE_SPACE_TREE (0x1)
[pią mar 18 22:55:13 2022] BTRFS info (device sdf1): setting compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)

[bettyvschmartz]

Had this same issue installing Pop!_OS 22.04 and saw another report here.

This worked fine for me.

-- bvs

[Iizuki]

I had a similar issue:

1. Created new two drive raid1 (data & metadata) filesystem
2. Mounts good
3. Try to mount it with mount -a based on fstab entries
4. The same error as with OP

The issue was solved when I removed space_cache option from the fstab entries. Afterward mount -l shows that the system was mounted with space_cache=v2. I guess that in my case there was some issue with the space_cache version (default v1 vs v2)?

Using Arch.

[jeffmahoney]

Folks, this project is not for reporting general btrfs issues. The btrfs mailing list is the appropriate place for that.

[austinbutler]

I encountered the same thing last weekend and came to the same conclusion, when I mounted in the installer ISO I didn't use space_cache and presumably it defaults to v2. I had space_cache in the fstab for the persistent system so upon reboot apparently it interprets that as v1. I changed fstab to space_cache=v2 and it worked.

[unfa]

@austinbutler Thanks, changing space_cache to space_cache=v2 in my fstab has solved the mount issue!