@Superfish1000 Thanks for the additional info/feedback. We ourselves have had a warning against using the Raid5/6 for some time but not out-right disabled it. The btrfs unsupported status is not the same as the distro support status but we need to keep an eye on this for sure.
But Rockstor auto enables quotas upon import, something we really need to re-address. Especially given it can take a good few minutes for this re-enablement to be enacted and mid-process there can be some strange quota reports form the various and numerous btrfs commands we run while doing an import.
As you say if there is no write access then things are a little constrained. We do have work to do in this scenario re better timeouts. To ‘kill’ database ‘knowledge’ we have a brute force script whose mechanism we intent to add to an advanced area for Rock-ons.
Take a look at @Flox post here for this “delete-rockon” script’s use:
Briefly:
/opt/rockstor/bin/delete-rockon <rock-on_name>
That’s progess. Please note however that there are, as of yet, not official pre-build installers. I’ll contact you directly via forum private messaging for the details of an ongoing closed beta test in that area.
Not necessarily. You may just have a poorly pool, and in turn it is throwing us off track re the unsupported and read only. Given you have not in the past used newer kernels and the newer kernels have better ‘protections’ than we had in our prior v3 CentOS based variants. You may just be experiencing the btrfs design decision to go read-only upon finding insanity of sorts. And insanity is frankly more likely in the much younger parity raid levels of 5/6 within btrfs. Hence it’s lake of support / production recommendation in our upstream and within our own doc and Web-UI. I would recommend a back-up refresh and re-assessment of raid levels. One avenue that is unfortunately as yet unavailable in Rockstor is to use a raid1 or raid1c2/3 for metadata while maintaining the 5/6 parity for data. We hope to at least surface this within the Web-UI in time but it’s not likely to be in the near future. Unless of course we get more developer input in this direction. You never know. I fancy seeing this myself but a little hands-full on my end currently.
Another note on the ISO build that may account for you differing experience. Whenever you build a new installer it pulls in the latest upstream (openSUSE) updates. And to their enormous credit the openSUSE / SuSE teams aggressively backport btrfs fixes/features. So you may just have received a fix that favoured your situation re the import/mount or what ever. Or the initial mounts you attempted helped to clean up some of the potential pool issues that had accumulated un-noticed by the prior kernel.
Keep an eye out for forum PM notices for that closed beta test of our pending pre-build installer.
Thanks again for the detailed report/feedback; much appreciated.