@zoombiel Welcome to the Rockstor community forum.
With regard to removing disks via the:
Pool - Resize Pool - Remove disks
method @KarstenV is correct in that it will trigger a re-distribution of the data that resides on the disk being removed so that the redundancy level (btrfs raid level) of the pool is maintained, if the proposed drive count permit this of course: the UI informs us otherwise, it also does a rudimentary space requirement check as you have mentioned having done.
However in your case you state:[quote=“zoombiel, post:1, topic:3151”]
failed disk
[/quote]
and:[quote=“zoombiel, post:1, topic:3151”]
If I remove the detached disk from GUI will it trigger the “chunks rebuild” on remaining disks?
[/quote]
Here the pertinent wording for me is detached!
With regard to detached disks ie ones that show up with names starting with detached- just removing them using the bin icon by their name does nothing to address the underlying pool, it just removes them from the database of drives that have been connected and associated with a Rockstor managed pool.
We do have the following significant and still open issue that I suspect partly relates to your circumstance:
It is worth reading the linked forum threads from this isue but they mainly pertain to replacing a still connected drive: noting your “(no replacement)” title here.
In that issue there is the mention of the -r variant of btrfs replace where the disk to be replaced is considered read only, ie for when it is suspect / know failing. However if your drive is now detached proper (as indicated by a name change in Rockstor to detached-) then what you need is to remove the missing drive (in btrfs speak).
btrfs device delete missing mountpoint
I have opened an issue with a proposal of how we might implement this within the Rockstor UI and have linked back to this forum post and related pre-requisite issues as well as the btrfs documentation on the associated command:
As I have referenced within that issue, and as you have just experienced yourself, Rockstor is currently a little poor on the pool health reporting. Hence the (current) requirement to drop to command line to address failure scenarios. We are making progress in this area and I hope to help more myself by focusing at this level in the near future.
Thanks for highlighting this area and I hope the above pointers helps.