To view parent comment, click here.
To read all comments associated with this story, please click here.
A SSD is many times faster than a HDD for my work (programming). My 5 year old ThinkPad T61p (Core 2 Duo, 8GB) with a slow 128 GB, SATA I SSD absolutely stomps my employer-provided ThinkPad W520 (Quad Core i7, 16GB) that has a 7200 rpm HDD in tasks I care about, like compilation. Generally my compile jobs and large application launches (enterprise DBMS) are 4x faster. And this is with a nearly 5 year old SATA I SSD drive (a whopping 128 GB at that).
Another interesting note is that I also have a Samsung 830 512 GB in a newer system and the performance, while better than the super-old SSD, is less than 2x better. The return on investment for high vs low performance SSDs is minimal. OTOH, making sure you buy a reliable drive is money well spent.
This is honestly such a deep, complex subject that everyone could argue the living hell out of it and no one would ever agree on a conclusion.
There are just too many factors involved, and whether you want to hear it or not, the OS involved does make a difference.
I did a quick fsck on my / and /home partitions for the hell of it earlier just to get fragmentation data, and quite honestly, I am amazed at what I saw; it completely backed up what I said, 100%. It was shocking, considering the cringe-worthy state of my system's partitioning. It's in desperate need of re-partitioning, and technically I'm doing a lot of things extremely inefficiently and just downright WRONG, yet far fewer fragments were reported than PerfectDisk would typically report in much better circumstances. And the biggest culprits? Exactly what I expected according to filefrag: three VirtualBox disk images.
And BTW, the reason I focused on data fragmentation is because in my experience it tends to have a far more devastating effect than a bunch of little files scattered all over a drive. That is, assuming you're running an OS and file system combination that is prone to fragmentation in the first place... luckily, in that case there are some excellent tools to keep the fragments under control.
Not to mention, with the general explosion of the data densities of hard drives that has been going on over the years, even if the rotational speeds do not increase a newer drive will still probably read the same amount of data as an older drive, even faster.
The bottom line is that hard drives are wicked fast these days. And with partitioning, it's easily possible to separate your boot files (/boot), main system (/), programs (/usr), and personal files (/home) and keep them all together to minimize seeking between files... but honestly, in my experience you don't even have to go that far, because I've found (for example) Windows XP running practically exactly the same on a 15GB partition at the beginning of the disk as it did on a 60GB partition spanning the entire drive. The only condition? That the number of file fragments are kept to a minimum.
I will just say that I still stand by what I said and will leave it at that.
Edited 2012-09-28 12:51 UTC
What is there to argue about? Less time spent waiting == more time doing something else.
A seek is a seek, it doesn't matter how you believe you've grouped the files together. What matters is their physical location on the platters: the closer to the outermost edge of the platter the faster the transfer speeds and lower the seek times.
This here quite well demonstrates how little you understand about the topic; the size of the partition is irrelevant, the location of the files is not. You get EXACTLY the same speed with a 200TB partition as you get with a 200MB partition if the files themselves haven't moved.
Go ahead. Come back when you decide you don't wish to be wrong any longer.




Member since:
2006-02-15
Don't try to turn this into an anti-Windows argument. You know perfectly well that both Windows and any average Linux-distro consists of thousands of small files. It doesn't matter whether those files are fragmented or not, they're still not laid out on the disk in such an order that the drive can read every single one of them in sequential order and that is exactly why low seek times matter.
Also, as I said these days SSDs trump HDDs even in sequential speeds. Check out e.g. http://thessdreview.com/our-reviews/adata-xpg-sx300-256gb-msata-ssd... : the SSD can write ~200MB/s incompressible data in sequential order, something that no consumer-oriented HDD can do.
Reading both https://en.wikipedia.org/wiki/Solid-state_drive#Comparison_of_SSD_wi... and http://thessdreview.com/ would do you a lot of good.