Does NTFS compression slow SSD/flash performance?

[ShawnD1]

A while back I posted that I was using NTFS junctions to offload some program files to a high speed flash drive. I ran into a road block when there a slight shortage of space, so I decided to NTFS compress the drive. Here's how bad the fragmentation is: picture

What's interesting is that it doesn't seem to slow anything down. Even with NTFS compression and brutal fragmentation, it can still load Excel, Word, Powerpoint, and Photoshop in a very short time. Up until now, the biggest problem with NTFS compression was not the fact that it requires CPU power, but the fragmentation forces the drive to look all over the place just to find everything. Flash/SSD is not so heavily affected by fragmentation, so the only real concern is the CPU demand.

Can someone else check this for me? If you have an SSD, all you need to do is NTFS compress your Program Files directory and see if performance noticeably decreases.

 

[alcoholbob]

The random read speeds are fast enough on flash media that fragmentation should have little effect on application loads.

 

[Idontcare]

Originally posted by: Astrallite
The random read speeds are fast enough on flash media that fragmentation should have little effect on application loads.

Should have no effect, shouldn't it?

 

[taltamir]

READ speeds in SSD are not affected by fragmentation, at all...
Write speeds are greatly hindered by fragmentation, but not the one YOU see... you see, in order to do wear leveling every "sector" on the file system is mapped to a different and MOVING physical spot. So sector 1 on the NTFS file table might point out at physical sector 10, when you change it, it will be rerouted to the least written to sector, sector 70, then when you change the data on the NTFS sector 1 again, it will again go to the next "least written to sector" which happens to be sector 1004. And so on. This completely solves the issue of SSDs "running out of writes", but when it is combined with the fact the drive can write 1x4kb sector but only delete a row of 128x4kb sectors at once, means that fragmentation of the underlying table that the controller has that is COMPLETELY INACCESSIBLE AND INVISIBLE TO THE USER AND THE OS causes great slowdowns; this phenomenon is called "Steady state"...
this is why aligning the partition of an SSD increases performance
and this is also what the trim command will fix.

 

[soccerballtux]

Vista, 7 both have very aggressive prefetching. Only my rarely used applications (IE not Word, Excel) don't open instantaneously, and I'm on a harddrive.

 

[Nothinman]

Fragmentation has a much smaller affect on performance than people think, even on regular hard disks. So it's not surprising that it has virtually no affect on an SSD.

 

[taltamir]

Originally posted by: Nothinman
Fragmentation has a much smaller affect on performance than people think, even on regular hard disks. So it's not surprising that it has virtually no affect on an SSD.

heh, so true, there really isn't any point to defragging. its like spending dollars to save cents later.

 

[coolVariable]

Originally posted by: soccerballtux
Vista, 7 both have very aggressive prefetching. Only my rarely used applications (IE not Word, Excel) don't open instantaneously, and I'm on a harddrive.

Very, very true. Negates 90% of the benefits of an SSD.

I would think compression helps with SSD writes though, as the data needs to be compressed by the CPU ... I could see that this might turn some random writes into more sequential writes. The impact will be minimal though.

 

[Engineer]

Very, very true. Negates 90% of the benefits of an SSD.

I would think compression helps with SSD writes though, as the data needs to be compressed by the CPU ... I could see that this might turn some random writes into more sequential writes. The impact will be minimal though.

Anyone else have comments or experience with this? It seems that it would reduce writes to the drive but does it slow the system down? If you've tried it, what are your impressions? Also, I would assume that a multi core fast processor would be best to compress on the fly for this, no?

 

[Emulex]

you need the compression to be in the drive to manage wear leveling properly.

 

[Engineer]

you need the compression to be in the drive to manage wear leveling properly.

Why would that matter? The drive will keep track of the cells written to and balance the writing of them out through wear leveling. Doesn't matter if the data written is compressed or not....data to the drive is just that...data...compressed or not.

