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".
-
If you really love AI, we have good news for you: RTX 5090 exhibits 27% higher CUDA performance than RTX 4090 — exceeds 500K points in Geekbench
- Status
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.
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.
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.
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
Distinguished
- Feb 2, 2010
- 55
- 0
- 18,630
[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
Glorious
- Sep 24, 2010
- 14,022
- 21
- 43,265
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.
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.
- 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.
[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.
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.
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.
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
Distinguished
- May 9, 2008
- 18
- 0
- 18,510
From article:
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.
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
Honorable
- Dec 3, 2012
- 1
- 0
- 10,510
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
Just run Drive Press and see for yourself the extra liberated space
- Status
TRENDING THREADS
-
-
Discussion PSU recommendations and power supply discussion thread - Tom's hardware- Started by Darkbreeze
- Replies: 2K
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 4K
-
News AMD says Intel's 'horrible product' is causing Ryzen 9 9800X3D shortages- Started by Admin
- Replies: 89
-
News EA will shut down the Origin app on April 2025 — company asks users to migrate to the new EA app
- Started by Admin
- Replies: 18
Facebook
Twitter
Instagram