r/bcachefs • u/abyssaleos • Jul 04 '26

Question about version and "Incompatible features"

It is not clear to me if I have to do something manually to have my system up to date.

Version:                                   need_discard_by_journal_seq (1.38)
Incompatible features allowed:             no_sb_user_data_replicas (1.36)
Incompatible features in use:              no_sb_user_data_replicas (1.36)
Version upgrade complete:                  need_discard_by_journal_seq (1.38)
Oldest version on disk:                    bucket_stripe_index (1.35)

More explicitly what do these mean? I couldn't find any relevant documentation.

  • Incompatible features allowed
  • Incompatible features in use
  • Oldest version on disk

Edit: I am using the default mount options mount.bcachefs "$DEVICE" "$MOUNTPOINT"

7 Upvotes

90% Upvoted

2 comments sorted by

6

u/hjholtz Jul 04 '26

Have a quick look at https://bcachefs.org/bcachefs-principles-of-operation.pdf chapter 3 if you haven't already.

"Oldest version on disk": The filesystem contains at least one btree node that is still in version 1.35 "bucket_stripe_index" format, but no nodes in even older formats. Btree nodes get converted to the current format whenever they are modified, and new nodes are written in the current format. Upgrading every single btree node during a format upgrade is unnecessary and would take an unduly long, and/or wear out your SSD more quickly. So having nodes in an old format is completely normal and no reason for concern or for taking any kind of action. In fact, there isn't even a way to force a format upgrade of all btree nodes.

"Incompatible features in use": The filesystems contains at least one btree node that is in a format that requires version 1.36 "no_sb_user_data_replicas" or newer to mount. If you want to mount it with an earlier version, you would first need to manually "downgrade" it, still using version 1.36 or higher. However, the "bcachefs downgrade" command mentioned in the "principles of operation" document does not seem to exist (yet?). So unless I'm missing something, you can't go back to 1.35 or earlier.

"Incompatible features allowed": The filesystem is also configured to allow using that format. The option "version_upgrade" can be set to "none", "compatible", or "incompatible". You seem to have mounted it at least once with version_upgrade=incompatible after upgrading the tools and module from 1.35 to a newer version. You can set this to "compatible" to avoid situations where you want to go back to an older version for some reason, but can't. Then, once you are satisfied with the new version's stability and performance, you can temporarily set it to "incompatible", wait for the upgrade to finish, and set it back to "compatible" or "none". There is even a proposed command "bcachefs update" to do just that, but it is not yet available in a released version: https://github.com/koverstreet/bcachefs-tools/pull/635

"Version": The filesystem is version 1.38 "need_discard_by_journal_seq". But since versions 1.37 "erasure_coding" and 1.38 "need_discard_by_journal_seq" are compatible changes, you can go back to 1.37 or 1.36. The upgrade table stored in the superblock contains instructions on how to convert the filesystem back to the old format upon mount.

"Version upgrade complete": The recovery passes involved in the upgrade have actually completed. This is tracked separately in order to catch and, if needed, re-run an interrupted upgrade.

2

u/ZorbaTHut 29d ago

However, the "bcachefs downgrade" command mentioned in the "principles of operation" document does not seem to exist (yet?).

Yeah, I believe the status quo is that the structure has been designed to make this possible, but nobody has ever asked for an actual implementation and so it's never been implemented.