80 Gb Intel SSD only has 3 Gb space remaining - was supposed to only be OS & Key apps

D

DarkSideA8

Gawd
Joined
Apr 13, 2005
Messages
989
Need some advice on this - I intended for the SSD to only hold the OS & Key apps - but I just noticed that it's damn near full.

When I first loaded the OS (Win 7 64) MS Office & some Adobe programs to the drive, the files only took up 47 Gb. I figured it would stay that way.

Program Files (x86) only takes up 6 Gb, however hiberfil.sys & pagefile.sys have 14+ Gb between them.

The rest of my programs were all loaded on the standard HD. (Some exceptions - printer, Java, other utilities all were allowed to load up to the SSD). Photos & videos are also loaded to a different drive.

How do I find out what else has loaded to the drive to take up so much space?
 
Last edited:
download windirstat

move your pagefile to your other hard drive

turn off hibernation if you can stand it (boots are much faster with the ssd so it's less of a pain)
 
tgrimley said:
turn off hibernation if you can stand it (boots are much faster with the ssd so it's less of a pain)
Click to expand...
Sig says 4GB of RAM, so somehow his page file is 10GB.

Use windirstat like tgrimley said. It'll show you what folders are using the space.
Add RAM, kill page file and hibernation both. Use sleep.
 
right click on my computer > properties
in the advanced tab, under performance, click settings
click on advanced tab in new window
click change under vitrual memory section
set a custom size, put the initial value to something small, like 256 or 512mb and the max value at 2048mb (assuming you would never need to use more than 6GB of memory at any time- if you occasionally do, set the max high enough to cover it. the max page file size + physical ram = amount of memory you can use before running out and crashing programs).
 
Oops - forgot to update sig - actually have 8 Gb RAM.

Thanks for the suggestions.

Had to use cmd prompt to eliminate the hiberfil - but your suggestion re: changing the pagefile worked like a charm.

So I used windirstat (Thanks, BTW) and discovered that Empire Total War has been dumping all the save game files into my C drive - despite the fact that the game itself is purposefully loaded to a different drive. Those files took up 18 Gb.

Apparently saves are going to C:\Users\YourUsername\AppData\Roaming\The Creative Assembly\Empire\save_games...

I'm trying to find out (via game forums) if it's possible to change the save file location in the game - but from what I've read, its unlikely.

So - does anyone know if it is possible to re-route the Users file to another drive, even if the OS is on C?
 
Last edited:
Check to see how much resources are being used for the restore function.
 
Actually - a more important question: I've got the 80 Gb Intel X-25 M SSD - and ran the TRIM update (successfully) shortly after I received it.

Since I know nothing at all about how this works (I just know TRIM had something to do with letting the SSD clean memory blocks & free up memory) - do I have to do anything special after I delete files - or does TRIM run automatically?
 
Spacesniffer is also very good in addition to windirstat.

For moving folders to a different drive you'll want Link Shell Extention, I believe there are also some software available that do this.
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html

You can turn off hibernation with command 'powercfg -h off'. I'd turn the pagefile down to 2GB.

You can also enable compression on C and not notice much or any slowdown. And delete old restore points.
 
http://www.rekenwonder.com/linkmagic.htm
http://en.wikipedia.org/wiki/NTFS_junction_point

Saving disk space

Since the contents of a junction do not take up any space (they simply point to the original files in the original directory) if you need to have multiple points of entry to a large directory, junction points will serve that purpose well. Do not confuse junction points with a copy of something as it simply points to the original. If directories need to be modified separately a junction cannot be used as it does not provide a distinct copy of the directory or files within.

Circumventing pre-defined paths

Since reinstalling Windows (or installing a new version) often requires deleting the contents of the C: drive, it is advantageous to create multiple partitions so only one partition needs to be deleted during the installation. However, some programs don't let the user choose the installation directory, or install some of their files to the C: drive even when they are installed to a different drive. By creating a junction point, the program can be tricked into installing to a different directory.
Click to expand...

I use Junction Links to have my Steam folder on my SSD and the SteamApps folder on a 600GB Velociraptor.
 
Steam Mover is handy for moving Steam (and other) apps from your SSD to another drive seamlessly. It's just using junctions, but it's an idiot-proof GUI for doing so.

The easiest way to relocate your profiles directory is to do it with an answer file during setup. Windows gets installed with all the proper settings from the start. However, I'd say that you're better off leaving your main profiles dir on the SSD, and just moving the big items off. Your profile holds quite a bit of stuff in AppData and Temp that lose the benefits of SSD if you move them. Move your Downloads and maybe Documents to the other drive to save space, but keep the rest of the profile on the SSD so all those random little files become much faster.


Keep the pagefile on your SSD and size it properly.

http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
Mark Russinovich of Sysinternals said:
How Big Should I Make the Paging File?

Perhaps one of the most commonly asked questions related to virtual memory is, how big should I make the paging file? There’s no end of ridiculous advice out on the web and in the newsstand magazines that cover Windows, and even Microsoft has published misleading recommendations. Almost all the suggestions are based on multiplying RAM size by some factor, with common values being 1.2, 1.5 and 2. Now that you understand the role that the paging file plays in defining a system’s commit limit and how processes contribute to the commit charge, you’re well positioned to see how useless such formulas truly are.
...
To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number.
Click to expand...

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx
Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

* Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
* Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
* Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.

In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.
Click to expand...

Repeating for emphasis: there are few files better than the pagefile to place on an SSD.
 
You must log in or register to reply here.
Back
Top