Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Curious Case of SSD Performance In OS X

Posted by timothy on from the and-mysteriouser dept.

mr_sifter writes "As we've seen from previous coverage, TRIM support is vital to help SSDs maintain performance over extended periods of time — while Microsoft and the SSD manufacturers have publicized its inclusion in Windows 7, Apple has been silent on whether OS X will support it. bit-tech decided to see how SSD performance in OS X is affected by extended use — and the results, at least with the Macbook Air, are startling. The drive doesn't seem to suffer very much at all, even after huge amounts of data have been written to it."

20 of 205 comments (clear)

  1. Wow, a pro Mac story by Anonymous Coward · · Score: 5, Funny

    That is startling!

    1. Re:Wow, a pro Mac story by makomk · · Score: 4, Informative

      An inaccurate pro-Mac story too, by the looks of it. For the Mac test, they didn't properly erase the SSD to its initial state - instead they used a tool that filled the disk with zeros, marking the entire drive as in-use. It's no surprise that they failed to see any performance degradation as the drive filled up: the performance was already maximally degraded from the start!

  2. I've never seen a problem by mrsteveman1 · · Score: 4, Informative

    I've got a Vertex 60 in a While unibody macbook and it works fine, boot is 7-9 seconds, apps load almost instantly even if i start 10 at the same time.

    I know TRIM doesn't work yet in OS X but the drive seems to take care of itself just fine.

    1. Re:I've never seen a problem by joe_bruin · · Score: 5, Informative

      The impact of the TRIM command is vastly overrated. It is effective on "naive" devices that don't allocate a reserve block pool and therefore have to erase before doing every write. On a modern SSD, the disk controller reserves 5-10% of the physical blocks (beyond those that the host can see) as an extended block pool. These blocks are always known to be free (since they're out of the scope of that OS) and are therefore preemptively erased. So, when your OS overwrites a previously written data block, one of these pre-erased blocks is actually written to and the old block is put in the reserve pool for erasing later at the device's leisure.

      The one case where this isn't true is if you're constantly writing gigs of data to an empty drive. With TRIM commands, most of your drive may have been pre-erased, whereas without it you may overrun the reserve pool's size and then will be waiting on block erase. For normal desktop users, this is a pathological case. In servers and people who do a lot of heavy video editing it may matter a lot more.

    2. Re:I've never seen a problem by Jeff- · · Score: 4, Insightful

      You're missing something.

      Erase blocks and data blocks are not the same size. The block size is the smallest atomic unit the operating system can write to. The erase block size is the smallest atomic unit the SSD can erase. Erase blocks typically contain hundreds of data blocks. They must be relatively larger so they can be electrically isolated. The SSD maintains a map from a linear block address space to a physical block addresses. The SSD may also maintain a map of which blocks within an erase block are valid and fills them as new writes come in.

      Without TRIM, once written, the constituent blocks within an erase block are always considered valid. When one block in the erase block is overwritten, the whole thing must be RMW'd to a new place. With TRIM the drive controller can be smarter and only relocate those blocks that still maintain a valid mapping. This can drastically reduce the overhead on a well used drive.

  3. Lazy reporting, try different OSes by Anonymous Coward · · Score: 4, Interesting

    Maybe they should take the drive over to a Windows XP and Windows 7 box and see if it's the drive hardware being resilient or the OS. The G1 intel drives don't drop a ton after use, and they don't support TRIM. It looks like the Intel G1 flash is artificially capped by the controller. It could be similar here.

  4. This is possible. by anethema · · Score: 5, Informative

    It depends a lot on how the drive works.

    Intel drives actually use the whole drive for scratch space. Until a sector is written to. Then without TRIM it only has its tiny bit of extra scratch space to work with. That's why intel drives degrade so badly without TRIM.

    Indilinx Barefoot controllers on the other hand ONLY use their scratch space, they never use the normal writing space of the drive as scratch space.

    See here.

    http://www.anandtech.com/show/2829/9

    While it does show the synthetic tests degrading with lack of trim, even more than the intel drives, the real world use tests show they suffer almost 0% loss in performance.

    Depending on which controller the drive is using, TRIM could make almost no difference or a world of difference.

    Anand explains it best:

    "Only the Indilinx drives lose an appreciable amount of performance in the sequential write test, but they are the only drives to not lose any performance in the more real-world PCMark Vantage HDD suite. Although not displayed here, the overall PCMark Vantage score takes an even smaller hit on Indilinx drives. This could mean that in the real world, Indilinx drives stand to gain the least from TRIM support. This is possibly due to Indilinx using a largely static LBA mapping scheme; the only spare area is then the 6.25% outside of user space regardless of how used the drive is."

    --


    It's easier to fight for one's principles than to live up to them.
  5. Two quotes stick out by izomiac · · Score: 5, Interesting
    While skimming the article two parts really stood out. First:

    Apple's description of the zeroing format method we used fits the description of what we wanted in terms of resetting the SSD to a clean state

    Zeroing is not the same operation as TRIM. TRIM marks a block as unused, and if you read it you'll either get random data, or zeros (probably the later). Zeroing marks it as in-use, and if you read it you'll get zeros. The SSD's wear management algorithm will move the latter around as though it were real data, whereas it knows the former is "empty" so it won't bother (so the SSD will be faster). In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.

    Secondly, the SSD in the Macbook Air really isn't very fast at all

    Which strengthens the hypothesis that they were comparing one "full" state with another. Pop out the drive, TRIM the whole disk in another OS, and run the benchmark again. It'll probably be a lot faster. It wouldn't surprise me if installing the Mac OS at the factory caused every block on the SSD to be used at least once (e.g. a whole disk image was written), which would mean you'd already be at the worse possible performance degradation.

    1. Re:Two quotes stick out by izomiac · · Score: 5, Interesting
      Well, to be honest I did look a bit more at that part before criticizing it. On page two of the article they elaborate:

      The Macbook Air we received from Apple had previously been sent to other reviewers, so we first needed to get the SSD into a "clean" state. While we have an established way of doing with Windows systems - using HDDerase to perform a low level format - we needed to find a way of doing this with OS X. The OS X installer actually allows you to load an app called Disk Utility, which can partition and format the drive - and one of the options is for a format which zeroes all the data.

      According to Apple, "the "Zero all data" option... takes the erasure process to the next level by converting all binary in the empty portion of the disk to zeros, a state that might be described as digitally blank." The next level? Count. Us. In.

      And the link goes to an Apple site that explains what zeroing the data does and how to do it.

      Once we'd done this with the clean SSD, we then proceeded to give it a damn good thrashing. As with our Windows SSD testing, we filled the SSD with around 112GB of files from a USB hard disk - the files included OS files, game installs and media. We then deleted these files, then copied them across again, repeating the process ten times, so that we'd written over 1TB of data to the SSD.

      So... they wrote over the whole disk with a format, then copied and deleted a bunch of files in hopes to get full coverage of the disk (i.e. exactly what the zeroing format did). That's about three levels of abstraction above what they're trying to test.

    2. Re:Two quotes stick out by broken_chaos · · Score: 5, Informative

      if you read it you'll either get random data, or zeros (probably the later)

      If you read a TRIMmed block directly, most drives will kick back zeroes. You can do this with hdparm -- particularly useful as a method to test if TRIM works (and it even uncovered a bug in ext4's TRIM implementation in data=writeback mode, where TRIM only works on metadata). Run hdparm -I on a SSD, and it'll actually say something along the lines of "Deterministic read ZEROs after TRIM" for most drives.

      In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.

      Very true. There are only two methods I know of to 'clean slate' a full drive -- either TRIM the entire thing (with a tool like hdparm -- this is tricky to get right) or run an ATA Secure Erase command. Most SSDs take the secure erase command and just blank every NAND chip they have (taking ~2 minutes compared to the multiple hours that rotational drives take for the Secure Erase command) -- I've done this on my X-25M and it works brilliantly.

      Unless Apple's Disk Utility actually does a Secure Erase command (which is very unlikely), then their testing methodology is entirely flawed, and their 'resetting' of the drive instead made it behave as if it was entirely, completely, 100% filled to the brim.

  6. Flawed article by ShooterNeo · · Score: 5, Informative

    The article writers made 2 major mistakes that cause their results to be meaningless.

    1. They didn't secure erase the drive, which is what actually puts a drive back into a virgin state. They instead wrote zeroes to every sector, which means that the drive controller probably still thinks those zeroed out sectors are still in use.

    2. The Samsung drive controller has a form of self cleanup that greatly reduces the need for TRIM.

    3. Regardless, the SSD they used was slow as a dog and barely worth using over a HDD.

  7. Something wrong with testing methodology? by whoever57 · · Score: 5, Insightful
    Consider this statement:

    Consider the Vertex: without TRIM, and when used, its sequential read speed for 1,024KB files is 137MB/sec; the Macbook Air manages 105MB/sec. With TRIM, the Vertex manages 258MB/sec in this same test.

    According to their tests, TRIM has a big impact on read speeds, yet according to their explanation, TRIM should only have a significant affect on write speeds.

    --
    The real "Libtards" are the Libertarians!
  8. Re:cheese penis by Anonymous Coward · · Score: 5, Funny

    2.5 million B.C.: OOG the Open Source Caveman develops the axe and releases it under the GPL. The axe quickly gains popularity as a means of crushing moderators' heads.

    100,000 B.C.: Man domesticates the AIBO.

    10,000 B.C.: Civilization begins when early farmers first learn to cultivate hot grits.

    3000 B.C.: Sumerians develop a primitive cuneiform perl script.

    2920 B.C.: A legendary flood sweeps Slashdot, filling up a Borland / Inprise story with hundreds of offtopic posts.

    1750 B.C.: Hammurabi, a Mesopotamian king, codifies the first EULA.

    490 B.C.: Greek city-states unite to defeat the Persians. ESR triumphantly proclaims that the Greeks "get it".

    399 B.C.: Socrates is convicted of impiety. Despite the efforts of freesocrates.com, he is forced to kill himself by drinking hemlock.

    336 B.C.: Fat-Time Charlie becomes King of Macedonia and conquers Persia.

    4 B.C.: Following the Star (as in hot young actress) of Bethelem, wise men travel from far away to troll for baby Jesus.

    A.D. 476: The Roman Empire BSODs.

    A.D. 610: The Glorious MEEPT!! founds Islam after receiving a revelation from God. Following his disappearance from Slashdot in 632, a succession dispute results in the emergence of two troll factions: the Pythonni and the Perliites.

    A.D. 800: Charlemagne conquers nearly all of Germany, only to be acquired by andover.net.

    A.D. 874: Linus the Red discovers Iceland.

    A.D. 1000: The epic of the Beowulf Cluster is written down. It is the first English epic poem.

    A.D. 1095: Pope Bruce II calls for a crusade against the Turks when it is revealed they are violating the GPL. Later investigation reveals that Pope Bruce II had not yet contacted the Turks before calling for the crusade.

    A.D. 1215: Bowing to pressure to open-source the British government, King John signs the Magna Carta, limiting the British monarchy's power. ESR triumphantly proclaims that the British monarchy "gets it".

    A.D. 1348: The ILOVEYOU virus kills over half the population of Europe. (The other half was not using Outlook.)

    A.D. 1420: Johann Gutenberg invents the printing press. He is immediately sued by monks claiming that the technology will promote the copying of hand-transcribed books, thus violating the church's intellectual property.

    A.D. 1429: Natalie Portman of Arc gathers an army of Slashdot trolls to do battle with the moderators. She is eventually tried as a heretic and stoned (as in petrified).

    A.D. 1478: The Catholic Church partners with doubleclick.net to launch the Spanish Inquisition.

    A.D. 1492: Christopher Columbus arrives in what he believes to be "India", but which RMS informs him is actually "GNU/India".

    A.D. 1508-12: Michaelengelo attempts to paint the Sistine Chapel ceiling with ASCII art, only to have his plan thwarted by the "Lameness Filter."

    A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (- 1, Flamebait).

    A.D. 1553: "Bloody" Mary ascends the throne of England and begins an infamous crusade against Protestants. ESR eats his words.

    A.D. 1588: The "IF I EVER MEET YOU, I WILL KICK YOUR ASS" guy meets the Spanish Armada.

    A.D. 1603: Tokugawa Ieyasu unites the feuding pancake-eating ninjas of Japan.

    A.D. 1611: Mattel adds Galileo Galilei to its CyberPatrol block list for proposing that the Earth revolves around the sun.

    A.D. 1688: In the so-called "Glorious Revolution", King James II is bloodlessly forced out of power and flees to France. ESR again triumphantly proclaims that the British monarchy "gets it".

    A.D. 1692: Anti-GIF hysteria in the New World comes to a head in the infamous "Salem GIF Trials", in which 20 alleged GIFs are burned at the stake. Later investigation reveals that many of the supposed GIFs were actually PNGs.

    A.D. 1769: James Watt patents the one-click steam engine.

    A.D. 1776: Trolls, angered by CmdrTaco's passage of the Moderation Act, rebel. After a several-year flame war, the trol

  9. Re:Bad Summary by mrsteveman1 · · Score: 4, Informative

    Actually TRIM ensures there are free blocks of flash ready to be written quickly, otherwise they have to be erased first even if the OS thinks that particular logical address wasn't being used, which has a substantial performance penalty.

  10. Re:Bad Summary by mestar · · Score: 5, Funny

    Yes, and as we know, solid state disks lose performance when files are fragmented, because, when the disk spins, err, i mean the electrons, the heat goes around, ah, fuck it.

  11. Re:Bad Summary by DJRumpy · · Score: 4, Interesting

    I have to wonder why they didn't boot into Windows on the same PC and repeat the tests. That would have identified if it was a hardware issue, or a software (Filesystem) issue that caused the irregularity.

  12. Re:OS X has nothing to do with it by iotaborg · · Score: 4, Interesting

    FWIW, I've been using an Intel X-25M 160 GB SSD on my Mac Pro for over half a year, and my read/write speeds are essentially unchanged from when I got it... this is using xbench to check.

  13. Re:OS X has nothing to do with it by dfghjk · · Score: 4, Informative

    "If you put a good SSD (e.g. Intel) in your Mac the behavior will be completely different."

    Completely different from what?

    I have put an Intel SSD in a Mac, in fact 2 in a RAID 0 configuration, and it doesn't behave like you are insinuating it does.

    The performance of the Samsung drives does suck but it isn't because they are "pre-degraded".

  14. Re:Bad Summary by scdeimos · · Score: 4, Informative

    You both need to read up on TRIM (and I'll leave it at that)... http://en.wikipedia.org/wiki/TRIM

  15. Funny but not totally correct by Mathinker · · Score: 4, Informative

    Yes, and as we know, solid state disks lose performance when files are fragmented, because, when the disk spins, err, i mean the electrons, the heat goes around, ah, fuck it.

    Your reply was witty, but all of the EEs here on Slashdot will tell you that, for example, trying to write to random addresses in, for example, DDR2 memory when you could have written the same data to contiguous addresses, is a very bad idea. The only reason programmers don't feel this difference quite so much is that the cache hierarchy of the CPU is babying them.