@philuser Hello again.
Not sure about the wisdom bit, but i might be best to confirm first our interpretation/parsing of the underlying info here, as a first step: i.e. check as the root user the output of the command indicated in the text. If we are parsing correctly, you may have a drive that has failed in such a way that it has slowed to a crawl. Ergo estimate correct but untenable - without a lot of patience and belief that it won’t get any worse in the proceeding 5 years :).
So if this is a massive slow-down failure, i.e. drive is re-trying many many times and still failing to store/retrieve what was asked of it; leading to yet more slow-downs as as btrfs has retried to reestablish a correct copy, you should take a different approach here and start by cancelling this scrub.
Once cancelled, given the suspected very poorly nature/performance of the suspect drive, you may want to attempt a pool repair via CLI removal from pool of the suspect drive. I suggest CLI here as we don’t yet implement a no write disk replace function:
But we have the following doc section:
Note the Note/Warning coloured sections in that doc sub-section:
An important function of ´btrfs replace´ is its ability, via an optional switch “-r”, to only read from the to-be-replaced drive if no other zero-defect mirror exists. This is particularly noteworthy in a data recovery scenario. Failing drives often have read errors or are very slow to achieve error free reads. See our dedicated Replacing a failing but still working drive section which uses this options.
In some cases a Btrfs replace operation can leave a pool between redundancy levels. This presents a risk to data integrity. Please see our Re-establish redundancy section for details.
Given you have currently only 4 drives in a raid5 data raid5 metadata pool you may not want to reduce that to the practical minimum of 3, but you do still have a single drive removal (or even disconnect) option here with subsequent degraded remount/repair. But the parity raids are not favourite on the repair and speed front.
So maybe the dedicated linked doc section in the above notes/warnings is your go-to here:
Replacing a failing but still working drive: Data loss - prevention and recovery in Rockstor — Rockstor documentation
In the case of a failing disk the ‘replace’ work-around of disk add/remove or remove/add, referenced in our sub-section header Btrfs replace, is far from optimal. The extreme reads/writes associated with these steps could fully fail an otherwise borderline functional device. Potentially failing the entire pool. After adding a disk Rockstor automatically does a full balance, to enhance ease of use; at the cost of performance. And btrfs itself does an internal balances to effect a drive removal.
For whatever reason, it can sometimes be preferred to do an in-place direct drive replacement. Depending on the btrfs-raid level used, this may also be your only option.
So when a direct disk replacement is required, the command line is also required.
Note from above doc section:
Note the use of the “-r” option. This is precautionary: only read from the to-be-replaced drive if no other zero-defect mirror exists. An optimal arrangement for a failing disk. If you are just after the fastest command line disk replacement, and all disks are known good, this option can be removed for improved performance.
Note the doc section has an example command where one can follow the status/progress of a requested replace. Hopefully it will take less than the next 5 years!
As always, refresh any back-ups if need be as these are large and thus risky operations.
Hope that helps.