Intel Takes SATA Performance Crown With X25-E SSD 164
theraindog writes "We've already seen Intel's first X25-M solid-state drive blow the doors off the competition, and now there's a new X25-E Extreme model that's even faster. This latest drive reads at 250MB/s, writes at 170MB/s, and offers ten times the lifespan of its predecessor, all while retaining Intel's wicked-fast storage controller and crafty Native Command Queuing support. The Extreme isn't cheap, of course, but The Tech Report's in-depth review of the drive suggests that if you consider its cost in terms of performance, the X25-E actually represents good value for demanding multi-user environments."
Dedicated Database Storage (Score:4, Informative)
This just screams dedicated database storage.
Lousy storage density, insane price. (Score:2, Informative)
Let's see...$720 [newegg.com] for 32GB ($22/GB) versus $278 for 256GB [newegg.com] ($1/GB.)
Keep in mind that you could buy two of those 256GB drives, mirror them, and exceed (in all likelihood) the performance of the Intel drive, and have eight times as much storage. Since reliability is pretty unproven, having them in a mirror means your ass is suitably covered.
The absolute lowest storage density (SAS doesn't come in anything less than 36GB, and 300GB is the top-end) at $22/GB, when $4/GB is the norm for SAS drives (that's a premium of 5.5x) is a big ol' cup of Fail.
Re:NCQ on an SSD? (Score:2, Informative)
Re:NCQ on an SSD? (Score:3, Informative)
NCQ gives the SSD something to do while the host is figuring out what to write or read next. Normally it's used to allow the host to fire and forget 32 commands. In this case, you queue up a bunch of stuff, then figure out what to queue next.
SSDs are so much faster that the host is generally not keeping up with it.
Re:Software development (Score:5, Informative)
Re:Software development (Score:3, Informative)
I often do compiles (Gentoo) on a ram disk.
Linux desktop systems doesnt use anywhere near the amount of ram modern systems have so just make a tmpfs mount and the compiles fly. :)
Re:Lousy storage density, insane price. (Score:4, Informative)
Re:Question for slashdotters: (Score:5, Informative)
It becomes a very fast cdrom - read only.
Re:NCQ? (Score:4, Informative)
Re:I find it strange... (Score:3, Informative)
Yes, but some legacy operating systems can only address 4G of RAM (including the graphics card). Also, some hardware may not be able to take more ram. I can't think of any machine where 64G of ram is very cheap.
Re:NCQ? (Score:2, Informative)
read here: http://techreport.com/discussions.x/15374
Since we had her cornered, we took the opportunity to quiz Huffman about a few other matters. One of those was the interaction of Native Command Queuing and SSDs. We're familiar with NCQ as a means of dealing with the seek and rotational latency inherent in mechanical hard drives, but wondered what need there was for NCQ with SSDs. (Intel's just-announced SSDs have NCQ listed prominently among their specifications.) She said that in the case of SSDs, NCQ has the primary benefit of hiding latency in the host system. If you look at a bus trace, said Huffman, there's quite a bit of time between the completion of a command and the issuance of another one. Queuing up commands can keep the SSD more fully occupied.
Re:Software development (Score:3, Informative)
Re:wicked-fast door blowing screams? (Score:3, Informative)
"our Lotus Notes servers are almost as rough on the SAN as the DB servers, huge numbers of IOPS and almost as much storage."
I have no idea if you fall into this category, but many, MANY Domino administrators who implement with a SAN do so in a suboptimal fashion. A Domino server should have considerable resources on local drives even if you are committed to a SAN for your primary data storage. All system NSFs should be stored on local drives, as well as your transaction log (you are using transaction logs, right?) and a dedicated indexing swap drive.
If you're running Domino 8.0.1 or higher, you should use the non-summary item compression switch on your databases, as this can improve I/O demands by as much as 30%.
The newest version of Domino is due this quarter, and includes the new attachment and object storage model that can also dramatically improve I/O, since it's possible to move things like email attachments into an alternative storage location. (Whether this is on the SAN or not is up to you.)
As an IBM design partner, I've also been pushing the Domino server team to make some further improvements in I/O for future versions of Domino. Most significantly, this would include:
1) Permitting full-text indexes to be stored in a location other than a folder adjacent to the NSF. Right now, if you're storing mail files on your SAN, you *must* store FT indexes on the SAN as well. Which is rather limiting.
2) Pulling the view index collection object out of the NSF itself. When Domino builds a view index today, the $Collection object for that view gets stored similarly (not identically) to an attachment in the NSF itself. If you look at an NSF in the Administrator client, you can right click and select "Manage Views" to see the size impact this has on the database. More importantly, this results in dramatically more I/O to the NSF itself, and increases data fragmentation. So I've been beating the drum pretty hard to get IBM to pull that object content out of the NSF. (It was a choice many years ago to store it IN the file to keep administration simple in the days when Notes servers were brought up on NetBIOS LANs in broom closets.)
If you'd like to see these I/O improvement implemented, contact your IBM representative and beat that drum with me. :-)
And if you have any questions about any of this, feel free to contact me.