@greyson1973 Hello again,
Re:
There is, by default, no auto-update enabled in an instance of Rockstor created from our downloadable installers. It can be enabled manually via our instructions here:
https://rockstor.com/docs/interface/system/update_channels.html#auto-updates
So as long as you haven’t enabled this yourself, and take note of the version of testing your are about to install, your system should stay at the last version you opted into. When-ever you are about to put in a new version the Web-UI presents you with the changelog. So if you see 5.0.15-0 at the top (as of writing) that is the latest version that will be installed. You can then await the end of the next testing phase and do the same. Plus this forum is open about where we are in any given testing release. And if you are unsure you can always ask again. Or refer to the downloads page table to see what the last stable was: as it will most likely have been published first in the preceding testing phase - but only at the end of that phase.
This is always a good idea, yes.
Again there is no auto-update. Once you configure your system to use either the Testing updates, or the Stable updates, neither will auto-update. It will just offer you the option to update from the channel you have selected.
This is the default. But note that it will always offer you the latest version in current testing. So once we roll-over to the next testing phase (i.e. 5.5.- which will lead onto 5.6.. stable eventually) you do not want to install that until it reaches the end of the next testing phase. Again the forum always has this info available and we anounce mid-to-late testing phase rpms as RC or Release Candidate. But only use late RC or stable on production setups.
That would be a re-install, and import of the pool and a saved config. But that is more messy than manually taking note of the phase of testing your want to be involved in.
Nice. Our underlying filesystem is something we rely on our upstream OS to maintain: that is outside the expertise of our current contributors. So in that sense we are just users of the filesystem. That same filesystem is shared across all modern linux systems. So it would be expected that you can always mount our pools in an equally up-to-date kernel/btrfs-progs linux distribution. We just make it easier. But note that we only support a subset of arrangements in btrfs, so the opposite is not true: at least not without some manual re-arrangements so that a non rockstor native btrfs pool will not necessarily be importable into Rockstor without some rearrangements.
Indeed, that is always an aim and seemingly never achieved in the modern software arena. In part that is why we only support a sub-set of btrfs. As we gain more developer and testing interest/feedback this sub-set should expand; but we are subject to the same excessively shifting sands that bugs all current software development. However we try at least to choose our battles
.
Our next testing phase is to approach our own complexity in the front-end predominantly (development wise). In time this should lead to easing developer and user input into the project. But as always everything takes longer than one thinks, or would prefer.
For your own peace of mind, you could install a separate Rockstor instance in a Virtual Machine hosted by your desktop/laptop or an entirely other unused machine. You can then see for yourself the process of 1st subscribing to an update channel, and 2nd seeing what it offers, and 3rd what you are required to do to enact the offered update. Just be sure to read the Changelog that is presented within the Web-UI. And avoid CLI (Command Line Interface) updates as they will not not present a changelog by default.
Out of curiosity, what raid level have you chosen? Always use a raid level that has redundancy if your are storing data that you care about:
Hope that helps, at least with some context.