Let me first admit that this is armchair quarterbacking, and I know it.
I’m pretty sure Rockstor is using a database. I assume this is to make the UI snappier and also for code convenience (go get the value from a DB field rather than execute a command and parse out what you want on-the-fly).
I would like the propose the suggestion that a database causes more problems than it solves, and that a UI that’s a little slower is OK as long as the user can see activity.
I bring this up because I’ve seen some issues that I’m pretty sure are database related. What I’m being shown only makes sense to me if I’m not shown the real live data, but rather the bad recording of data. For example, I have a pool of 12 drives. This is correctly listed in the pool pane. In the disks pane however there are 14 drives attributed to that pool, 2 erroneously. Also, in the disks pane I correctly see 4 drives attributed to a 2nd pool, however in the pool pane it’s telling me there are 5 drives which is not true.
While it could be argued that these are bugs and can be fixed, I’d like to argue that the existance of a database makes bugs like this possible. My suggestion is to run the btrfs fi show every time the disks pane is loaded and parse out the drives and pools they belong to on-the-fly. The same for the pool pane and everywhere else in the GUI.
I apologize for comparing to another solution, but it’s one I’m familiar with and I think is a good illustration. Napp-it is more or less the same thing but for ZFS instead of BTRFS. It’s written in perl and I’m 99% it does not use a database. Whenever a screen is loading it’s refreshing the live data and parsing it out in the GUI. At the bottom of the gui there is a small “mini-log” where you can see the scripts being executed as the page data is being generated, parsed, and displayed. Yes pages do take a little longer to load but I can see that they are loading. The benefit is that I can always be confident that what is displayed is always correct and I’m never unable to perform some adminstrative action because the application is mixed up about the real state of my drives and filesystems. The manifestation of this right now is that I can’t import the 2 additional single-drive pools that really exist because the disks pane is erroneously reporting the 2 disks as belonging to the first pool.