@BRRABill said:

I'll check those other ones out.

Oooooh looks like I have some reading/Googling to do!

@Dashrender said:

because their money is worthless

FTFY

http://www.xe.com/currencyconverter/convert/?Amount=1&From=CAD&To=USD

1US to 1.4CDN

1CDN to 0.71USD

I am a sad panda when shopping online.

BTW: I reached out to Cameron at Kingston about this, just to get a manufacturer's opinion. (I also invited him to join the forum as Kingston has been very helpful with demos and stuff.) Same as what the experts here have said. 🙂

He said:
TRIM is not as critical today as it was several years ago. The SSD controllers now do a good job at garbage collection which is effectively trying to accomplish the same thing by trying to keep the invalid data areas empty for new writes to come in efficiently. We've studied the performance affects of TRIM in our labs here at Kingston and have found that most reputable SSD manufacturers today are making SSD's that perform well whether TRIM is enabled or not on the operating system.

TRIM support is definitely necessary from a marketing standpoint but less necessary from a technical stand point at this point in time.

@xByteSean said:

@BRRABill Yes as a matter of fact we do. Any proof of concept box can be configured and shipped to you, and if it didn't fit your needs we would provide the return shipping label at no cost to you.

That is very awesome!

Ended up revising my approach to the whole configuration. I bought an SM951 128GB for the caching device and grabbed a pair of seagate 2TB drives and put them in an md raid 10. Random 4k inside one of the VMs averages between 12,000 and 20,000 write depending on queue depth. This seems low given that the SM951 is rated really high, can bcache be tuned to increase the dirty cache for random io?

I did manage to find a setting for sequential which pushed it up to 1GB/s.

The R820 is a very cool unit. So many cores and so much memory. Perfect for massive Linux and FreeBSD systems.

@ryan-from-xbyte said:

In the interest of reliability and compatibility, we opted to only support enterprise level SSDs. We actually only recently supported non-Dell drives because of those same reasons. We started talking with Edge and found a partner who would co-developer firmware to limit the risk to our customers. If Dell makes a firmware change, we didn't want our customers to experience any issues with their drives.

That what made me reaaaaaaaaaaaaaaally nervous about non-DELL drives.

Not that anything would happen, but the last thing you need is some change form DELL and then your drives stop working, or booting.

Total BS that they do that, but whatever. It's their company and there are other options.

@scottalanmiller said:

@Dashrender said:

@scottalanmiller said:

He does have on board hardware RAID. The problem is not his card but his hot swap bays.

You mean because of the lack of empty caddies? Sure I understand that, but I addressed that in my post.

oh, meaning rip the caddies off. I didn't understand what you were implying. That makes more sense.

Exactly. I've considered doing the same for my HP server.

@dafyre said:

@scottalanmiller said:

That's why comparing 500GB to 500GB for a "Watt per GB" comparison.

I assume we're talking average... Some HDDs are set to time out and switch to low power mode and stuff... and some folks (like me) go in and turn that off). SSDs have the advantages of not having to spin up or down. They simply draw less power.

Spinning down a Winchester drive dramatically increases its chance of death. So would increase costs in other places. Not sure if that would save money over the drives lifespan or not since it easily cuts 75% of the lifespan off.

@BRRABill said:

It seems as though you can install another DC, then replicate, then demote the EVAL one.

But I think I'll just go with not doing that. 🙂

Yes, it wouldn't be a functional AD if you could not do that. You risk schema issues, though.

@Dashrender said:

I'm not sure about that if that was the case, then why is Scott so dead set against Hot Spares? Unless he's only against hot spares for spinning rust RAID 5.

Hot Spares with R5 are insane as it could be a live part of the array making it a RAID 6. RAID 1, same thing, just make it part of the array. Both cases are insane to have hot spares.

With RAID 6 you can have them in situations where the hot spare does not push you unnecessarily close to RAID 10 and RAID 5.3 (aka RAID 7) is not available. But that's relatively uncommon.

In RAID 10 you can have them but they only make sense in very large arrays or cases where you just can't get to the array to swap the failed drives.

In some cases it is an architectural problem, in others it is that the cost is just not justified.

@alvama said:

Scott, thank you for your topic. I am planning new installation and comparing between RAID 10 and RAID 5 on ssd drives. What do you think about stripe size and TBW for two types of raid? Do you know what size of blocks will be written on disks if service (sql for example) writes 8Kb on volume. For raid10 I think it will be two 8K blocks on mirror disks. But for RAID 5 it will be two blocks with size=stripe size and may be 32 or 64K. And in raid5 configuration TBW limit will be reached faster.

I'm not Scott but in your context RAID5 seems to be preferred. Because 1) Flash and not spinning disk used so typical parity RAID issues associated with high-capacity spinners are gone (see URL below) 2) Database logs are sequential writes of a big sizes so should "touch" maximum amount of spinners possible and because of sequential nature read-modify-write is not going to happen and 3) RAID5 gives you write performance of (N-1) and RAID10 does (N/2) (where N = amount of spinners).

https://slog.starwindsoftware.com/raid-5-was-great-until-high-capacity-hdds-came-into-play-but-ssds-restored-its-former-glory/

Good luck 🙂

@scottalanmiller said:

SATA SSDs often make sense because they are cheaper and the protocol benefits of SAS really are not there in the same ways for SSDs.

So this brings up @DustinB3403 question of best practice or more aptly as you @scottalanmiller said implementation patterns - which ones as generically as you can be would go which way. I suppose it might be easier to say 'in these set of circumstances (list 1-4) you do this, generally in the rest you do that.'

@Breffni-Potter said:

@Bob-Beatty said:

@Breffni-Potter I agree with everything Scott says, with the exception of stopping at strange bars in the middle of the jungle at 10:00 at night.

Are you honestly telling me it was just the "one" thing you disagreed with? 🙂

I suspect there might be a few more bar visits you would object to if you cast your mind back.

haha! I.. cant.... remember too many bar visits with Scott, or I may agree with your comment... 😛

That means that we have hit the tipping point. The world's largest SSD (at any cost) is now 60% larger than the world's largest spinning rust legacy style Winchester drive (at any cost.) So while SSDs remain more expensive per GB, they are no longer smaller in capacity!! We were told to expect that this year, but now it has happened.

@Dashrender said:

Actually, there is another way.

If you use full disk encryption from day one, once you delete the encryption key you don't have to worry about it.

Any encryption can be broken. That is why the article I linked talks about getting verified information from the vendor.

For comparison, "cheap" sandisk 256gb SSD in my work laptop:

upload-46cb10a5-1af4-44d0-b0d4-e02ff3e04cd1

http://community.spiceworks.com/topic/1122819-perform-ssd-over-provisioning-optimization-on-the-array-good-or-bad

@thecreativeone91 said:

I saw this on SW and everyone was freaking out saying they would never use SSD based SANs because of this report.. People's Logic makes no sense.

Yup, the average SMB IT person has a serious issue understanding stats and how to apply information to the real world.