Intel SSDs have some horrible issues when SMART command sequences are interleaved with normal disk accesses. That is, when you run smartctl while the drive is busy doing other things. The drives go tits-up when that happens.
I've also noticed significant training time differences between Intel SSDs and WD HDs when connected to 6Gb/s SATA ports when using newer AMD chipsets. The AMD chipsets (supporting 6Gb/s SATA ports) have fairly poor firmware and it takes some massaging in our AHCI driver to get it to properly probe an Intel SSD at 3Gb/s. There were no problems with the WD HDs so I suspect poor or fragile SATA/AHCI firmware in both the cpu chipset AND in the Intel SSD.
In anycase, I've had very good results with all of my Intel SSDs to date, and very good results with the WD Caviar series of HDs. Nearly all of my Seacrates have failed, some well before their time. I don't buy Seagate HDs any more. I also no longer buy high-rpm drives, for any reason. They simply wear out more quickly than lower-rpm drives. Instead we continue to experiment with SSD + HD combos (using DragonFly's swapcache feature) to deal with the lower performance of the lower-rpm HDs.
Well, the i7-990x is certainly a fast processor but I don't see the point comparing it against a 965 without turbo-boost. They are effectively comparing a 3.8 GHz i7 (when it isn't running all its cpus.. that's how turbo boost works for both vendors) against a 3.4 GHz phenom II. Well Duh! The phenom ii x6 1100T black is 1/4 the price and runs 3.7 GHz out of the box in turbo boost mode, and it can be trivially and reliably overclocked to 3.8 GHz on all 6 cpus with turbo boost turned off (and to 4.0 GHz with moderately good cooling).
Intel still has faster cpus clock for clock, but not by a whole lot and the price/performance ratio for the i7 is horrible. Expensive cpu, expensive ram... come on.
All our current servers use a small 40G Intel SSD to cache copies of filesystem meta-data, plus data for often-accessed files and databases. Since the data sets being served are far, far larger than the ram in the machine this leads to a massive improvement in efficiency and a massive reduction in the load on the hard drives. Actual write activity is minimal, the SSDs will easily last 20 years at their current wear rate.
It all comes down to the workload. A very large swath of workload types can use SSDs RIGHT NOW without shredding them to bits, so it's pretty stupid not to use them when a measily little $110 Intel SSD saves you $2500 worth of dram, server motherboards, not to mention a massive savings in power costs by not having stuff 32G of ram into a server.
Some people just don't get. It's ok, I don't take it personally.
Insofar as actual swap (as in paging physical ram in and out) goes, it depends heavily on the amount of ram the machine has and the type of work load. Mostly-read workloads with data sets in memory that are too large can be cached in swap without screwing up a SSD. A large dirty data set, however, will cause continuous heavy writing to swap space and that can shorten the life of SSD-based swap very easily.
A system which needs to page something out will stall badly if the pageout activity is rate-limited, thus you just don't want to use an SSD in any situation where huge, continuous pageout rates are expected. Huge pagein/re-pagein rates due to largely static in-memory data sets are fine. Huge pageout rates are not.
It is a different story for filesystem meta-data or data caching. You should be able to control worst-case write rates in those sorts of setups (at least you can with DragonFly's swapcache), making the SSD a huge win under virtually any circumstances.
Now that 6GBit/s SATA ports are becoming commonly available on motherboards it's only natural that SSDs follow. Normal HDs can't really take advantage of a 6Gb/s port but SSDs can. These high speed ports will make port multiplier enclosures more useful as well.
There's certainly a lot of use for this sort of thing. SSDs can already replace far more expensive DRAM (and the far more expensive motherboards needed to support lots of DRAM) for numerous problem sets, including mostly-read database accesses. This will significantly reduce the cost of server architectures for large swaths of problem areas.
The channel has pretty much gone down the tubes, I don't watch it any more. Whenever I flip to it all I see is some ghost busters crap or wrestling. Adult Swim is the only thing that is moderately interesting, and they moved the Anime well past midnight so there's no point trying to watch it on that channel.
For the record, the FarScape movie was the BEST ending to a science fiction series ever. Nothing else comes even remotely close to that ending. But the SciFi channel didn't have much to do with the production of that series.
The RAWs from my camera are already 25-35MB each. A quality-9 jpeg post-production final is usually in the 7-10MB range. I archive both so I'm sitting on about ~40MB per picture in archive storage. Needless to say it adds up pretty quickly.
I keep the archive on a 2TB drive which is backed up as part of my normal backup, meaning it gets backed up to another machine on the LAN and from there to a colocated off-site box. So I have three physically separated copies. I also usually wind up uploading the jpegs to my paid account on flickr for distribution and for 'just in case'. And even though it isn't the RAWs it's still what is most important to me... a viewable picture.
I would caution against having a single copy with no backup, even if it is on a RAIDed system. That's a recipe for complete data loss.
On my laptop I have around a ~120G SSD to spool-off RAWs taken from the camera's 16G card when I'm on the road. I try to do that every day just in case the card fails (which has happened to me), or in case the camera or laptop gets stolen. I only erase the cards at the last possible moment in order to retain local backups as long as possible.
I usually don't try to do post-production on the laptop. Post-production with lightroom is fairly straight-forward though if you spend some time taking the original picture properly Canon's free software works just fine too. Frankly it takes actually printing the pictures out to get all the parameters correct, even good screens don't really match printed output. I don't like to 'play' with my pictures like other people, I like them to be as original as possible so most of lightroom's features go unused.
The TOS bit is almost useless. It is abused mightily and even standard services such as ssh can't really tell the difference between an interactive session and a batch session. So there's no real point in trying to queue based on the bit.
It's actually more around 10,000 cycles for consumer grade MLC flash (which is what you find in most SSDs). SLC flash runs around 100,000 cycles. There's been a lot of misinformation on this topic but the easiest way to think about it is to consider the actual write durability that people have been experiencing with SSDs. Take an Intel 40G SSD for example. The vendor-specified write durability is 35TB (I always say 40TB just to make the numbers easy), or 1000x, which assumes a very high write amplification factor of 10x. The ACTUAL durability is closer to 200TB with a 2x write amplification factor when used wisely, which is about what we get with DragonFly's swapcache feature. But it depends heavily on how the SSD is used. Put a normal windblows filesystem on a SSD and you will likely see durabilities more in the range of 40-80TB due to higher write amplification factors and heavier write combining loads on the SSD controller. Put a stupid database which tries to disk-flush every single transaction individually and the write durability will be as low as 40TB. But something like DFly's swapcache which does bulk writes in 64K+ blocks the write durability will be dramatically improved.
Write amplification is basically due to the fact that a MLC flash chip uses a 128KB write/erase block. Smaller writes either have to be write-combined or otherwise eat a ton more durability due to having to write the whole block than larger writes would. The result is 'write amplification'... more flash is being written to than the actual data being written by the computer. Write combining also requires garbage collection later on... a rewriting which itself creates additional write amplification.
In anycase, this makes flash totally unsuitable for ram-like activities, but quite suitable for filesystem logs and file data/meta-data caching. Perhaps IBM's M-RAM will be able to fill that niche in a few years. We will just have to see.
Typically 2x2G sticks are cheaper than 1x4G stick, particularly when it has to be ECC memory and DDR3. If you are talking about non-ECC memory then you aren't talking seriously. non-ECC memory is just fine for a consumer desktop (though even that is arguable when one is talking about storage in excess of 4GB), but in a server environment ECC is pretty much required. As of about a year ago I've started buying only ECC memory for desktops too.
Google did a study on memory in 2009, it raised a lot of eyebrows. Let me try googling up some references for people. cnet article. There. That references the pdf too if you want to read the actual paper.
This is kinds like comparing apples to oranges. Think of the SSD as another intermediate fully random-accessible cache layer that is slower than ram but much faster than a hard drive. Consider the cost of placing, say, 40G of ram in a server. That's a lot of DIMM slots, a more expensive mobo, lots of expensive high density dram, verses the cost of a 40G SSD ($115 from Intel). So even though the SSD is more expensive per gigabyte than a normal HD, it is considerably less expensive per gigabyte relative to dram and far denser. Perfect for another cache layer.
Access times through a standard SATA interface are not all that bad either. Certainly NOT 3-digit microseconds. Random read access time is something like 38uS with SATA-II @ 26K IOPS with the cheapest Intel SSD. That isn't bad at all for access to (~40G-160G) worth of SSD per SATA channel.
Much faster custom PCIe card based SSDs exist but they are really only useful for dealing with database transactions. System performance (sans database transaction tests) is going to be fairly agnostic to any access time less than around 100uS. The more important feature is the full random access capability of the SSD verses a normal HD. HD performance goes to hell when it has to be accessed randomly... as in 6mS hell. 38uS vs 6ms... hrmmm.
Not sure why you think it would be viable. Small server racks still have very deep footprints and already have plenty of front-loaded 2.5" and/or 3.5" hot-swappable slots. You are advocating that this DIMM thingy would somehow be an improvement? It isn't hot-swappable, it still needs a separate mobo SATA connector (and cable), you actually have to PULL the freaking server out of the rack to change it out. It essentially can't be upgraded. It isn't commodity hardware. AND it is low density compared to what can be stuffed into a 2.5" or 3.5" SSD. Servers are the last place you would ever want to use one of these things.
The size argument only works if all you wanted was one of these things, and only if space were at a premium. Space is not at a premium in racked servers, not even for 1U. There is always going to be room for 6-8 front-loaded 2.5" standard form factor drives.
I think you are misapprehending the density argument. These DIMM slot SSDs are NOT ultra-high-density items. A standard form factor 2.5" or 3.5" SSD is much higher density when you are talking about more than a few gigabytes worth of SSD. They can fit 1TB+ into a 3.5" form factor already. Also, 1U rack mount boxes have no trouble fitting a whole crapload of 2.5" or 3.5" front-loaded slots into the box. It is after all a fairly deep form factor.
In a server room these DIMM SSDs are the last thing you would ever want to use. Not hot swappable, low density, custom-fit hardware. I wouldn't touch these things with a ten-foot pole.
But this makes even LESS sense for large-form-factor mobos. If you want to maximize density you buy a high-density SSD (they come in terrabyte sizes now, after all). You don't buy a hundred custom-fit DIMMs with discrete SATA connectors. It doesn't even make any sense for 1U FF, since 2.5" drive bays trivially fit in that form factor.
But not more useful than actually putting ram in that slot, since most small form-factor motherboards are also going to have a minimal number of DIMM slots anyway. One rarely sees more than 4 slots and I don't know about everyone else but I always populate all my DIMM slots so I don't have to purchase ultra-high density sticks (which cost a premium).
There is a very good reason why Apple had to use this sort of thing... a custom-fit SSD in a custom, basically non-upgradeable item (people who buy Apple stuff tend to replace the machines en-toto and not do piecemeal upgrades). Since custom-fit essentially makes the stuff non-upgradeable it just isn't suitable for any other environment. One might not care so much when one purchases the item initially but I guarentee that people will start to care very much when, a year or two down the line, they find the part no longer available and their hardware now worthless because it can't be upgraded.
So for Apple, it may be a good thing, but sold as a general consumer item it is going to become a has-been very quickly. Except for the ultra-thin market a 2.5" SSD (e.g. most of the Intel SSDs) is plenty small enough. If there were actually demand for this sort of thing we will also see case makers react very quickly and start pushing 2.5" slot-only cases (especially now that the CD/DVD form factor is starting to disappear in favor of USB).
I guess you think a brain-dead one-liner comment like that is meaningful. Try again. I'm sure if you actually spend more than 5 seconds thinking about it you can come up with something better.
I think its a bit silly too. For one thing, there is ALREADY a suitable form factor: mini-PCIe. And two, DIMM slots change every year. Anyone buying this dimm-based SSD is basically buying a custom part with no resale value (because its form factor will become obsolete very quickly) and wasting a memory slot that they might actually want to use in the future. Bad news all around.
Not sure I would call it an OS hack but DragonFly has precisely that, called swapcache. Swapcache Manual Page. It isn't so much making standard paging work better (systems rarely have to 'page' these days) but instead its ability to cache clean data and meta-data from the much larger terrabyte+ hard drive that makes the difference. Anyone who has more than a few hundred thousand files to contend with will know what I mean.
-Matt
The easiest way to understand this is to consider a boat or vehicle heading in one direction with the wind going crosswise to that direction (e.g. left to right while the vehicle is going straight). Then add a sail.
In a (forward-to-back) frictionless environment no matter how fast the vehicle is going there will still be wind going from left-to-right capable of driving the sail, powering the vehicle forwards even faster. In reality the faster the vehicle is going the more the apparent wind direction shifts forward, and ultimately friction combined with the cross wind effectively becoming a head wind limits how fast the vehicle can go.
I dunno whether this would work in space. The reason a vehicle can be powered forwards with a cross-wind is, of course, that the vehicle is anchored left-to-right. i.e. it can't slide left to right, it can only slide forwards, so the power generated by the sail all goes to driving the vehicle forwards. A sail-boat works in a similar fashion (though there is an added feature in that the keel of a sailboat actually forms a foil in the water which counters the pressure on the mast). A space vehicle has nothing to 'anchor' it per-say, though I think it would be possible to create a keel-like solar sail element to partially anchor the vehicle and drive it in a more desirable direction.
I just make a 32G partition myself. Actually I just dos/gpt partition the whole disk but then in UNIX I create a smaller partition and leave 8G unpartitioned.
It doesn't matter, just as long as the unused space is not written to. Again, on a factory-fresh drive. If not factory-fresh you have to format it to factory fresh or TRIM the whole drive (destroying all data on it) before partitioning or the drive will not know that the unpartitioned area is unused space.
Oh, I had better add another note on performance benchmarks. SSDs require idle time for wear leveling and lookup table decomplexification (not an english word:-)) to run efficiently. Most benchmarks don't give drives the same amount of idle time that a real life scenario gives them. OCZ drives are particularly sensitive to this but all SSDs need idle time.
The biggest single issue when it comes to maintaining high performance over the life of a SSD (and here I am talking mainly about random read performance) is the firmware. I think everyone has seen the massive improvements in firmware over the last several years. I expect those improvements to continue.
Also on my previous comment. I had two points initially but it turned into four:-)
I think there are two aspects to TRIM that need to be understood. First is the ability to send the command over the SATA link. If the drive is idle then it certainly can't hurt but since TRIM is not a NCQ command you cannot send it while also having pending reads or writes. That is, the SATA driver and/or chipset firmware cannot send it concurrently with other commands.
The second aspect is TRIMs ability to free up physical flash for use by the wear leveling algorithm, thus potentially improving the wear leveling. However, the performance of the wear leveling algorithm is going to operate on a log curve against available storage. Partitioning some space off on a newly purchased drive will get into the 80th percentile immediately (that being my guess, not tested), so freeing up more space via TRIM is not going to improve matters much more. Of course, a major problem with this is that you then wind up making assumptions on durability based on your filesystem never getting over 90% full. If your filesystem does get over 90% full all your assumptions go out the window because TRIM will no longer be effective.
A third issue with TRIM is that it might actually create additional write combining overhead if the filesystem is not careful using it. If a filesystem is using e.g. 4K clusters and isn't packing the free space, TRIMming out those little 4K holes can actually make the lookups more complex. When used properly TRIM can reduce write combining complexity by cleaning out cruft that the filesystem doesn't care about. Pick your poison... it all depends how it is used.
A fourth issue with TRIM is that it is very unclear to me whether the SSD will guarantee read-all-zero's for TRIMmed areas or whether it will return stale data which can then later disappear when the wear leveling code uses the space. This can be a major danger area for filesystem code which might depend on data stability on read() regardless of whether the area read has been designated as free space or not.
Now I'm not saying that TRIM is bad. What I am saying is that TRIM can open a pandora's box of potential issues which partitioning a smaller space avoids.
No, the SSD has no clue about partitions. All it knows about is what has been written to and what has not. So if you never write to an area the SSD will use that flash as part of its wear leveling. You can't depend on the filesystem never writing to an area, you have to partition the area for your filesystem to use which leaves some of the SSD's storage unused. e.g. 32G on a 40G SSD.
If you have a good pile of games then you already spent gobs of money on them at $50 a shot plus subscription (depending on the game), as well as likely having spent gobs of money on a good video card and gobs of money on a good motherboard with multiple PCIe slots. At that point spending even more gobs of money on a larger SSD is not going to be a concern:-). In fact, a gamer is far more likely to desire a SSD than a non-gamer since the games will load a whole lot more quickly, and some have to page data in while they are running (most of the large-world MMPORGs for example).
However, I will give you points on the space usage. Modern video games tend to eat a lot more than 20G these days.
Yes you can. The Intels store the number of writes along with the wear factor. If you do a smartctl -a with smartmontools smart id #225 Load_Cycle_Count is the number of writes x 32MB. You can use that combined with the wear level (attribute 233, starts at 99 and drops to 00) to figure out the write amplification factor.
So for example on one of my servers I get 252262 (x 32MB = 8TB) and the wear level indicator is down to 95% from 99%. ~5% wear on 8TB worth of writes calculates to around 160TB durability.
Write amplification is an important issue and anyone using a SSD should use a filesystem/RAID on top of it that matches the write block size if possible. For MLC flash the write block size is 128KB. Most filesystems do not have 128K blocks but at least on DragonFly HAMMER's 16K/64K blocks seem to produce fairly low write amplification levels. For a RAID this means you want to use a 128K stripe on each drive. You also want to make sure the partitions are at least 128KB-aligned to the raw drive. We use 1MB alignment ourselves. SSDs should be able to write-combine unaligned but sequential writes but performance should be a lot better if you align things right off the bat so it doesn't have to write-combine as much. Write combining is a major feature in a modern SSD but it is also responsible for the degradation in performance over time so you still want to minimize it.
Slashdot Mirror
Intel SSDs have some horrible issues when SMART command sequences are interleaved with normal disk accesses. That is, when you run smartctl while the drive is busy doing other things. The drives go tits-up when that happens.
I've also noticed significant training time differences between Intel SSDs and WD HDs when connected to 6Gb/s SATA ports when using newer AMD chipsets. The AMD chipsets (supporting 6Gb/s SATA ports) have fairly poor firmware and it takes some massaging in our AHCI driver to get it to properly probe an Intel SSD at 3Gb/s. There were no problems with the WD HDs so I suspect poor or fragile SATA/AHCI firmware in both the cpu chipset AND in the Intel SSD.
In anycase, I've had very good results with all of my Intel SSDs to date, and very good results with the WD Caviar series of HDs. Nearly all of my Seacrates have failed, some well before their time. I don't buy Seagate HDs any more. I also no longer buy high-rpm drives, for any reason. They simply wear out more quickly than lower-rpm drives. Instead we continue to experiment with SSD + HD combos (using DragonFly's swapcache feature) to deal with the lower performance of the lower-rpm HDs.
-Matt
Well, the i7-990x is certainly a fast processor but I don't see the point comparing it against a 965 without turbo-boost. They are effectively comparing a 3.8 GHz i7 (when it isn't running all its cpus.. that's how turbo boost works for both vendors) against a 3.4 GHz phenom II. Well Duh! The phenom ii x6 1100T black is 1/4 the price and runs 3.7 GHz out of the box in turbo boost mode, and it can be trivially and reliably overclocked to 3.8 GHz on all 6 cpus with turbo boost turned off (and to 4.0 GHz with moderately good cooling).
Intel still has faster cpus clock for clock, but not by a whole lot and the price/performance ratio for the i7 is horrible. Expensive cpu, expensive ram... come on.
-Matt
All our current servers use a small 40G Intel SSD to cache copies of filesystem meta-data, plus data for often-accessed files and databases. Since the data sets being served are far, far larger than the ram in the machine this leads to a massive improvement in efficiency and a massive reduction in the load on the hard drives. Actual write activity is minimal, the SSDs will easily last 20 years at their current wear rate.
It all comes down to the workload. A very large swath of workload types can use SSDs RIGHT NOW without shredding them to bits, so it's pretty stupid not to use them when a measily little $110 Intel SSD saves you $2500 worth of dram, server motherboards, not to mention a massive savings in power costs by not having stuff 32G of ram into a server.
Some people just don't get. It's ok, I don't take it personally.
-Matt
Insofar as actual swap (as in paging physical ram in and out) goes, it depends heavily on the amount of ram the machine has and the type of work load. Mostly-read workloads with data sets in memory that are too large can be cached in swap without screwing up a SSD. A large dirty data set, however, will cause continuous heavy writing to swap space and that can shorten the life of SSD-based swap very easily.
A system which needs to page something out will stall badly if the pageout activity is rate-limited, thus you just don't want to use an SSD in any situation where huge, continuous pageout rates are expected. Huge pagein/re-pagein rates due to largely static in-memory data sets are fine. Huge pageout rates are not.
It is a different story for filesystem meta-data or data caching. You should be able to control worst-case write rates in those sorts of setups (at least you can with DragonFly's swapcache), making the SSD a huge win under virtually any circumstances.
-Matt
Now that 6GBit/s SATA ports are becoming commonly available on motherboards it's only natural that SSDs follow. Normal HDs can't really take advantage of a 6Gb/s port but SSDs can. These high speed ports will make port multiplier enclosures more useful as well.
There's certainly a lot of use for this sort of thing. SSDs can already replace far more expensive DRAM (and the far more expensive motherboards needed to support lots of DRAM) for numerous problem sets, including mostly-read database accesses. This will significantly reduce the cost of server architectures for large swaths of problem areas.
What we are seeing is a natural progression.
-Matt
The channel has pretty much gone down the tubes, I don't watch it any more. Whenever I flip to it all I see is some ghost busters crap or wrestling. Adult Swim is the only thing that is moderately interesting, and they moved the Anime well past midnight so there's no point trying to watch it on that channel.
For the record, the FarScape movie was the BEST ending to a science fiction series ever. Nothing else comes even remotely close to that ending. But the SciFi channel didn't have much to do with the production of that series.
-Matt
The RAWs from my camera are already 25-35MB each. A quality-9 jpeg post-production final is usually in the 7-10MB range. I archive both so I'm sitting on about ~40MB per picture in archive storage. Needless to say it adds up pretty quickly.
I keep the archive on a 2TB drive which is backed up as part of my normal backup, meaning it gets backed up to another machine on the LAN and from there to a colocated off-site box. So I have three physically separated copies. I also usually wind up uploading the jpegs to my paid account on flickr for distribution and for 'just in case'. And even though it isn't the RAWs it's still what is most important to me... a viewable picture.
I would caution against having a single copy with no backup, even if it is on a RAIDed system. That's a recipe for complete data loss.
On my laptop I have around a ~120G SSD to spool-off RAWs taken from the camera's 16G card when I'm on the road. I try to do that every day just in case the card fails (which has happened to me), or in case the camera or laptop gets stolen. I only erase the cards at the last possible moment in order to retain local backups as long as possible.
I usually don't try to do post-production on the laptop. Post-production with lightroom is fairly straight-forward though if you spend some time taking the original picture properly Canon's free software works just fine too. Frankly it takes actually printing the pictures out to get all the parameters correct, even good screens don't really match printed output. I don't like to 'play' with my pictures like other people, I like them to be as original as possible so most of lightroom's features go unused.
-Matt
The TOS bit is almost useless. It is abused mightily and even standard services such as ssh can't really tell the difference between an interactive session and a batch session. So there's no real point in trying to queue based on the bit.
-Matt
It's actually more around 10,000 cycles for consumer grade MLC flash (which is what you find in most SSDs). SLC flash runs around 100,000 cycles. There's been a lot of misinformation on this topic but the easiest way to think about it is to consider the actual write durability that people have been experiencing with SSDs. Take an Intel 40G SSD for example. The vendor-specified write durability is 35TB (I always say 40TB just to make the numbers easy), or 1000x, which assumes a very high write amplification factor of 10x. The ACTUAL durability is closer to 200TB with a 2x write amplification factor when used wisely, which is about what we get with DragonFly's swapcache feature. But it depends heavily on how the SSD is used. Put a normal windblows filesystem on a SSD and you will likely see durabilities more in the range of 40-80TB due to higher write amplification factors and heavier write combining loads on the SSD controller. Put a stupid database which tries to disk-flush every single transaction individually and the write durability will be as low as 40TB. But something like DFly's swapcache which does bulk writes in 64K+ blocks the write durability will be dramatically improved.
Write amplification is basically due to the fact that a MLC flash chip uses a 128KB write/erase block. Smaller writes either have to be write-combined or otherwise eat a ton more durability due to having to write the whole block than larger writes would. The result is 'write amplification'... more flash is being written to than the actual data being written by the computer. Write combining also requires garbage collection later on... a rewriting which itself creates additional write amplification.
In anycase, this makes flash totally unsuitable for ram-like activities, but quite suitable for filesystem logs and file data/meta-data caching. Perhaps IBM's M-RAM will be able to fill that niche in a few years. We will just have to see.
-Matt
Typically 2x2G sticks are cheaper than 1x4G stick, particularly when it has to be ECC memory and DDR3. If you are talking about non-ECC memory then you aren't talking seriously. non-ECC memory is just fine for a consumer desktop (though even that is arguable when one is talking about storage in excess of 4GB), but in a server environment ECC is pretty much required. As of about a year ago I've started buying only ECC memory for desktops too.
Google did a study on memory in 2009, it raised a lot of eyebrows. Let me try googling up some references for people. cnet article. There. That references the pdf too if you want to read the actual paper.
-Matt
This is kinds like comparing apples to oranges. Think of the SSD as another intermediate fully random-accessible cache layer that is slower than ram but much faster than a hard drive. Consider the cost of placing, say, 40G of ram in a server. That's a lot of DIMM slots, a more expensive mobo, lots of expensive high density dram, verses the cost of a 40G SSD ($115 from Intel). So even though the SSD is more expensive per gigabyte than a normal HD, it is considerably less expensive per gigabyte relative to dram and far denser. Perfect for another cache layer.
Access times through a standard SATA interface are not all that bad either. Certainly NOT 3-digit microseconds. Random read access time is something like 38uS with SATA-II @ 26K IOPS with the cheapest Intel SSD. That isn't bad at all for access to (~40G-160G) worth of SSD per SATA channel.
Much faster custom PCIe card based SSDs exist but they are really only useful for dealing with database transactions. System performance (sans database transaction tests) is going to be fairly agnostic to any access time less than around 100uS. The more important feature is the full random access capability of the SSD verses a normal HD. HD performance goes to hell when it has to be accessed randomly... as in 6mS hell. 38uS vs 6ms... hrmmm.
-Matt
Not sure why you think it would be viable. Small server racks still have very deep footprints and already have plenty of front-loaded 2.5" and/or 3.5" hot-swappable slots. You are advocating that this DIMM thingy would somehow be an improvement? It isn't hot-swappable, it still needs a separate mobo SATA connector (and cable), you actually have to PULL the freaking server out of the rack to change it out. It essentially can't be upgraded. It isn't commodity hardware. AND it is low density compared to what can be stuffed into a 2.5" or 3.5" SSD. Servers are the last place you would ever want to use one of these things.
The size argument only works if all you wanted was one of these things, and only if space were at a premium. Space is not at a premium in racked servers, not even for 1U. There is always going to be room for 6-8 front-loaded 2.5" standard form factor drives.
-Matt
I think you are misapprehending the density argument. These DIMM slot SSDs are NOT ultra-high-density items. A standard form factor 2.5" or 3.5" SSD is much higher density when you are talking about more than a few gigabytes worth of SSD. They can fit 1TB+ into a 3.5" form factor already. Also, 1U rack mount boxes have no trouble fitting a whole crapload of 2.5" or 3.5" front-loaded slots into the box. It is after all a fairly deep form factor.
In a server room these DIMM SSDs are the last thing you would ever want to use. Not hot swappable, low density, custom-fit hardware. I wouldn't touch these things with a ten-foot pole.
-Matt
But this makes even LESS sense for large-form-factor mobos. If you want to maximize density you buy a high-density SSD (they come in terrabyte sizes now, after all). You don't buy a hundred custom-fit DIMMs with discrete SATA connectors. It doesn't even make any sense for 1U FF, since 2.5" drive bays trivially fit in that form factor.
-Matt
But not more useful than actually putting ram in that slot, since most small form-factor motherboards are also going to have a minimal number of DIMM slots anyway. One rarely sees more than 4 slots and I don't know about everyone else but I always populate all my DIMM slots so I don't have to purchase ultra-high density sticks (which cost a premium).
There is a very good reason why Apple had to use this sort of thing... a custom-fit SSD in a custom, basically non-upgradeable item (people who buy Apple stuff tend to replace the machines en-toto and not do piecemeal upgrades). Since custom-fit essentially makes the stuff non-upgradeable it just isn't suitable for any other environment. One might not care so much when one purchases the item initially but I guarentee that people will start to care very much when, a year or two down the line, they find the part no longer available and their hardware now worthless because it can't be upgraded.
So for Apple, it may be a good thing, but sold as a general consumer item it is going to become a has-been very quickly. Except for the ultra-thin market a 2.5" SSD (e.g. most of the Intel SSDs) is plenty small enough. If there were actually demand for this sort of thing we will also see case makers react very quickly and start pushing 2.5" slot-only cases (especially now that the CD/DVD form factor is starting to disappear in favor of USB).
-Matt
I guess you think a brain-dead one-liner comment like that is meaningful. Try again. I'm sure if you actually spend more than 5 seconds thinking about it you can come up with something better.
-Matt
I think its a bit silly too. For one thing, there is ALREADY a suitable form factor: mini-PCIe. And two, DIMM slots change every year. Anyone buying this dimm-based SSD is basically buying a custom part with no resale value (because its form factor will become obsolete very quickly) and wasting a memory slot that they might actually want to use in the future. Bad news all around.
-Matt
Not sure I would call it an OS hack but DragonFly has precisely that, called swapcache. Swapcache Manual Page. It isn't so much making standard paging work better (systems rarely have to 'page' these days) but instead its ability to cache clean data and meta-data from the much larger terrabyte+ hard drive that makes the difference. Anyone who has more than a few hundred thousand files to contend with will know what I mean. -Matt
The easiest way to understand this is to consider a boat or vehicle heading in one direction with the wind going crosswise to that direction (e.g. left to right while the vehicle is going straight). Then add a sail.
In a (forward-to-back) frictionless environment no matter how fast the vehicle is going there will still be wind going from left-to-right capable of driving the sail, powering the vehicle forwards even faster. In reality the faster the vehicle is going the more the apparent wind direction shifts forward, and ultimately friction combined with the cross wind effectively becoming a head wind limits how fast the vehicle can go.
I dunno whether this would work in space. The reason a vehicle can be powered forwards with a cross-wind is, of course, that the vehicle is anchored left-to-right. i.e. it can't slide left to right, it can only slide forwards, so the power generated by the sail all goes to driving the vehicle forwards. A sail-boat works in a similar fashion (though there is an added feature in that the keel of a sailboat actually forms a foil in the water which counters the pressure on the mast). A space vehicle has nothing to 'anchor' it per-say, though I think it would be possible to create a keel-like solar sail element to partially anchor the vehicle and drive it in a more desirable direction.
-Matt
I just make a 32G partition myself. Actually I just dos/gpt partition the whole disk but then in UNIX I create a smaller partition and leave 8G unpartitioned.
It doesn't matter, just as long as the unused space is not written to. Again, on a factory-fresh drive. If not factory-fresh you have to format it to factory fresh or TRIM the whole drive (destroying all data on it) before partitioning or the drive will not know that the unpartitioned area is unused space.
-Matt
Oh, I had better add another note on performance benchmarks. SSDs require idle time for wear leveling and lookup table decomplexification (not an english word :-)) to run efficiently. Most benchmarks don't give drives the same amount of idle time that a real life scenario gives them. OCZ drives are particularly sensitive to this but all SSDs need idle time.
The biggest single issue when it comes to maintaining high performance over the life of a SSD (and here I am talking mainly about random read performance) is the firmware. I think everyone has seen the massive improvements in firmware over the last several years. I expect those improvements to continue.
Also on my previous comment. I had two points initially but it turned into four :-)
-Matt
I think there are two aspects to TRIM that need to be understood. First is the ability to send the command over the SATA link. If the drive is idle then it certainly can't hurt but since TRIM is not a NCQ command you cannot send it while also having pending reads or writes. That is, the SATA driver and/or chipset firmware cannot send it concurrently with other commands.
The second aspect is TRIMs ability to free up physical flash for use by the wear leveling algorithm, thus potentially improving the wear leveling. However, the performance of the wear leveling algorithm is going to operate on a log curve against available storage. Partitioning some space off on a newly purchased drive will get into the 80th percentile immediately (that being my guess, not tested), so freeing up more space via TRIM is not going to improve matters much more. Of course, a major problem with this is that you then wind up making assumptions on durability based on your filesystem never getting over 90% full. If your filesystem does get over 90% full all your assumptions go out the window because TRIM will no longer be effective.
A third issue with TRIM is that it might actually create additional write combining overhead if the filesystem is not careful using it. If a filesystem is using e.g. 4K clusters and isn't packing the free space, TRIMming out those little 4K holes can actually make the lookups more complex. When used properly TRIM can reduce write combining complexity by cleaning out cruft that the filesystem doesn't care about. Pick your poison... it all depends how it is used.
A fourth issue with TRIM is that it is very unclear to me whether the SSD will guarantee read-all-zero's for TRIMmed areas or whether it will return stale data which can then later disappear when the wear leveling code uses the space. This can be a major danger area for filesystem code which might depend on data stability on read() regardless of whether the area read has been designated as free space or not.
Now I'm not saying that TRIM is bad. What I am saying is that TRIM can open a pandora's box of potential issues which partitioning a smaller space avoids.
-Matt
No, the SSD has no clue about partitions. All it knows about is what has been written to and what has not. So if you never write to an area the SSD will use that flash as part of its wear leveling. You can't depend on the filesystem never writing to an area, you have to partition the area for your filesystem to use which leaves some of the SSD's storage unused. e.g. 32G on a 40G SSD.
-Matt
If you have a good pile of games then you already spent gobs of money on them at $50 a shot plus subscription (depending on the game), as well as likely having spent gobs of money on a good video card and gobs of money on a good motherboard with multiple PCIe slots. At that point spending even more gobs of money on a larger SSD is not going to be a concern :-). In fact, a gamer is far more likely to desire a SSD than a non-gamer since the games will load a whole lot more quickly, and some have to page data in while they are running (most of the large-world MMPORGs for example).
However, I will give you points on the space usage. Modern video games tend to eat a lot more than 20G these days.
-Matt
Yes you can. The Intels store the number of writes along with the wear factor. If you do a smartctl -a with smartmontools smart id #225 Load_Cycle_Count is the number of writes x 32MB. You can use that combined with the wear level (attribute 233, starts at 99 and drops to 00) to figure out the write amplification factor.
So for example on one of my servers I get 252262 (x 32MB = 8TB) and the wear level indicator is down to 95% from 99%. ~5% wear on 8TB worth of writes calculates to around 160TB durability.
Write amplification is an important issue and anyone using a SSD should use a filesystem/RAID on top of it that matches the write block size if possible. For MLC flash the write block size is 128KB. Most filesystems do not have 128K blocks but at least on DragonFly HAMMER's 16K/64K blocks seem to produce fairly low write amplification levels. For a RAID this means you want to use a 128K stripe on each drive. You also want to make sure the partitions are at least 128KB-aligned to the raw drive. We use 1MB alignment ourselves. SSDs should be able to write-combine unaligned but sequential writes but performance should be a lot better if you align things right off the bat so it doesn't have to write-combine as much. Write combining is a major feature in a modern SSD but it is also responsible for the degradation in performance over time so you still want to minimize it.
-Matt