On our 3.9.2-57 installation, we have a detached disk that is not assigned to any pool. I gather there were some problems a couple of years ago so it was detached.
Can we just delete it? Will that cause any problems? Will a reboot be required?
Thanks
@MRC-MBU Hello again.
Re:
Yes.
Although it may error out (harmlessly) if you havenāt, just prior to this, pressed the āRescanā button on the disks overview page. From memory, I think back then we had a bug in this area and we re-name the drive on each page refresh, i.e. the random number against itās name changes. Just try again if it fails the first time.
No,
itās just a dead weight functionally. There is not pool association. If there was you would, at least in more modern versions or Rockstor, be guided to the ReRaid to have the āmissingā disk removed from the pool first. In fact it slows the Web-UI down to have these detached disks in place as they are not entirely dead from the Web-UI perspective as they represent a maintenance burden of sorts.
No.
There is no pool connection and so no pool correction associated with this entry. Itās there as one of our remits is to track disks and their prior management status. This disk, as you say, was once attached to the system, and is no longer. We are there-fore obliged to indicate this within the Web-UI as it may not be what was intended and so would represent a failure of sorts.
Iām looking froward to you getting this older setup replaced in time. But I know this is often a non trivial afair. We have made hundreds of bug fixes since then and upstream has made thousands (years worth in fact). So lets hope our newer and differing domain stuff will work out for you as I believe that is one of the complexities in your current migration. Always best to be sure all is OK (via real world proof) before you migrate to what may be incompatible in some way. Also do keep your reports coming on your trials of v4 in your environment as although we havenāt yet, we do intend to do hot-fixes (read smaller ones) to the stable branch (which started at v4.1.0 as per in the installer) as the need arises.
We have now branched our code to handle the large scale code changes required of the next testing phase. See:
https://github.com/rockstor/rockstor-core/issues/2362
So be sure to either subscribe to the stable channel (which is build from the master branch in GitHub), or update all but the rockstor package if you happen to have a system already on testing (v4 in this case), or subscribe to neither channel for the time being, at least until we reach a workable testing channel again.
For the ways to update see: Installation ā Rockstor documentation
But the testing updates are, and were, never intended for production use. Its just that at the beginning they are just plain broken. When we first released Rock-ons in testing they would all fail on reboot and one had to re-enable then on boot. It just takes time to do things in smaller steps but those steps help to garner wider participation.
Hope that helps.
