Windows 7 Hard Drive and SSD Performance Analyzed

bigwophh writes "Despite the fact that Windows 7 is based on many of the same core elements as Vista, Microsoft claims it is a different sort of animal and that it should be looked at in a fresh, new light, especially in terms of performance. With that in mind, this article looks at how various types of disks perform under Windows 7, both the traditional platter-based variety and newer solid state disks. Disk performance between Vista and Win7 is compared using a hard drive and an SSD. SSD performance with and without TRIM enabled is tested. Application performance is also tested on a variety of drives. Looking at the performance data, it seems MS has succeeded in improving Windows 7 disk performance, particularly with regard to solid state drives."

Comments

Linux already has this

[Saba]

Linux already supports SSD's and other flash media by having a noop scheduler. The basic premise is that devices that don't depend on mechanical movement to access data don't need reordering of requests. This is also the scheduler you use if you have an advanced controller (RAID, etc) that is capable of doing it's own I/O rescheduling.

To see what scheduler you are running (on this case /dev/sda):

# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

Here the completely fair scheduler is currently running. To swap to the noop scheduler:

# echo noop > /sys/block/sda/queue/scheduler
[noop] anticipatory deadline cfq

Re:Linux already has this

[BikeHelmet]

I found that CFQ gave best results on my Ubuntu box. When moving files around, it was usually about 20% faster than deadline, and 100% faster than anticipatory. I can't remember if I tested noop.

Re:Linux already has this

[TheLink]

noop scheduler != support for SSDs.

Sequential writes in common Flash SSDs are faster than random writes. Sequential reads are also usually faster than random reads.

See: http://www.anandtech.com/printarticle.aspx?i=3531

For RAM + battery based SSDs, while there's still a difference the difference should be unnoticeable for drive workloads.

Re:Linux already has this

[ihavnoid]

noop scheduler isn't SSD support. Seems like you didn't RTFA, which means that you didn't understand what TRIM is.

From the article, page 4:

"If the drive broadcasts itself as a solid state drive (which can be done through the latest ATA specification), Windows 7 can make adjustments to ensure that the drive performs at its best. For example, if Windows 7 can verify that you're running a solid state disk, it will disable defragmentation for that drive (as defragging puts un-necessary wear on SSD's and doesn't help performance). Windows 7 will also enable support for "TRIM", also known as DisableDeleteNotify, an add-on to the ATA specification which allows for enhanced performance and decreased strain on the drive. According to Microsoft, here's what TRIM brings to the table.

        * Enhancing device wear leveling by eliminating merge operation for all deleted data blocks
        * Making early garbage collection possible for fast write
        * Keeping deviceâ(TM)s unused storage area as much as possible; more room for device wear leveling.

Basically, Windows 7 will send TRIM commands down the storage chain, but it's up to the drive to accept the commands and utilize them. In order for TRIM to work, you not only need Windows 7, but you'll need a solid state hard disk which has support for TRIM via its Firmware."

Re:Linux already has this

[marm]

On my eee 1000 (with its slow pair of SSDs) I found that while CFQ gave the best average throughput, the noop IO scheduler gave me the best disk latencies and the best interactive performance, which IMHO is much more important on a netbook than raw throughput. I think the issue is that the netbook SSDs have such slow write speeds (and no write cache on the SSD) that any long sequential write freezes all other IO for obviously noticeable periods of time. All of the 'intelligent' IO schedulers in Linux reorder IO requests so that writes happen in one long sequential block if possible to avoid seeking, which is the right strategy for traditional Winchester disks and probably even SSDs with a decent amount of write cache, but wrong for simple, slow SSDs. CFQ isn't too bad as it tries to be fair to different processes asking for simultaneous IO so there aren't too many very long writes, but the anticipatory and deadline schedulers are really painful on my eee.

Control test?

[viyh]

They should have also included a benchmark test against Windows XP so that we could see how much it's decreased/increased since then. A majority of people haven't upgraded to Vista yet so it would have been useful to give an idea to those users. And perhaps, benchmarking other OSs to see how they all stand.

Re:So?

[R4nneko]

Well, I admit this isn't the newest test, but Win 7 was already beating XP in build 7000, heck it is worth noting that Vista vs XP comparison is not particularly bad either.

TRIM is not a final spec

[AllynM]

The TRIM spec is not yet final, and most SSD's will not support it until it is. It's also a safe bet that the WIndows 7 RC does not yet issue TRIM commands (for the very same reason). My testing suggests TRIM is *not* yet at play in the 7100 build of 7. The *slight* gain in write performance seen in the linked review is likely due to the fact that they used two different firmwares for the supposed TRIM enabled / disabled testing. TRIM on a Vertex would give you more than the gain they saw.

Allyn Malventano
Storage Editor, PC Perspective

Re:TRIM is not a final spec

[Anonymous Coward]

More importantly, TRIM does nothing for fully encrypted disks, because unused blocks must be treated like in-use blocks or you'll reveal information about the disk's content. You do encrypt all your data, don't you?

Re:TRIM is not a final spec

[mooglez]

According to one of the Win7 developers blog post, the TRIM is already being used in the Windows 7 RC release.

It's just a matter of getting firmwares that support said TRIM command out in to the existing SSD's now.

Yes, Trim is already in the Win7 RC.

Trim is enabled by default but can be turned off. You can use the "fsutil behavior query|set DisableDeleteNotify" command to query or set Trim.

from the comments section of this:
http://blogs.msdn.com/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

Re:TRIM is not a final spec

[Anonymous Coward]

TRIM would clearly reveal a hidden volume. It would also likely identify the type of filesystem used, because different filesystems use different characteristic space allocation algorithms. There's also a potential for finding the size of files if TRIM is used on a moderately used encrypted disk.

Re:Failure to compare with XP

[Tanman]

Well, maybe they did. However, if the article's opening paragraph was:

Windows 7 accessed data noticeably faster than Windows Vista, although still not as fast as XP. However . . .

Most of us would never get past that first line there.

Re:But...

[David Gerard]

Because the entire article is basically a press release for Windows 7. They compare it to something they know sucks, because they know it wouldn't look nearly as good compared to the thing (XP) people are actually running now.

Re:So?

[Colonel Korn]

Build 7000 (beta) was notably faster and slimmer than Build 7100 (RC) when we tried it here - 7000 was highly responsive and usable in 512MB, 7100 thrashes and is slow in 1GB. We were horrified. So forget 7000's admirable speed - it appears the RC was compiled with -fsuck-like-a-dyson-on-steroids enabled.

I just switched from 7000 to 7100 on a 1 gb netbook and saw no change in responsiveness. Both are much more responsive than XP, which liked to stall for ~3s at a time every time I ran something uncached on the Dell Mini 9's SSD. 7 hasn't done it once. You do know that in the first few hours of use it thrashes intentionally to build the index and populate superfetch, right?

Re:Moving off-topic a little

[Anonymous Coward]

No, Vista changed this so all files that are successful will complete, then at the end any files that failed or need user interaction (like asking to overwrite) come up at the end.
No more hitting 'Copy" on gigs of data and coming back hours later to find a prompt came up 30 seconds in.

Re:But...

[Rycross]

Well, AnandTech benchmarked Windows 7 against XP. It did well, and beat XP in many categories. There you go, no need to thank me.