Slashdot Mirror


Which OS Performs Best With SSDs?

Lucas123 writes "Linux, Vista and Mac OS perform differently with solid state disks. While all of them work well with SSDs, as they write data more efficiently or run fewer applications in the background than XP, surprisingly Windows 2000 appears to be the winner when it comes to performance. However, no OS has yet been optimized to work with SSDs. This lost opportunity is one Microsoft plans to address with Windows 7; Apple, too, is likely to upgrade its platform soon for better SSD performance."

10 of 255 comments (clear)

  1. Summary FAIL by Wonko+the+Sane · · Score: 3, Interesting

    "If you really want to go inside [the OS numbers], Windows 98 was the fastest of all," Far said.

  2. Stupid article... by Cyberax · · Score: 4, Interesting

    Have they tuned Linux for SSD? Like setting no-op IO scheduler (which gives about 20% speedup on some workloads)?

    I suspect that Win2000 and Win98 win because they have the most simple (and stupid) IO schedulers. That's a problem for conventional HDDs, but it's an advantage for SSDs.

    Also, they are talking about "Win98 doesn't support wear-levelling technology". But that's incredibly stupid since modern 'disk-like' SSDs do wear-leveling in hardware.

  3. No optimized OS = false by The+Man · · Score: 5, Interesting

    Since they didn't test Solaris, the test is meaningless. It's the only OS in existence right now with caching and data management features designed specifically to take advantage of flash to improve real-world performance. The submitter's assertion to the contrary is a deliberate lie, an assumption that until Microsoft does something it hasn't been done, or at best sheer ignorance.

    Read up on the ZFS L2ARC and the use of supercap/DRAM/flash subsystems for separate intent logs that make up the hybrid storage pool. There are plenty of white papers and other material out there, and of course you can also read the source code.

  4. Just did this, DMX4, Suse 10, Oracle 10g. by Bardwick · · Score: 2, Interesting

    Wasn't a massive test. Used Swingbench against 170g database. Quad core, 2gig. Disks were 300g 15k fiber, dual pathed. Swingbench seemed to be like 50 users running VERY poor queries, so this was almost 98% reads. Ms response time was between 3-4, cache hits minimal. Added EMC (1) 146g SSD into the disk group. Response time hit .4 to 1 ms response, identical tests.

  5. Re:Do we just need a new filesystem? by MattBD · · Score: 2, Interesting

    Isn't LogFS designed specifically for flash memory? At present most flash drives seem to come with FAT, purely because anything can read that, but that's sure as hell not designed for flash. Seeing as portable music players seem to be heading towards using flash memory, they could do with something like that.

  6. Re:Nevers run anything in the background? You what by Actually,+I+do+RTFA · · Score: 5, Interesting

    For example, XP will defrag your disk without you asking it to as soon as you're marginally idle

    XP will not. OS X will. In fact, OS X will defrag your thumb drive without your permission. It was bad enough that it was wearing my disk for no benefit, but it also made my thumb drive remarkably non-resiliant to power outages.

    --
    Your ad here. Ask me how!
  7. Re:Windows 2000 is fastest of Windows and Mac OSX by ADRA · · Score: 2, Interesting

    Fragmentation causes more needle shifts than regular burst read/writes. If a hard-drive is most likely to die from needle shifts, fragmentation could wear on the drive more than a nice and tidy system.

    Of course this is all speculation and moving the needle could have absolutely nothing to do with death rates, who knows.

    --
    Bye!
  8. Re:Windows 2000 is fastest of Windows and Mac OSX by Bwian_of_Nazareth · · Score: 2, Interesting

    Actually thru extremely slow hard disk drives you are able to discover a lot of race-conditions that would otherwise go unnoticed.

  9. Linus on SSD Vendors and Filesystems by zealot · · Score: 5, Interesting

    >I'm suspicious of the suggestion that a log-based
    >filesystem will cure all the ills of the limited flash-
    >controller based wear leveling.

    Yeah. Total bull.

    Anybody who thinks the filesystem can do really well has
    bought into the crud from most existing vendors about how
    you have to use those things differently. If you really
    do believe that, you shouldn't touch an SSD with a ten-foot
    pole.

    If the flash vendor talks about "limits" in the wear
    levelling, and how you have to write certain ways, just
    start running away. Don't walk. Run away as fast as you
    can.

    >A question keeps coming up in my mind about what happens
    >when you split an SSD into multiple partitions, and what
    >*you want to happen*. I use separate partitions for root,
    >boot, and var, because I tend to make root and boot
    >read-only.

    Again, if your SSD vendor says "align to 64kB boundaries"
    or anything like that, you really should tell them to go
    away, and you should do what Val said - just get a real
    disk instead. Let them peddle their crap to people who are
    stupider than you, but don't buy their SSD.

    So what you want to happen if you split an SSD into multiple
    partitions is exactly nothing. It shouldn't matter
    one whit. If it does, the SSD is not worth buying. If it is
    so sensitive to access patterns that you can't reasonably
    write your data where you want to, just say "No, thank you".

    Anyway, I have a good SSD now, so I can actually
    give some data:
    - Most flash-based SSD's currently suck.

    I don't have these ones myself, but last week we had the
    yearly kernel summit here in Portland, and a flash
    company that shall remain nameless (but is one of the
    absolute biggest and most recognizable names in flash)
    was selling their snake-oil about how you need to write
    in certain patterns.

    So I called them on it, and called them idiots. Probably
    one reason why I didn't get one of the drives they were
    handing out, but one of the people who did get a drive
    was the Linux block system maintainer. So he ran some
    benchmarks.

    Those things suck. You will never get any decent
    performance of anything but a very specialized filesystem
    out of them, unless you use them as essentially read-only
    devices.

    For a basic 4kB blocksize random write test, the SSD got
    around 10 IOps. That's ten, as in "How many fingers do
    you have?" or as in "That's really pathetic". It means
    that you cannot actually use it as a disk at all, and
    you need some special filesystem to make it worthwhile,
    and certainly means that wear levelling is probably not
    working right.

    (For the math-challenged, 10 IOps at a 4kB blocksize
    means 40kB/s throughput and 100ms+ latencies for those
    things. It also means that even if some operations are
    fast, you can never trust the drive)

    - In contrast, the Intel SSD's are performing exactly as
    advertised.

    I did get one of these, with warnings about how
    if I want to get low-power operation etc I need to make
    sure that disk-initiated power management is enabled etc.

    Whatever. The important thing is that the Intel SSD does
    not care one whit where you write stuff, or how you do
    it. With the same 4kB random write b

    --
    He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
  10. ext4 and btrfs will support SSD better by calc · · Score: 2, Interesting

    I am at the Ubuntu Developer Summit at Google and listened to a talk given by tytso a few days ago. He mentioned that both ext4 and btrfs will support a new ATA command to tell the drive that a particular sector in no longer in use so that it can reuse it for better wear leveling. So it appears Linux will have better support for SSDs in the near future.