@Michael_Arthur
Could your post the output of the:
yum info rockstor
command as there is more info there that is pertinent to some of your reports as the 3.9.2 release as a whole has had > 45 fixes since it’s release, some fairly significant like the ability to work with quotas disabled and a little later on Web-UI elements to disable / enable quotas. Plus some fixes for the immutable attribute (chattr -i ) stuff.
Glad to hear some positive change is a foot. Would be nice and potentially useful to have some feedback on my prior suggestions re ensuring root causes for some of these issues however. But I fully appreciate that everything takes time however. But if your hardware is ‘flaky’ as the range of issues suggests (but not all of them of course) it’s in your interests to do the suggested checks.
Great, and thanks for the update.
Yes quite possibly, however to say possibly for sure we need the output of the above yum command. Quotas was a real pain for Rockstor for a period back there and is still a haunting element of btrfs, mainly on the performance and usage reporting front, ie it kills performance but is absolutely required to report usage. But the downside of significantly lower performance is being somewhat alleviated by upstream (the kernel and btrfs folks) so upon us moving to a more progressive base of openSUSE we should have that one sorted curtest of upstream which will be nice.
Also note that there is a delay from enabling quotas to it’s size reporting coming into effect. Also note that you will require later stable versions to cope with a quota state change.
Any changes on a system that is of unknown reliability, such as your system appears to be, is ill advised. Try the suggested memtest in my prior post before making any changes as no operating system or file system is robust to bad memory, hence the common additional precaution of ECC memory in server grade hardware.
But given the assumption of good hardware, yes you can change to btrfs raid1 for a close equivalent to traditional mirrored raid. Btrfs raid 1 effectively attempts to keep 2 copies of data and metadata on 2 independent device, irrespective of the number of devices in the given pool. This also affords btrfs the capability, under some circumstances, of self healing, ie given all data and metadata are check summed by default it can check data/metadata integrity, and given a raid level having multiple copies (2 in raid1/10 currently) it can substitute the know good copy when it encounters a bad copy. Scheduled scrubs for an integral pro active part of this element of btrfs. So in summary both btrfs raid1 and 10 only have 2 copies of data, and can each only suffer a single drive failure, I would favour raid1 unless you require the potential performance benefit of btrfs raid10. There are also slightly less ‘moving parts’ in raid1 than 10, as there is no striping. Just a thought. Also I would avoid compression for the time being simply as it’s another ‘moving part’. I’m a little cautious that way 
Note however that the btrfs parity raid levels of 5/6 are not recommended as they are significantly less mature and have incomplete facilities within the filesystem, such as size reporting and repair capability. But btrfs raid1 / raid10 are far more robust / mature, and perform better across the board as a result. So don’t use raid5/6 unless you know of the risks you are taking.
So chuffed you system seems to be on the ‘up’ but do please report on the exact Rockstor version via that command run as root on a terminal / console as that may well help to explain a lot, although there is as yet no explanation for your failed systemd atd service which is why I suggested the memory check / PSU consideration in my last post as they are common components for causing seemingly unrelated issues.
Well done for persevering but do keep in mind that to help forum members to help you they need complete feedback on suggested commands. And a full history if possible, ie why were quotas disabled, you also mention a power failure. They are again non friendly but not necessarily disastrous due to btrfs’s copy-on-write mechanism and your employing a redundant btrfs raid level. However our current limitation to a single device system disk is a weakness but one that hopefully upstream will tackle in time. And if said power failure, or another that preceded it, was the cause of your atd failure then yes a re-install and re-import on known good hardware would be nice. Just remember if you are going the system re-install route to make sure to disconnect all data drives (with system powered down) so you can be certain human/installer error doesn’t result in an install over the top of a current data pool member.
We do have the following howto: Reinstalling Rockstor doc entry which might be useful.
As for disk usage for different btrfs raid levels their is the online btrfs calculator:
btrfs disk usage calculator
Hope that helps.
sad days
after a power cut here. I was in the process of copying off everything to potentially do a fresh install. Still left with the docker not starting issue though