On my Task History page, it is showing a task as still running. I know this is not the case, because the underlying SCRUB that the task was for finished, as well as my machine has been rebooted since Feb 15th.
My guess is that something missed writing out that the task finished, so the status looks wrong. I am trying to find where in the database this is stored, but I can’t seem to find it. If anyone can point me in the right direction, I don’t mind firing up postgres and running an update statement to fix the history page, assuming that is what needs to be done.
Could you give us some details of your Rockstor version. You have some previous posts indicating you making customisation and potentially running newer kernels, i.e. your earlier post with the heads up on scrub format changes:
Also there were some improvements made in schedule reporting code but that was quite a few months ago now. So we need more details here really. Starting with:
yum info rockstor
and any customisation, if any.
Did you get around to sorting our code re scrub status command output parsing by the way? If so do you fancy submitting a pull request? We will have to get that sorted soon as our Built on openSUSE move progresses as those scrub reporting improvements may now have been backported in the Leap15.1 kernel / btrfs-progs versions.
Given you prior posts re custom kernel versions and the referenced scrub command output format change heads up maybe you would be interested in trialing our openSUSE testing channel rpms:
Relevant here is that openSUSE are pretty aggressive with their btrfs back-ports as detailed by @Flox in the following post:
The Built on openSUSE move is really our priority currently as that way we get folks on an upstream supported base, re the filesystem, as quickly as possible. We can then return to our ‘smaller’ issues of our own code’s dysfunction.
With regard to your postgres editing that would do it but it’l take time to find the right section. It may just be easier to run another scub, assuming it it’s just broken from here on in: i.e. via a newer kernel change say. And in which case looking to our new testing channel may be the way to get this sorted for the future. We haven’t had any other reports of this happening as a matter of course however. But again from memory it’s not the most robust of mechanisms in that area of the code. So is due for attention. But that is unlikely to come from a core developer at least until we have completed our drive for feature parity, or near enough, in the built on openSUSE offering.
