Remove detached, unassigned disk?

36

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:

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: https://rockstor.com/docs/installation/install.html#updating-rockstor

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.

3 Likes