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."

37 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. OS X has nothing to do with it by Wesley+Felter · · Score: 3, Interesting

    You can't really draw any conclusions from these results. In one particular Mac, Apple ships a particular Samsung SSD that doesn't degrade, probably because its "clean" performance is already terrible (you might think of it as "pre-degraded"). In other Macs Apple ships Toshiba SSDs that may have completely different behavior. If you put a good SSD (e.g. Intel) in your Mac the behavior will be completely different.

    1. 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.

    2. 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".

    3. Re:OS X has nothing to do with it by billcopc · · Score: 2, Informative

      TRIM performance is directly tied to an SSD's erase performance. All TRIM does is tell the SSD which blocks are free to erase in its spare time. EVERY write to a NAND cell requires an erase, so if the SSD can perform that step while the system is idle, the next write to that cell can be performed immediately.

      TRIM allows SSDs to "cheat" by doing some of the work ahead of time. The dirty performance is the normal, sustainable speed you should expect from your SSD. Any gains from TRIM are the result of pre-erasing cells when you're idling... if your system never idles (e.g. a busy database), TRIM won't help at all.

      --
      -Billco, Fnarg.com
    4. Re:OS X has nothing to do with it by m.dillon · · Score: 3, Informative

      Strange reasoning. In anycase, the Intel SSDs appear to use a combination of static and dynamic wear leveling and it seems to do a really good job. A really, really good job. I have over a half dozen of the 40G drives and have not noticed any reduction in read or write performance.

      There seem to be dozens of different write combining and wear leveling implementations across vendors. Dozens and dozens. Variations between vendors are significant and even variations between revisions from the same vendor can be significant. Drives sold just two years ago are likely to have primitive weal leveling and write combining verses drives sold today. Vendor technology can be years apart.

      I guess you can thank MLC flash for the radical improvement in wear leveling and write combining algorithms over the last few years. Vendors can't really cheat when they use MLC flash... the algorithms have to work properly or the device has an early death due to the limited cell durability.

      Personally speaking, I am very confident about Intel's technology. OCZ seems to be pretty good too but it is also full of hacks and does not properly support SATA NCQ. I'm sure there are some other good vendor technologies out there but there are also definitely some very bad ones that are years behind Intel. In the SSD space, the quality of the software matters a lot.

      -Matt

  3. 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. Re:I've never seen a problem by onefriedrice · · Score: 2, Informative

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

      It probably is taking care of itself. Some OCZ drives, including the Vertex series, can have firmware which forgoes Trim support in favor of some form of garbage collecting.

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
  4. 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.

    1. Re:Lazy reporting, try different OSes by wvmarle · · Score: 2, Informative

      TFA stated this is actually a follow-up test on tests done on Windows, where they found TRIM to have a large effect on the drive's performance. This included a drive they suspect to be technically similar to the one in the Mac (same manufacturer, age) - though unfortunately no direct comparison of actual hardware.

  5. 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.
  6. 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.

    3. Re:Two quotes stick out by AllynM · · Score: 3, Interesting

      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.

      Not only that, but writing to all free space of many SSD's will *drop* their IOPS performance since the drive now has to track *all* sectors in the LBA remap table. This is especially true with Intel drives (even the 2nd gen). Additionally, without TRIM, most drives will then continue to track all LBA's as long as used in that same Mac.

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

      A Macbook Air is just about the worst test of SSD performance, as its SATA and other busswork is run in a much reduced power mode, meaning the bottleneck is not the SSD at all. A worst-case degraded SSD in an Air will still be faster than the other bottleneck in that system.

      Allyn Malventano, CTNC, USN
      Storage Editor, PC Perspective

      --
      this sig was brought to you by the letter /.
    4. Re:Two quotes stick out by scdeimos · · Score: 2, Interesting

      I read the Apple link (http://support.apple.com/kb/HT1820) and I don't see how it would be equivalent to TRIM on an SSD device.

      Zeroing a device, as per the link, just writes zeroes to every block on it. From an SSD's point of view this means that every block is in use and just happens to contain zeros. Next time a request is made to write to a block it requires a (comparatively slow) read-modify-erase-write cycle. It won't make an SSD faster, but it may serve to securely erase the data on it (depending on its absence of wear levelling techniques).

      TRIM on the other hand is used by the file system driver to say "I've deleted all data in this block, you can disregard it now." The device will erase it at its leisure. Next time a write is made to that block it's a simple (and fast) write cycle, without the read-modify and costly erase. Saving the erase cycle from interfering with a write is how TRIM-enabled drives gain their performance boost.

      TFA's tests were invalid, because the drive was always in a degraded mode (assuming of course the 2008-era Samsung even supported TRIM).

  7. 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.

    1. Re:Flawed article by ekran · · Score: 2, Interesting

      I think that the biggest mistake in the test was that they wrote zeros to the drive first, which means that the blocks got allocated (dirty) and had to be read/rewritten with new data when the next phase of the test started. So, basically both tests are the same and it's no wonder they got about the same test results.

  8. 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!
  9. Re:Apple is waiting to patent iSSD first by fuzzyfuzzyfungus · · Score: 2, Insightful

    The complicating factor, when trying to make any useful statements about "What Operating System Whatever does on SSDs" is that SSDs are totally free to do whatever crazy stuff internally, so long as they can present a coherent block device abstraction over the IDE/SATA/etc. bus.

    TRIM happens to make the design problem easier; because it allows you to throw data on the floor when the OS says that they are no longer needed, rather than having to treat everything that isn't explicitly deleted as still good. However, before TRIM was available, manufacturers tended to do their best to design around its absence. This generally had a cost(either monetary, with lots of reserve flash driving up the cost, performance, with the drive either starting fast and taking a nosedive or just not being all that fast, or predictability, a given write operation could take milliseconds or it could take literal seconds, depending on the drive state).

  10. 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

  11. Re:Traditional denial by Jane+Q.+Public · · Score: 2, Informative

    That's not the problem with their antenna. As it turns out, the algorithm they used to show signal strength ("bars") was incorrect... generally showing more signal strength than there really was. So what was happening was this: people thought they had a good signal when they really didn't. Then the slight loss from bridging the antennas pretty much took their connection down. It SHOWED as a big difference, but the real difference was very small.

    The same tests done in an area where there is actually a good signal get completely different results. There is almost no different whether the antennas are bridged or not.

  12. I didn't understand the 'benchmark' by Joce640k · · Score: 3, Interesting

    FTA: "We simulated this by copying 100GB of mixed files (OS files, multiple game installs, MP3s and larger video files ) to the SSD, deleting them, and then repeating the process ten times,"

    Surely you should be deleting half the files - every other file - then rewriting them. If you copy a bunch of files then delete them all you're leaving the drive in pretty much the same state as it was at the start, the only difference between passes wil be due to the wear levelling algorithms inside the drive. Overall performance at the end will mostly be a result of the initial condition of the drive, not what happened during the test.

    --
    No sig today...
  13. 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.

  14. 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.

  15. 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.

  16. How are the sandforce units going? by AHuxley · · Score: 2, Insightful

    How are Mac users with Mercury Extreme SSD's or the Mushkin ect units doing?
    They might be a bit different to the units Apple found at a set price point to max the profits.
    Most of the Apple users sites seem to like the idea of a ~ TRIM via a removal of all data, zeroing and a copy back of the OS. Thanks

    --
    Domestic spying is now "Benign Information Gathering"
  17. 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

  18. Why not just open fs.blocksize to 64-256k? by redelm · · Score: 2, Insightful
    TRIM just seems to be yet another abstruse abstraction layer. Why not just allow filesystems (HPFS, UFS, ext[234]) to have large blocksizes?

    Jes, I know the Intel MMU pages are either 4k or 4M. And people like "saving disk" since on average half a blocksize is wasted per file. But 4k is a tiny blocksize, set IIRC for newspools that few use. It only wastes 10 MB on a 5,000 file/dir system. That is not enough!

    A 128 kB blocksize to match the hardware bs would "waste" a more reasonable 320 MB. Only 1% of the minimum 32 GB SSD.

  19. Re:Bad Summary by billcopc · · Score: 2, Insightful

    Yes and no. Wear-leveling happens with or without TRIM, but what TRIM does is tell the SSD controller that a block can be treated as "virgin", meaning it can be overwritten in a single pass. This is an optimization as normally one must read the contents of an entire block, combine it with the incoming data, erase the block on-disk and finally write the newly-merged data.

    Contrary to popular ignorance, the slowdown is not caused by "fragmentation" - that's backwards, when the drive is clean it is cheating by skipping part of the write cycle. In other words, an SSD's dirty performance is its normal, sustainable speed. When it is clean, it can go faster because it is being LAZY, by short-cutting the Read-Erase-Update cycle. For obvious reasons, most SSD vendors, particularly in the consumer segment, advertise the maximum speed when really the honest thing would be to advertise the minimum speed.

    --
    -Billco, Fnarg.com
  20. Re:Bad Summary by mysidia · · Score: 3, Interesting

    I have the feeling that if you match the block size of files written to the block size of the SSD (optionally padding with zeros to fill it up) you could get quite a performance boost - and only when the drive starts to fill up start using the unused, zeroed out fragments from the blocks.

    With SSDs it's erase block size that matters most. When a page of memory on a SSD device is being overwritten, the page has to be erased first, and then its contents rewritten.

    Of course if your OS implements SCSI PUNCH or ATA TRIM, immediately when a block is freed, your SSD drive can have the memory erased ahead of time, and ready to use with minimal write latency.

    Most SSDs use an erase block size of 128K. So you would want your entire filesystem's allocation blocks 128K aligned.. in NTFS world, this would mean you need to align the disk partition, at least prior to Vista/Windows 2008.

    I believe MacOS automatically aligns partitions. This issue alone could explain why things might get so bad with Windows, let alone the ridiculously small 4K block size, or fragmentation issues that plague NTFS filesystems.

    And the ideal allocation cluster size is 128K (by default NTFS cluster size is 4K, which is not suitable. for best performance change in such a scenario it to 64K)

    You can think of the performance issue that can occur as something like RAID stripe crossing.

    If you have two 4K blocks side by side, and you need to overwrite just those two blocks.. if they are on different 128K erase blocks, your SSD will be having to write 256K of memory to change 8K of data.

    If those 2 NTFS blocks are on the same SSD block, your ssd flushes and writes 128K of data, maybe.

    This is before we start thinking about wear-levelling algorithms,

    or the fact an efficient SSD will likely keep a pool of non-erased blocks, to satisfy write requests against.

    So as long as there is memory left that was scheduled for erasure and flushed due to TRIM or flushed due to being overwritten, there would be no reason to require an extra in-line ERASE (increasing write latency).

    So the pool of non-erased pages are important, and the critical elements effecting write performance are (1) time to update header blocks to re-map disk blocks to unused flash pages, and (2) time to copy the erase block with changes to the newly mapped location.

  21. TRIM equivalent by m.dillon · · Score: 3, Interesting

    All SSDs have a bit more storage than their rating. Partitioning a little less space on a vendor-fresh drive can double or triple the extra storage available to the SSD's internal wear leveling algorithms. For all intents and purposes this gives you the equivalent of TRIM without having to rely on the OS and filesystem supporting it. In fact, it could conceivably give you better performance than TRIM because you don't really know how efficient the TRIM implementation is in either the OS or the SSD. And because TRIM is a serialized command and cannot be run concurrently with read or write IOs. There are a lot of moving parts when it comes to using TRIM properly. Systems are probably better off not using TRIM at all, frankly.

    In case people haven't figured it out, this is one reason why Intel chose multiples of 40G for their low-end SSDs. Their 40G SSD competes against 32G SSDs from other vendors. Their 80G SSD competes against 64G SSDs from other vendors. You can choose nominal performance by utilizing 100% of the advertised space or you can choose to improve upon the already excellent Intel wear leveling algorithms simply by partitioning it for (e.g.) 32G instead of 40G.

    We're already seeing well over 200TB in endurance from Intel's 40G drives partitioned for 32G. Intel lists the endurance for their 40G drives at 35TB. I'm afraid I don't have comparitive numbers for when all 40G is used but I am already very impressed when 32G is partitioned for use out of the 40G available.

    Unfortunately it is nearly impossible to stress test a SSD and get results that are even remotely related to the real world, since saturated write bandwidth eventually causes erase stalls when the firmware can no longer catch up. In real-world operation write bandwidth is not pegged 100% of the time and the drive can pre-erase space. Testing this stuff takes months and months.

    Also, please nobody try to compare USB sticks against real (SATA) SSDs. SSDs have real wear leveling algorithms and enough ram cache to do fairly efficient write combining. USB sticks have minimal wear leveling and basically no ram cache to deal with write combining.

    -Matt

  22. 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.

  23. Re:how can you _boot_ into windows on hpfs+? by jabbathewocket · · Score: 3, Informative

    The point is that while it would allow them to isolate whether the *drive* itself in the macbook air is somehow immune to the issue, or if its something to do with the operating system/file system preventing the issue to occur.

    IE if You do the tests in OS X, rezero the drive install windows xp/vista run them again (in NTFS on the mac's ssd), then finally install windows 7 also to a clean drive under NTFS and run the tests a final time (this last test would have trim enabled of course)

    Chances are that what is happening is that the OS X has an artificial limit in speed (for whatever reason) masking the problem.. If that theory is correct then installing windows 7 to a freshly zero'd drive on the air, should result in significantly faster initial performance than measured under OS X, with a dropoff to roughly the levels measured under OS X over time.