• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

NTFS compression on SSD

A

Acer_Sheep

[H]ard|Gawd
Joined
May 18, 2007
Messages
1,201
Is this good idea? I have 60 gig SSD, which is still ok but I'm thinking about compression as it saves up some space, but what about CPU load, spare SSD's operating cycles and its lifespan? I can't decide if to do it or not, what you guys would recommend?
 
Saved me 15GB on my 60GB SSD. CPU not a bottleneck. Would highly recommend it.
 
with multi-core multi gigahertz CPUs being the norm compression is basically free and a no bainer.

example

Properties for the shogun 2 total war directory on my laptop here

Size: 32.2GB
Size on disk: 24.1GB

almost 10GB saved
 
Greetings

Overhead is minimal on even a single processor and compression has been around since windows NT 3.51 and was very stable even back then.

The main advantage with SSD's is that once its compressed the stuff thats written out to disk is smaller and hence will make your SSD last longer due to its limited number of writes (3000? on new 25nm SSD's).

Cheers
 
HobartTas said:
Greetings

Overhead is minimal on even a single processor and compression has been around since windows NT 3.51 and was very stable even back then.

The main advantage with SSD's is that once its compressed the stuff thats written out to disk is smaller and hence will make your SSD last longer due to its limited number of writes (3000? on new 25nm SSD's).

Cheers
Click to expand...

you would have to write about 700tb to a 64gb 25nm m4 drive just to kill it. you can't kill a drive in windows unless you intentionally do it for every minute months straight.
 
just did it, and before I had 12 gigs of free space and now I have 9.5 after compression, how is it possible?
 
The main advantage with SSD's is that once its compressed the stuff thats written out to disk is smaller and hence will make your SSD last longer due to its limited number of writes (3000? on new 25nm SSD's).
Click to expand...

Doesn't the OP have a sandforce based ssd? I would expect compressing those will only do the opposite. Since these drives rely on internal ssd compression to reduce the nand usage and to improve write speed. You can not compress already compressed data so you are in effect removing the advantages of the internal ssd compression.
 
Last edited:
drescherjm said:
Doesn't the OP have a sandforce based ssd? I would expect compressing those will only do the opposite. Since these drives rely on internal ssd compression to reduce the nand usage and to improve write speed. You can not compress already compressed data so you are in effect removing the advantages of the internal ssd compression.
Click to expand...

It shouldn't make any difference. Just means the SandForce controller's compressing capabilities go more or less unused. It will still be writing about the same as before.

The advantage is the NTFS file system sees more space available :)
 
Acer_Sheep said:
just did it, and before I had 12 gigs of free space and now I have 9.5 after compression, how is it possible?
Click to expand...

Err not sure. Have you rebooted since? I think during compression my pagefile got huge....

Can you run Treesize Free and post a screenshot of where the most space is used up?
 
I actually wouldn't suggest doing this. At first, yeah, it seems like a great idea. But the problem is NTFS uses 64k chunks (on a 4k file system, which is default). So that means even if one byte in that 64k chunk changes, then you have to do a read-modify-write operation (at the OS level). This is on top of whatever operations the SSD itself is doing.
 
In some cases, the mount of writes incured because of compression are greater than would be seen if they were uncompressed. Either way, running NTFS compression on SF isn't a good idea. SF really has to work hard to deal with random data, and when the whole drive is filled it just creates more overhead IMHO. If you're overprovisioning the drive,it can mitigate some of these effects, but I think the OP is better off ditching compression, hibernation, and most/all of the page file to save space.
 
Just tried it again and I'm not able to boot, I get message like EBKL is compressed, press ctrl+alt+del and that's all, so I guess I wont be enabling this feature, however It lately saved up some 4 gigs of space, but not able to boot and I only recovered the system via my hidden backup installation.
 
Atto gets blinded by the NTFS compression that sends all its calls to memory cache, I actually tried it with a NTFS compressed ramdisk and the result were identical to those of my compressed SDD (intel 330 120gb) note it is plugged on a sata II interface!

