Follow-up: TRIM supported SSDs in Snow Leopard RAID1?

[fhturner]

So as not to muddy the New BootROM 138.0.0.0.0... thread w/ more of this offshoot, I hoped I might solicit some advice about this TRIM issue in a new thread. Basically, I have a pair of SSUBX 512GB blades in a RAID1 mirror in a server. The read speed after the firmware update (and using Slots 2 & 3) is over 2500MB/s. However, the write speeds are extremely low at around 200-300MB/s (continues below quotes):

@h9826790

Your post about better RAID performance with dual low cost PCIe cards with 138.0.0.0.0 is correct. @fhturner tested it now after I did his BootROMs. AJA with Dual SSBUX 512 RAID1:
View attachment 778089 View attachment 778091 View attachment 778090

Yeah, I definitely have a problem going on there w/ the write speed. But as Alexandre points out, the cool part is the Read speed approaching 2x the single SSD (1400-1500MB/s). As he also points out, this is actually a RAID1 mirror (which is probably what you meant)...so while the write speed, when not fouled up like this, will be approx 1x of a single SSD, since the same thing is written in tandem to both SSDs; but the read speed can function like a RAID0 and get nearly 2x that of a single SSD.

These are SSUBX blades, so Samsung/Apple. Just re-checked, and they do in fact show TRIM Support status of "Yes" in System Profiler.

If that's a test drive, you may un-RAID them now, and just to check if the writing performance still the same. If yes, then may be TRIM is activated on 10.6.8, but not be used in RAID.

This is actually an in-production 10.6.8 Server. I can take it down for short periods in off hours, but nothing lengthy. I will try fsck in Single User Mode, but it sounds like that might not work for a RAID. Any thoughts on a repeatable, minimally intrusive process to work around this periodically, since it appears that TRIM is not functioning on the RAID?

I like the redundancy of having 2 mirrored boot SSDs on my servers (more than one configured this way), but should I consider another way if they're all going to degenerate to this level of write performance?

Thanks,
Fred

 

[h9826790]

I like the redundancy of having 2 mirrored boot SSDs on my servers (more than one configured this way), but should I consider another way if they're all going to degenerate to this level of write performance?

IMO, for most usage (including small scale multi media production), no need to use RAID 1 boot drive. Simply make a daily clone of the boot drive should be enough.

My understanding of having RAID 1 boot drive is mainly for "keep the system alive" (when the boot drive fail).

For a single simple computer system (like a cMP). Having a PCIe AHCI SSD as mirror for just to keep the system alive is very over kill. And not cost effective.

What's the chance of having a boot drive (SSD) fail during use? From memory, I haven't seen a single case on this forum yet. That means... very low.

And for our system, as long as you have a backup boot drive (SSD), we can easily make the system back on live in few minutes. Not that destructive. I understand some very complicated system may require hours to reboot. And if not follow a specific procedure to shutdown, it can be a big disaster. That of course want RAID 1 boot drive (or even more redundancy). But for cMP, we can even hold power button to force shutdown the entire system without damage anything (of course, we know it's not a good practice, but it's a fact that most of us did this many times without issue).

Since it's a RAID 1. You don't need to make it too complicated for the test. You can simply shutdown the Mac, remove one of the drive, and boot the Mac. This will essentially "break" the RAID 1, put the system back on single drive. And now you can test if there is any change on the write performance.

Of course, after the test and when you install the 2nd SSD back in, it may take some time for the system to sync the data. But for such a small capacity and high speed SSD, it shouldn't need much time to finish the sync.

 

[fhturner]

My understanding of having RAID 1 boot drive is mainly for "keep the system alive" (when the boot drive fail).

Very good points all. However, since this is a server, and since the content is changing regularly because it handles mail for an organization, I really do want that fail-safe that the RAID1 offers. I'm still cloning to a 3rd disk nightly, plus backing up to multiple sets rotated offsite.

For a single simple computer system (like a cMP). Having a PCIe AHCI SSD as mirror for just to keep the system alive is very over kill. And not cost effective.

Quite right again. But again, being a server— and one that handles mail for a medium-sized organization— I needed some improved performance over the original enterprise HDs for handling all those small files quickly. I could certainly have made do w/ less and used some SATA SSDs. At the time a couple of years ago, however, @handheldgames SATA Express meets the '09 Mac Pro thread was a mere few hundred posts long , and I was all excited to use these XP941/SM951/SSUAX/SSUBX beasts that could do 1500MB/s! So I went w/ those.

Since it's a RAID 1. You don't need to make it too complicated for the test. You can simply shutdown the Mac, remove one of the drive, and boot the Mac. This will essentially "break" the RAID 1, put the system back on single drive. And now you can test if there is any change on the write performance.

I will give this a try. I do know, though, that the system will tend to maintain the RAID in a degraded state, even if it has just a single member. So, it may still be seen by the OS as a RAID, even if 1 SSD is absent. I'll see what I can do and post back.

Thanks!
FT

 

[AidenShaw]

Since it's a RAID 1. You don't need to make it too complicated for the test. You can simply shutdown the Mac, remove one of the drive, and boot the Mac. This will essentially "break" the RAID 1, put the system back on single drive. And now you can test if there is any change on the write performance.

Note that you should also make sure that TRIM is enabled, and that you run the disk utility tool that forces TRIM on free space.

If the problem is un-TRIM'd space, breaking the mirror by itself won't TRIM free space.

Actually, it would be interesting the run the tests before and after forcing TRIM.