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."
Geniuses often don't play well with others.
It conflates the results of several independent tests to form the view that XP is somehow best. It also bandies about meaningless numbers like one OS being x% faster than another without giving any hint of the metric.
Avoid.
Nick
Filesystems are fundamentally engineered to cope with the high latency of hard drives, so I'd imagine there are a lot of assumptions to unlearn. But what other implications are there for the OS? Since the tradeoffs between RAM and persistent storage are smaller with SSD, maybe the changes should go beyond the filesystem into the virutal memory system?
What is your criteria for a different file system? NTFS is already a very good one for most of the important criteria.
from TFA: "Linux is "always faster" than Vista or Mac OS X"
FTA:
"Linux is "always faster" than Vista or Mac OS X -- to the tune of 1% to 2% -- because like Windows 2000, "it never runs anything in the background."
I'm sorry , what? Have these people never heard of daemon processes? What the hell are they talking about?
If this is their level of expertise I think I'd take any tests they do with a whole cellar full of salt.
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.
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.
According to Far, Mac OS X runs "a little faster than Vista" with an SSD drive, but Linux is "always faster" than Vista or Mac OS X -- to the tune of 1% to 2% -- because like Windows 2000, "it never runs anything in the background."
Ok, so Linux and Windows 2000 never run anything in the background. My head exploded so I stopped reading.
The article is all over the map, discussing in vague terms everything from boot-up speed to I/O speed to some sort of generic "runs a little faster" that I assume (?) means overall system or app benchmark performance.
When actual numbers are quoted, they sound somewhere between questionable and boring. The article quotes all sorts of differences in the range of 1% and 2%. Leaving aside the question of what this is a 2% difference in, and whether a difference that small is even consistently measurable outside of sampling error and quirks of their particular setup, does it actually matter? I'm certainly not going to choose an OS based on a 2% difference in SSD performance.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
for when you need to partition your wife
Actually recent benchmarks have shown that defragging doesn't make *that* much of a difference - http://www.maximumpc.com/article/the_disk_defrag_difference?page=0%2C2 I've never heard of a fragmented drive affecting machine stability. That's like saying having a 5400 RPM drive instead of a 10,000 RPM drive in a server will make it crash... It makes no sense. Fragmentation has nothing to do with data integrity which is the only thing that would affect stability.
Also, it's "its" not "it's".
You are using English. Please learn the difference between loose and lose; they're, there, and their; your and you're.
Even if their methodology was clear.
Even if their methodology was valid.
Even if every percentage point was accurate.
Even if all of their arguments were valid.
(And none of these are true.)
Why would I care enough about 5% to let that pick my OS?
It's not only 'bad' it's weirdly bad.
According to Far, Mac OS X runs "a little faster than Vista" with an SSD drive, but Linux is "always faster" than Vista or Mac OS X -- to the tune of 1% to 2% -- because like Windows 2000, "it never runs anything in the background."
Never runs anything in the background? What in the world does that mean? Am I missing something, here, or is this just the wrong terminology to use? Even at the most basic use level, you can "background" an application in Linux with the ampersand ... I'm confused.
Not to mention that they didn't test Linux... or, presumably, any Unix OS. They basically only tested Apple and Microsoft operating systems. Hm. I actually like Windows on occasion, and I find that pretty stupid. (I also like Linux :) )
It did have some interesting things to say though, like the block alignment.
TFA: "Microsoft also plans a certification program for SSDs so that the drives properly identify themselves to Windows 7 and prioritize data I/O for the SATA interface. "
While MS is known for embrace-extend-engulf, this is nothing to panic over. If the drive passes a string that identifies it as an SSD, Win7 (or any other OS) will use different disk control logic than they will for an HDD. All OSes will benefit if there's a clear way of identifying SSDs; MS, Linux, Apple, Sun, IBM, all of 'em. Change the preferred block size, alter garbage management, adjust caching to deal with 1 ms response times, (typically) fast reads,(typically) slow writes, etc.
I've been on slashdot so long I'm starting to get out of touch with the cool stuff if it ain't on slashdot.
Obviously, SSD's are in their infancy. NO OS has been even remotely optimized for them yet, I'm sure (except maybe the big hitters, like Solaris). I'd be willing to be my left leg that the next version of every commercial OS (OSX, Windows, Linux*) is optimized for them. This article is irrelevant.
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.
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!
Stop posting on Slashdot and go back to jail, Hans.
the source of windows 2000 was leaked a few years ago. http://www.kuro5hin.org/story/2004/2/15/71552/7795
Overall, I would state that this article is useless beyond "cocktail gossip." And really, SSD should have a specific FS written to its peculiarities, which would, of course, render the "OS" questions moot.
Ruby Neural Evolution of Augmenting Topologies
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!
LOL.
I had in past run a Windows server for about 2 years. And it was terribly slow, despite the fact that in the beginning it was blazingly fast. I believe it was O&O Defrag which actually returned the server to life: downtime on Sunday with boot time defragmentation did the miracle.
Same thing in the company I work for right now: IT recently took off net two file servers and exchange server to defragment file systems, because FS performance went considerably down. Folks have said that they "lose to fragmentation 30% of FS performance," meaning that system works about twice faster after defragmentation. That's why they schedule at least one down time for every windows server in company.
Whatever synthetic benchmarks people perform - it is irrelevant.
Long term real life experience tells otherwise.
All hope abandon ye who enter here.
depends on your definition of crash. Having a slower HD will cause disk IO to stack under heavy load. What is the real difference between a server that has crashed, and one that doesn't respond? Fragmented disks will have the possibility of a similar effect. The linked article measures the difference between a disk that is 7.5% fragmented and after its been defragged. 7.5% isn't much. It really depends upon which files have been fragmented. If they are rarely accessed data files, then obviously there isn't going to be much of a performance difference. If they are frequently accessed, then the difference would be huge. I've seen desktops that topped out at 30% fragmentation. The performance after dragging is night and day. Its much more important for me to have consistent performance ( due to automatic reallocation of files when they would be fragmented) than a gradual slowdown that requires downtime for defragmentation.
Note, haven't run windows in production servers for the past ten years. But I don't think NTFS has changed that much since then.
Well.. maybe. Or Maybe not. But Definitely not sort of.
That's because Mac users are non technical and open their files by name rather than cluster number. If you do that then defragmenting doesn't break anything.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
i alwasy got a kick out of the NT4 documentation for how to defragment a partition.. the "best pratice" was to back the data up to tape then format the partition and restore from the tape..
alwasy gave me a good laugh..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Actually thru extremely slow hard disk drives you are able to discover a lot of race-conditions that would otherwise go unnoticed.
nope you're a coward :P
I can't call that English
Linux will have good support SSD support, you can be sure of it as Linus uses it himself, he mentions it in his blog. (he is using an intel SSD drive) http://torvalds-family.blogspot.com/2008/10/so-i-got-one-of-new-intel-ssds.html
>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.
Linux is not a "very major OS" [...] that has less than a few percent of the desktop market
Who said anything about the desktop market? There are plenty of subnotebooks, handhelds, and embedded devices that boot from flash into a Linux-based environment. I would imagine that even servers could benefit from the faster seeks and lower heat dissipation of SSDs for some workloads.
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.
Oh, come on now! *throws chair* Stop ruining my minions^H^H^H^H^H^H^Hteam's astroturfing with your 'facts' and 'logic'! *throws another chair* I'm gonna fscking KILL that Anonymous Coward guy!!
-- Steve B.
My blog
I think you mean "head", not "needle", unless we're talking about 33 RPM vinyl discs here.
Gamingmuseum.com: Give your 3D accelerator a rest.
I run a RAIV-5 array, you insensitive clod!
Sam ty sig.
ext3 and a lot of modern filesystems do not need defraging.
http://www.heise-online.co.uk/open/Tuning-the-Linux-file-system-Ext3--/features/110398/3 This article explains how an Ext3 filesystem can be less fragmented than say NTFS but still need defraging under extreme conditions.
The point of the article is that solid state drives have different performance characteristics than hard disks. Since SSDs are random-access devices, fragmentation does not increase seek time. Therefore, it makes sense that a filesystem that doesn't try to worry about fragmentation could perform better on SSDs.
You must have missed the change. It was a major feature for the Linux 2.6 kernel series. All linux processes now run in the foreground. Running a process in the foreground saves on overhead, thus resulting in a significant improvement in speed. Easily more than the 1-2% that the article mentions. I suspect the article downplayed the speed advantage, to cast Windows in a better light.
Linux achieves this ability by forking the process from the shell, and redirecting the inputs and outputs away, thus giving the illusion of a backgrounded process. The beauty of this is that it's all completely transparent to the end user. The system behaves just as before, apart from the speed increase.
Everyone knows that processes in the foreground run faster. Myself, I used to background a process only out of absolute necessity. These days though, a background process is actually a foreground process, so I don't worry at all about running multiple jobs at the one shell now. Linux is truly a state of the art operating system!