Freeing Up Capacity On An SSD With NTFS Compression

[Guest]

Thanks but no thanks. This NTFS compression got me a "bootmgr is compressed, press ctrl-alt-del to restart." I had to use hirensboot cd to be able to boot windows 7(it's an option in the menu of hirensboot) and then uncheck the "compress drive".

 

[Guest]

I miss a CPU impact page in the article.

For example, I own an Atom based HTPC with 2 cores running a 1.66ghz. The statement "Users with a modern dual- or quad-core CPU should not notice the additional load incurred by enabling compression. Due to the generally lower performance available from notebooks, the same wouldn’t necessarily hold true on mobile systems" is the key for me. Measuring this impact should be as easy as using the same test procedure and include the host CPU usage while reading/writting. I can also think on using an AMD CPU and an Atom CPD with the used Intel i5.

Only with that step more, the article would have been perfect for me.

Anyway, very good idea for the test.

 

[hmp_goose]

Pardon me for asking so late, but is there any commentary on SSD selection if one aims to use NTFS compression? Should I be looking for a model with better IO scores, or something like that?

 

[cbass64]

Sorry if this is a double post...browser is being weird...

I'm concerned about this article because it doesn't appear to mention some of the issues you may run into if you compress your entire drive running Windows Vista or newer (hopefully, newer). If you compress the windows directory, specifically the winsxs directory, you will run into issues if you attempt to enable features that weren't installed at the time of the OS install. For example, if you try to enable IIS and your winsxs folder is compressed, the install will fail. This won't affect most users, but it sure is frustrating when it does happen.

 

[G-Systems]

[citation][nom]MasterMace[/nom]Those using SSDs and storage hdds should make sure that they set up their virtual memory so that none is being used on the SSD. Instead have the hdd set up for virtual memory.[/citation]The main issue with this line of thinking is that Windows demands a 400MB system dump file on the main OS... So removing all pagefile from the system drive ends up hurting your ability to troubleshoot when things go bad. If you can live with that (and I choose not to), then go on and remove the little .4GB pagefile from your System (SSD) drive...

 

[blazorthon]

The main issue with this line of thinking is that Windows demands a 400MB system dump file on the main OS... So removing all pagefile from the system drive ends up hurting your ability to troubleshoot when things go bad. If you can live with that (and I choose not to), then go on and remove the little .4GB pagefile from your System (SSD) drive...

Having the paging file on a system SSD means a huge increase in wear on the flash memory and it can kill the drive much faster. I guarantee that your trouble-shooting data will be gone too if the drive fails and wouldn't that completely defy the point of it? You'd even already know the cause of the failure, the SSD, so it'd do you little good.

Besides, why couldn't Windows be set to use another drive for this anyway? You can put a page file on a non-system drive and you can also tell Windows the exact file path name to where you want it to dump troubleshooting data, can't you? I know that there's an easily accessible setting to do something like that in the advanced system properties.

 

[masbicudo]

Changing bytes is not the only thing that can make every other bit of the file rewritten... if you remove or add any single byte, the whole file will be rewritten after that point... and this affects uncompressed files too. What we need to know is: what is the most common operation:
- changing bytes
- adding/removing bytes

Also, NTFS compresses files in chunks of 64kb... leaving some space at the end of the compressed unit: e.g. 64kb after compression becomes 50kb, but it leaves 2kb free, because 50 is not multiple of 4, and it must allocate 52kb... so if you change a byte in the middle of that 50kb, it probably wont make a difference... even if you add a byte, it will probably not make the file rewritten.

As you can see, when using compression, there are less reasons for rewritting the whole file, not more reasons as the poster suggested... but, of course, it all depends on the kind of operation that is most common.

There is even one extra point... applications are not forced to create compressed files if they don't want... I think that SQL Server will created uncompressed mdf files when database is created (or at least it will complain, don't remember exactly), even if the folder has the check to compress files.

 

[masbicudo]

[citation][nom]Anonymous[/nom]because when you modify even just one byte of a file that is compressed, you can end up changing a significant portion of the file, not just that byte. it's good if you can fit the change in one block erase; what if you can't? you'll end up writing more info on the "disk" then.[/citation]

Changing bytes is not the only thing that can make every other bit of the file rewritten.
if you remove or add any single byte, the whole file will be rewritten after that point...
and this affects uncompressed files too.

What is the most common operation:
1) changing bytes?
binary files, with only fixed data
database files - they mostly change/append data

2) append only?
log files - logs are mostly append only files, until they reach max size
journal files - these are high-performance logs used in transactions

3) adding/removing bytes?
files changed by a humans fall into this category: txt, doc, xls, html, cs, vb, js, html... so on
non binary config files (even the ones edited by apps): xml, ini, and so on

4) just reading?
program files, OS files: exe, dll, bmp, png
user media: avi, png, mp3

Where the compression is good or not:
1) bad (increases total writes)
2) very good with simple-logs (reduces total writes)... but very bad with journal files
3) very good (reduces total writes)
4) good (but may have no effect on media files)

(It would be great if there was an app that knew how to classify files into these
categories and apply compression to them, or not)

There is even one other point:
applications are not forced to create compressed files if they don't want.
I think that SQL Server will created uncompressed mdf files when database is created
(or at least it will complain, don't remember exactly),
even if the folder has the check to compress files.

 

[Guest]

I've been able to realize triple space savings with NTFS using Drive Press (http://www.magicrar.com/drive-press.html). I think this also improves overall SSD performance, because there is more spare area available on the drive.

My average space savings are 20%-25% (but this is only after using Drive Press, which compresses more than Windows itself somehow).

TRIM is not an issue within Windows itself, but I employ the best practice of keeping the root of the drive clear so the temp file Intel's SSD Toolbox creates during manual TRIMs is not affected by drive compression.

So I have two 600 GB Intel SSDs on my system - one of them for my source codes, the other for my games. VMs are hosted on both SSDs (there's no RAID involved). The raw capacity of the SSDs is 558 GB. Both drives have 100 GB free space. The source code disk has 650 GB actual usage, the games disk has 550 GB actual usage.

For regular applications, there is no perceived slow-down at all. When I am running 4 VMs simultaneously though on VMware, and doing some heavy-lifting, there is a bit of a noticeable slow-down.

 

[taltamir]

From article:

NTFS compression isn't very aggressive and it excludes important Windows system files

This is false. you tried to compress C drive while the OS was running. NTFS cannot convert a non compressed file into a compressed one or vice versa while the file is locked against writes.

You can compress all those OS files by:
1. Create an empty and compressed partition and then install windows on it (every single file will be compressed)
2. Plug your OS drive as a secondary on another windows machine and use it to compress the now not in use files. (might have permission issues with a few files though).

I am more then a bit curious as to what the effects of NTFS compression are on a sandforce drive though.

 

[installaware]

Apart from the hassle of not being able to convert an existing installation, even with that method some files remain uncompressed.

Just run Drive Press and see for yourself the extra liberated space