This was the subject of some discussion with SoftRAID tech support, the upshot being that they admitted their SMART monitoring was ill-equipped for SSDs (rather, for HHDs or seemed to be so claimed).
#Reddit raid monitor update#
I've lost drives when using SoftRAID as well, and was always able to update the backup before rebuilding the array with the replacement drive.Ĭlick to expand.SoftRAID has proven useless at SMART monitoring, in this case, an OWC Thunderbay 6 with 5x2TB Sumsung SSDs configured as RAID 4.
#Reddit raid monitor software#
I've used SoftRAID-backed RAID 5 and RAID 10 for long-ish term use (2 years before I went to a dedicated NAS) without problems, and the performance was very good for a software RAID 5. It meant losing a couple days work going back to my backup, rather than being able to do one last incremental backup and saving it all. macOS simply refused to bring up the second layer RAID because of the degraded state of one of the mirrors making up the RAID 0 layer, and simply entered a state of confusion where it didn't even recognize that the RAID 0 layer existed anymore. In my case, when I did lose a drive a couple months after building a 4 drive RAID 10 in DU. You can kinda get DU to build you a RAID 10, but I tried that once, and will not try it again. Honestly, if you are doing RAID 0 or RAID 1, it doesn't really matter too much. using SoftRAID.Īttached: AJA, BlackMagic and Terminal dd command displays/outputs for using Apple’s DU for RAID-0. I guess I will use the same testing procedure for the Sonnet/Samsung RAID-0 comparison and I suspect there will little variance using the Apple’s DU vs. This limited testing showed me there was little performance difference using DU or SoftRAID for RAID-0. So the dd command was showing slightly better write & read rates compared to AJA & BlackMagic. This was done such that the kernel File buffer cache was being cleared using ’sudo purge’ between runs to avoid reading from the RAM file cache. I ran a serious of dd writes & reads using different transfer block sizes from 512 bytes up to 262144 bytes, and for file sizes ranging from 10.5 MB up to 5.37 GB and the best write rate was some 583 MB/s and for reads the best was 510 MB/s. No matter, the take-away was there was little difference between using DU vs. The BlackMagic rates for writes were quite bad but the reads were close to what AJA displayed (does BlackMagic avoid using the kernel file buffer cache?). The AJA data rates came out to be around 518 MB/s for writes and a bit less at 490 MB/s for reads, using 1GB file sizes.
Using AJA and BlackMagic I found little difference between using DU and SoftRAID. In each case I set the RAID-0 transfer block size to 128Kb. The TB4m was directly attached to the MBP using Apple's USB-C-to-TB2 adapter.Īfter configuring these 4x BarraCuda drives as RAID-0 using both DU and SoftRAID I used AJA, BlackMagic Disk Test and the Terminal command dd to establish some data rates for each. I ran the tests under Catalina 10.15.3 (Build 19D49f) on my late 2016 15" rMBP13,3. The 5TB disks were freshly erased and formatted as HFS+. With this unclear issue of which is best, DU or SoftRAID, I’ve spent a limited amount of time to see just what the differences are configuring RAID-0 on a set of 4x 5TB 2.5” Seagate BarraCuda 5400 RPM spinning disks in an OWC Thunderbolt 2 mini 4 enclosure (TB4m). I’m unclear what the basis is for this claimed 85%. In some articles I’ve read there’s mention that SoftRAID offers as much as 85% better RAID-0 performance than for DU’s RAID-0. SoftRAID for configuring RAID-0 for our MP7,1’s internal/external units in particular our Sonnet PCIe card with its 4x Samsung SSD/Flash blades. Today, I’m wrestling with the use of DU vs. The prospect of configuring RAID-5 using SoftRAID appealed to me for protecting against a single drive failure.
#Reddit raid monitor full#
I’ve been using Apple’s Disk Utility (DU) for ages and purchased a SoftRAID full license in Dec 2015 to handle RAID sets beyond what DU offered. Subject: Pros & Cons using Apple’s Disk Utility vs.
0 kommentar(er)
