SFOS disk structure arrangements

Essentially you have a config partition and the alternative config partition. Config is only the layout of the structure - Means like UTM the backup file (it is not the core system structure duplicated on disk). 

So if you update to a new version, the files will get updated, the configuration will be migrated to the new configuration and your current/then old config will be freezed in the alternative slot. 

If you roll back to the old slot, your config will come up exactly how you left it prior upgrade. 

Essentially you have a config partition and the alternative config partition. Config is only the layout of the structure - Means like UTM the backup file (it is not the core system structure duplicated on disk). 

So if you update to a new version, the files will get updated, the configuration will be migrated to the new configuration and your current/then old config will be freezed in the alternative slot. 

If you roll back to the old slot, your config will come up exactly how you left it prior upgrade. 

Thanks.

What about the core OS?

When updating, it copies unchanged parts of the old OS combining the patches of the update file to generate the new "firmware"?

Essentially it will also stores binaries from the old part of the OS in the old state, as needed. There is a logic behind it, to not break the downgrade to the old version as well. 

So to speak, if you update to a version, which fixes a bug or a vulnerability and you downgrade, you will once again experience the bug / be vulnerable in that system. 

The use case / point of this feature is to have always a smooth downgrade possibility, if you do an upgrade to a new version and something does not work. So people have a chance to go back to the old state and continue to work. Plenty of users utilize this option to have a fallback without the need to reinstall everything etc.