A Balance process is already running or paused for this pool (ChronosIgnis). Resize is not supported during a balance process

Brief description of the problem

I’d like to change the RAID level of a 2 disk RAID1 pool, but rockstor thinks there’s a balance running while there’s no balance running.

Rockstor version 4.6.1-0 on openSUSE Leap 15.5. I probably should also mention I only just updated Leap from 15.4.

Detailed step by step instructions to reproduce the problem

Attempt to change RAID level from raid1 to single on a RAID1 pool.

Web-UI screenshot

Error Traceback provided on the Web-UI

Traceback (most recent call last): File "/opt/rockstor/.venv/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 68, in run_for_one self.accept(listener) File "/opt/rockstor/.venv/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 27, in accept client, addr = listener.accept() File "/usr/lib64/python2.7/socket.py", line 206, in accept sock, addr = self._sock.accept() error: [Errno 11] Resource temporarily unavailable

There’s a couple of failed balances but none currently in progress:

@unguul Hello there.
Re:

After such a dramatic change as an OS distribution update, it is always best to do a reboot. I’m assuming you have done this however. And that you followed our docs on distribution updating a Rockstor instance, i.e.:

Distribution update from 15.4 to 15.5: Distribution update from 15.4 to 15.5 — Rockstor documentation

And note that we now also have:

Distribution update from 15.5 to 15.6: Distribution update from 15.5 to 15.6 — Rockstor documentation

Not yet strictly required but 15.6 is our main target for the next Stable release.But currently has no stable rpm available. But we are in late Stable Release Candidate phase in testing channel: as of 5.0.14-0 from last week:

We have seen such false flags as this before. Try a reboot first, just in case, and if that does not work, try updating to 5.0.14-0 testing channel, and change back to Stable again to avoid accidentally installing anything newer from the testing channel as we will soon begin a new testing channel development phase where things get flaky again for a bit. This way we can see if the pending next Stable release also exhibits this same issue on your system. And hopefully then tend to a fix if it is still required.

The output of the following command, run as theroot user may also help us diagnose what has happened here:

btrfs balance status /mnt2/rock-pool

Substituting rock-pool for your Pool name.

Hope that helps. And keep in mind that almost all functional components have been switched out since our last Stable (4.6.1-0) to latest RC9: so this is a big update and will take take a few minutes longer than normal.

3 Likes

Hey @phillxnet, thanks for the detailed response.

Is a problem still a problem if it no longer exists even if a solution was not actually applied?

Anyway, one of the SSDs in my array died before I could do anything about it, so I had no choice but to move on from that setup I had. However, for a complete story regarding my issue I’ll still provide some information:

After such a dramatic change as an OS distribution update, it is always best to do a reboot.

I rebooted the system at least twice following the distribution update to make sure boots work smoothy as I don’t always have physical access to this machine and would hate for a power-cycle to prevent remote access.

you followed our docs on distribution updating a Rockstor instance

Absolutely. Thanks again for the docs.

The output of the following command… btrfs balance status..

This was actually the first thing when I initially got the error message, perhaps I should have attached a screenshot, my bad. Either way, no balance was running.

try updating to 5.0.14-0 testing channel

I’m just about to do that. I’m a stable updates channel subscriber, but I’ve been following the testing channel closely to find a good time to make the jump. I think that day is today.

As initially mentioned, my problem went away on its own, even if it wasn’t actually solved by me doing something. I guess all is well when it ends well. Fingers crossed for this update I’m about to start.

1 Like

Update to Leap 15.6 and Rockstor 5.0.14-0 completed successfully. No blockers identified yet, but I’ll do my best to report if it comes to it.

I do have an issue with the Rockstor service startup, but I’m pretty confident this is because of my non-default network setup, which takes long enough to start that the rockstor-pre service gives up. Starting the services via systemctl start rockstor-pre and systemctl start rockstor works just fine.

1 Like

@unguul that’s good news. As for the Rockstor service startup failure, this might be related to your network setup. There was a change to a hard dependency between NetworkManager and Rockstor startup. This is just being discussed in another thread (in case you haven’t seen it):

before and after that post are some insights on what device can cause this challenge.

3 Likes

Thanks for the reference. I didn’t see that thread in particular, but I did see a different one regarding the link between network service startup delays and Rockstor service starting. I can confirm that I have a bridged network setup which woulld probably explain the network startup delays.

Going back to my update, it would seem I spoke too soon. From what I can tell, none of my shares are mounting on their own. I’ve yet to search for solutions on this topic yet as it’s not a blocker for my immediate use case.