At 02/23/2017 06:51 PM, Christian Theune wrote:
Hi,
not sure whether it’s possible, but we tried space_cache=v2 and obviously after
working fine in staging it broke in production. Or rather: we upgraded from 4.4
to 4.9 and enabled the space_cache. Our production volume is around 50TiB
usable (underlying HW Raid 6).
The machine crashes silently every 15 hours or so and takes _ages_ to reboot.
It current is stuck trying to mount the local filesystems and I guess btrfs is
doing something, but I don’t have shell access yet.
I’m wondering whether we can downgrade by booting back into 4.4 or will this
break things even further? (We’ve had some unpleasant surprises with FS’ in the
last months, so I thought I’d rather ask.)
You could use "btrfs check --clear-space-cache" to completely cleanup
space cache. Both v1(free space cache, file based) or v2(free space
tree) are supported.
And specially for v2 space cache (space cache tree), "btrfs check
--clear-space-cache" will also clear the ro_compat flag, so older kernel
should mount the fs without problem.
In free-space-cache.c
------
features = btrfs_super_compat_ro_flags(fs_info->super_copy);
features &= ~(BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE_VALID |
BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE);
btrfs_set_super_compat_ro_flags(fs_info->super_copy, features);
------
Thanks,
Qu
Kind regards,
Christian
--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