Got me the idea to do a copy to the ramdrive. So I took 1.6 gb of files 2300 files (compressed on the SDD at 895 MB). (note Im doing this on my laptop, asus N61jq with 4 gig ram, with the ram drive I dont think windows got any memory left to stores the file I copy in memory..) Also tried with an unique file (1gb compressed to 680)

Im gonna report the speed windows gave at an average near the end of the transfer
compressed SSD -> NTFS RAM ~40 MB/s big file: 130
compressed SSD -> compressed NTFS RAM ~40 MB/s big file: 40

uncompressed SSD -> NTFS RAM ~60 MB/s big file: 300
uncompressed SSD -> compressed NTFS RAM ~60 MB/s big file: 60!

So reading takes a hit with compressed on especially with big files: we shouldnt expect such a big hit for the single file.pure NTFS compression routine takes a lot of time and we hit a 60 MB/s wall. And we can clearly see that NTFS protocol decrompress and recompress when copying from 2 compressed locations.

Now the other way around and look if we have the same effect on writing:
compressed NTFS RAM -> SDD (not compressed) 50-55 MB/s bif file:300-200
compressed NTFS RAM -> SDD (compressed) 30-32 MB/s didnt do..

NTFS RAM -> SDD (not compressed) 65-60 MB/s big file: 600-300 barely saw number
NTFS RAM -> SDD (compressed) 40 MB/s big file: 50
NTFS RAM -> HDD (USB3) 27MB/s big file: 69
So there is not as big a cost to decompress from memory, but it is still there. The compression is the killer here for big files.. 50 MB/s might as well be writing up on HDD for that big file!

In the end you lose for big file a factor of 6 in speed, if you would be compressing that amount it would be nice, but it shows there is way too much overhead on the compression ..I checked the transfer speed to my HDD (USB3 hub so not the best comparaison but it gave writes of 27 mb/s for the folder and 69 for the big file.)

There is still the read access time that we dont really probe with moving files, these are probably less impaired as it will be only the decompression algo running.

In the end I will keep it mostly uncompressed, unless It feels too tight, since I will have my older HDD replacing the DVD, I should be able to manage everything well.

I would also recommend only for single SSD systems, and not full directories, only the less used or less critical to be fast to load applications. On data storage it would be great (as long as you dont plan to migrate them too often..)

On a side note I put the ramdisk to good use as the default temp folder and cache folder for my web browser (512 mb).
 
msitpro said:
It shouldn't make any difference. Just means the SandForce controller's compressing capabilities go more or less unused. It will still be writing about the same as before.

The advantage is the NTFS file system sees more space available :)
Click to expand...

Well, that's not really an advantage. SF drives are designed with compression in mind, that will allow great speeds, but also be part of their durability. If you only write incompressible data on the drive, then you shorten its lifespan.
 
Aesma said:
Well, that's not really an advantage. SF drives are designed with compression in mind, that will allow great speeds, but also be part of their durability. If you only write incompressible data on the drive, then you shorten its lifespan.
Click to expand...

you're not going to kill a sf drive with ntfs compression... they can take something like 600tb of data written on the small drives before you start having problems.
 
Driffster said:
compressed SSD -> NTFS RAM ~40 MB/s big file: 130
compressed SSD -> compressed NTFS RAM ~40 MB/s big file: 40
uncompressed SSD -> NTFS RAM ~60 MB/s big file: 300
uncompressed SSD -> compressed NTFS RAM ~60 MB/s big file: 60!
compressed NTFS RAM -> SDD (not compressed) 50-55 MB/s bif file:300-200
compressed NTFS RAM -> SDD (compressed) 30-32 MB/s didnt do..
NTFS RAM -> SDD (not compressed) 65-60 MB/s big file: 600-300 barely saw number
NTFS RAM -> SDD (compressed) 40 MB/s big file: 50
NTFS RAM -> HDD (USB3) 27MB/s big file: 69
Click to expand...

Interesting data, just curious, how does OS calculate the transfer rate with compression involved?
1. amount of compressed transferred from source/ Time: If the size is measured at compressed size, then there's less data to transfer.
2. amount of transferred and compressed received at destination /Time: If the destination is measured at compressed size, larger amount of data was actually transferred, but measured at compressed.
 
You must log in or register to reply here.
Back
Top