Now back to the question: Does compression effect the speed of the system in a negative way?

 

[Beautiful_Life]

I've an SSD and I'll probably try this out soon.

Theoretically, NTFS compression or compression of any kind will greatly boost read and write speed. Compression is done on the OS/program level and uses the processor to reduce the size of a bunch of file and at the same time convert it into a nice stream of data. The components used here are the processor and the RAM. After compression, this means that less has to be written onto the SSD, which is good. NTFS compression doesn't seem to be very taxing on the processor either.

How about reads? The OS will read less from the HDD, then it will have to expand the data and then sift out the unnecessary information(since during compression, different files get combined together), then combine all the necessary information together just as it should have been and as requested by the program. So by right by a contemporary processor, this shouldn't cause any slowdown., instead it should be a speedup.

Real world test. OCZ Vertex 2 uses this concept. it has a compression chip or something that compresses and expands the data being written. On benchmarks, it's reads are still slower than Intel's Gen2 however it's sequential writes go up to 260MB/s which is about 80% faster than Intel's. It's kinda dumb anyway because no one will ever be able to utilize the extra fast write speed, they will need to be transferring from a RAID 0 SSD config because SATA to SATA transfer is still quite slow. Any meaningful processing of such a large amount of data can't be handled by even the fastest consumer processors anyway.

So the question is why is the read speed still slower than Intel's SSD without compression? That's the only thing keeping me from applying NTFS compression on my whole disk now.

Also benchmarks asides, compression can only do so much. music and movie files can hardly be compressed any further. It would tax the processor for nothing. File which have already been compressed(zip rar etc) can't be compressed any further too.

 

[sub.mesa]

Compression increases latency; noticeable only with latency-sensitive applications

 

[Seero]

Edit: was not realized that this is a zombie threat.

 

[jimhsu]

Here was my empirical data generated by IOmeter. Take it with a grain of salt.

Note the axis on the left is MB/s, on a log scale. Caching is enabled.

http://forums.anandtech.com/showpost.php?p=30779028&postcount=11

From what I can gather, compressing your Program Files directory might not be a bad idea, and may actually increase performance. Compressing your Windows directory, or AppData, on the other hand...

 

[amanieux]

i wanted to get more space and eventually some speed on my ssd so i tried compression at windows level, here are my results : with ntfs compression on, it saved 18% size on my ssd (8gb freed on a 48gb uncompressed used disk space).about speed with my compressed ssd : crystal diskmark performances remained the same except a 10% slowdown in 512k random write (which is acceptable for me as everything else remained at the same speed, especially the more significant 4k reads and writes).

by the way about performances loss in ssd i notice a much stronger average 20% performance slowdown in read and up to 45% slowdown in 4k random reads (write speed is unchanged) on my ssd if i change my power settings from "maximum performance" to "balanced" or to "maximum power saviing".

my hardware :macbook white under bootcamp ( core2duo@2ghz/crucial m225 128gb/win7 x64 )

 

[Mark R]

One thing that I did run into with some memory sticks, was that if you use NTFS compression in situ, then it can cause monster fragmentation. In essence, especially if the volume is near full (which is probably why you are using compression in the first place), NTFS tends to use the same blocks on the disk, but then just omit a sector (or cluster).

As NTFS defaults to 512 byte clusters, this can lead to massive malalignment, and lots of interstitial single free clusters.

If you then end up copying new data to the drive, it can be horrendously slow, due to the individual sector writes. On an SSD (where the native sector size is 4k, or increasingly 8k), this can be catastrophic for performance (and wear levelling).

I noticed most severley on a USB stick - this was a fast stick (30 MB read, 20 MB write). However, after filling it up, and enabling NTFS compression, filling the last 250 MB was impossible. Write speed was under 2 kB/s. I actually thought the stick was dead, until I cleared out a bunch of uncompressed files, and then the speed suddenly returned.