Page file with SSD, indexing

Hello again! I have two questions that I'm wondering about, and I need some insight from you smart people!

Question 1: Page file location and size

I have as my main drive an 80GB SSD and also have 3 standard HDD's for storage. 1 for music, documents, etc. 1 for movies, and 1 for TV recording with media center. My OS is Windows 7 ultimate 64 bit with 4GB of DDR2 PC2-6400 RAM . As it currently stands, I have one single page file set to 6GB. I recall the rule of thumb as using 1.5x your RAM for page file size? Is this correct/OK?

I have that single page file located on my SSD along with the operating system. I figure this will yield the best performance due to the read/write speeds of the SSD. But I am also wondering if this is more beneficial than locating the page file one of the other standard HDD's that is not used very often.

So which of these scenarios would be the better option:
- page file on same drive as OS with the benefit of SSD speeds
- page file on a different drive than the OS but with the lower speeds of a standard 7400RPM HDD

Also, if locating the page file off of the OS drive is the better option, keep it one one single HDD or split it up between the three HDD's?

Question 2: Windows indexing... on or off?

I'm wondering which scenario is better for making my PC more responsive/faster/etc. What I am not sure of is whether it is better to have indexing on so the system can find things faster, of if it is better to have it off so that the system isn't constantly getting slow downs from windows indexing folders/directories that I'm opening up and going through. It seems like every time I open a folder with a lot of files in it (like my movie folder that has like 700GB+ in it) there is always a long pause while windows indexes all the files in it (the green "meter" in the address bar at the top of the window) Is it supposed to do this every time? I thought the point of indexing was to make it so it DOESN'T have top scan the contents of a folder every time you open it up. Is indexing ONLY used to make searches faster? Like as in Start > Search? Or does it keep track of things and make navigating your folders faster? Because if it's just to make normal searches faster, I can definitely do without it as I never use the search feature anyway.

So anyway... that's it. Any insight you can provide is appreciated!

EDIT:

Hmmm... after doing some reading/research, it would seem that a page file on the SSD would be a bad idea even if it is beneficial to performance in the short term... because of the constant reads/writes it shortens the SSD's life span?

If this is so, it would definitely be better to move it over to one or more of the stantard secondary HDD's.

In that case:

- How much total page file should I use? Space isn't an issue, my HDD's hold 2.5TB in total.

- Is it better to have the PF on one single drive or split it up between multiple drives?

- Is it OK to have absolutely NO page file on my OS disk, or should I leave a very small one there... like 256MB or so? I have heard that this is necessary in the case of crashes for error reports, dump files, etc.

Yep, pagefile on SSD will shorten its life.

If you cpu is a fast quad and you have lots of files, shouldn't notice indexing.

6GB should be more than enough for 4GB ram, never set pagefile to zero, if you have 8GB or more, set it to a static 1GB.

About this... I opened up the defrag utility, to make sure defrag was disabled on the SSD but windows is not even showing the SSD on the list of drives for the scheduled defrag. Does Windows 7 automatically exclude SSD drives from the defrag utility?

Defrag list/schedule: http://i46.tinypic.com/10eljyb.png

Eh... true I rarely if ever use up all 4GB of my RAM. But I set a 1GB page file on each of the 3 HDD's anyway. It doesn't really hurt anything to have more than I need, and the 3GB is only like 0.2% of my storage space so it doesn't hurt me any.

Left a 200MB page file on the SSD as when I tried to remove it Windows told me it was a bad ideal lol.

You want to minimize read/write operations on the SSD. Whether you have 200MB or 1GB or 2GB, a read/write operation is a read/write operation.

Bah humbug. More SSD paranoia. You will not kill your SSD with a page file. It will easily survive the warranty period and likely beyond that. Benchmarking kills SSDs. That said, you will not benefit a great deal from the page file being on the SSD unless you constantly run low on RAM and use the page file excessively in a short period.

@RetiredChief: Where you expecting degradation in just 2 months? I expect my hardware to at least last the warranty period unless I abuse it.

This is not accurate. Windows does not specify where to write data on the SSD, the SSD controller does this. Windows has no knowledge of the physical location of any data or even if it is moved by the controller, Windows only knows the data's Logical Block Address. The controller maps the LBA with the physical NAND location. The controller will automatically spread data out over the drive to ensure only a small difference exists between the block with the most erases and the block with the least. For this very reason there is technically no such thing as a sequential read or write on an SSD.

When data on the same file changes, the controller will not overwrite the same blocks. Instead, it will try to write to a fresh block with no data. If none are available, it will have to cache the data in a partially filled block, erase the block, then re-program it with both the old data and the new data to be written. Once this occurs the map between the LBA and the physical NAND location is updated to ensure that when the data is read again that the controller access the correct blocks.

Data is only moved during idle periods or when absolutely necessary, such as when all free blocks are gone and some over-provisioned NAND is required to shift around and consolidate some data and free some blocks (this mostly happens when the drive is nearly full). It is also moved when a block can't be erased or programmed due to excessive use, in which case the data is read from that block, stored elsewhere, and the failed block is marked as bad and never written to again. In this event, a block in the over-provisioned NAND is activated to ensure that drive capacity remains the same.

Defragmentation is useful for different reasons to a HDD. Defragging a HDD reduces drive head movement because access time is horrendously slow otherwise. SSDs have the same access time for every cell so this is not an issue. The "problem" with SSDs is that they do not write sequentially. The controller selects where to write by "asking" two basic questions (there's probably alot more technical stuff behind it but let's not make things more complicated that necessary):

1) Are there any free blocks (ie. any blocks that have never been written to or have been erased so that they are filled with all 1's)?
2) Which blocks have the lowest erase count?

If you (hypothetically) have an SSD with only 2 blocks – one has been half filled while the other is free – and you wish to write half a block's worth of data, the controller will write to the 1 free block rather than erasing and reprogramming the partially filled block, as part of industry standard wear levelling (note that a block cannot be programmed twice without first being erased). This is why SSDs are extremely fast for a time. When all free blocks visible to the OS have been used up, the drive will begin to slow because most writes will require a program/erase cycle and erasing is very slow compared to simply programming a free block.

What defragging will do is grab data from partially filled blocks, write that data to another partially filled block to fill it, have the first block marked as "invalid" and then allow you to use another program to "erase" the first block (write all 1's to it) so that rather than having two blocks that will require a program/erase next time they are written to you now have only one and one free block that runs at "full speed."

You must use the correct defrag algorithm for SSDs though. You do not want the defrag program to try and consolidate bits of the same file as this is not necessary due to the almost zero access time. You want it to consolidate any data in any location. After this you want to write all 1's to the blocks that are now "invalid," which is in essence what TRIM causes.

For info on how to do this check here: http://www.ocztechnologyforum.com/ [...] hp?t=64753

I realise I am well outside of the scope of this thread now

From Randomizer
@RetiredChief: Where you expecting degradation in just 2 months? I expect my hardware to at least last the warranty period unless I abuse it.

There are a lot of SSD's out there that will develop considerable degragation well before warrent runs out. Those that are not trim awear and/or are used in XP/Vista operating system. Some do have a utility that mimics Trim Cmd that will have to be run manually and depends on use

With a Trim enabled SSD and Win 7 - Answer No
Bear inmind that only a realtively few SSD are trim enabled. Intel only recently provided a firmware update for G2 (0AHD) that enabled trim cmd. And I have not seen any degragtion (Over two weeks). Do not expect any - Win 7 and 0AHD firmware.

My Pateriot Torqx (Also Trim enabled) was in a win7 RC (non-trim) single Drive Laptop enviroment, and yes there was some degragation over short period of time (important to note this was small change and not noted in normal operation). Used patriot.exe on a weekly basis (Read someware that this was the recommended interval in a non-trim enviorment).

PS - good explaination

I'm well aware of this drop in performance, but I don't call it "degradation" because that's a rather harsh term that I've never seen applied to HDDs even though the same thing happens to them (different cause, same end result). TRIM is not going to help if you don't delete any data though. If you repeatedly write data to the drive, including "overwriting" without deleting, TRIM will not prevent slow-down.

If you really want a warm fuzzy feeling from high speeds when you run a benchmark like ATTO you need only delete 250MB of data and it will look as though you've got a fresh drive again.

Read my wall of text above and you'll see that fragmentation is an issue with SSDs, but a different issue.

Indexing doesn't need to be disabled, it should just be disabled for the SSD. Of course, there's no harm in disabling the service altogether, and some people find it slows down their system. I haven't noticed this slowdown, but I don't have much data either.

I see that someone does call it degradation with regard to HDDs, but if you look around most forums you don't see it used nearly as often as it is in reference to SSDs. The issue is overstated as though SSDs have some serious flaw that HDDs do not when in fact they are functioning exactly how they should be. This is what I was getting it

You can't disable the page file in Vista or Win 7.

That doesn't disable it, that just means the OS will use the system drive for the page file as necessary.

The system drive also has the page file disabled:



Trust me, this really, truly disables the pagefile. I just ran multiple copies of a program that uses up a great deal of memory so that even on my 12GB system all of the memory would be consumed. With no page file, what eventually happens is that the screen goes black because the desktop window manager itself ends up without any memory to use.

I was able to use "Alt-Spacebar, C" to blindly close my test programs which freed enough memory to get the DWM working again, and the system carried on as if nothing had happened. And in all this time no pagefile was created on the system drive.

Although I have now read it, I will also take it with a pinch of salt.

It's true that disabling the pagefile doesn't actually turn off paging or virtual memory support. Program code doesn't change at execution time - this means that when the system gets low on memory and pages containing program instructions are kicked out, they don't really need to be written to the pagefile. Instead, the memory pages are simply marked as "free" and if the system needs to reload the code it does so directly from the EXE file.

Not only that, but a lot of programs do file I/O by mapping a portion of their virtual address space to the file, leaving the gruntwork to be done by the paging subsystem. It's actually a very efficient way to do I/O if the file will fit into the program's virtual address space.

So disabling the pagefile doesn't disable paging. But it really does get rid of the pagefile.

Do everthing with your SSD except Defrag. SSD was designed to work super fast and the page file or setting up partitions is exactly the same as a standard HDD. Just don't DEFRAG.

Edited:

I forgot to mention that you should 'leave you file indexing on as well'. Some HDD backup software rely on file indexing to copy your various backup methods.

If you want a faster computer than you need an expert to optimze the system using all advanced Windows Settings. This does not include overclocking your CPU.

I have optimized over 1000 systems since 2002 remotely from my home computer. I know the scoop. Tech-heads can get very carried away with too many tweaks. There is a simple routine for getting the most Oomph out of your computer as it is designed to give you. So keep googling and find the advanced settings adjustments and you'll be fine. You can contact me too if you like, but to post everything in here would take two web pages.

Some programs don't play nice without a page file. Photoshop 6 was in that category. But modern systems can easily have enough memory to make a pagefile redundant, and if I knew that a particular program wouldn't work without a pagefile then I'd buy something else instead.

So you're not thrashing the *** out of your expensive SSD?

Yes, XP used it to compensate for insufficient RAM, but with 12GB RAM now reasonably affordable the page file isn't necessary. Some may want to reclaim the disk space, others may want to preserve their SSD in light of the technically true but dubiously supported belief that SSDs will die in 6 months if you write to them too often.

It's all about options. Personally, with 12GB RAM I'll have a page file set to minimum on a HDD just so any apps expecting it won't complain, but I doubt I'll be hitting memory issues. If I do, I'll just whack a 1GB page file on my SSD OS RAID and by the time the drives die SSD tech will be much more robust and affordable so it's easy to replace.

oh i entirely agree, but for some they'd just prefer to kill the pagefile and get some space back if they're sure they won't need it.

Each to their own really

The problem is that the OS is brain-dead when it comes to figuring out pagefile sizes. It typically defaults to 1.5 X the size of RAM, which is ludicrous on a 12GB system unless you're running an insane amount of stuff.

Windows does this because it takes a "better safe than sorry" approach. That approach was really important when systems were memory-bottlenecked. But RAM is extremely cheap these days, and it's easy to build a system that has more RAM than you'll ever need.

What it boils down to is this: use your system to do your typical work for a week or two and make a note of the highest amount of committed memory that you've ever consumed. Add, say, 25% or even 50% as a safety margin. If that works out to be smaller than the amount of RAM you have, then a pagefile is superfluous. Completely. There is no reason in the world that you need one - period.

6GB is fine if the programs you run don't use up more than that. And don't forget that for SSDs, the downside to a lot of memory is that you end up with a large "Hiberfil.Sys" in your root directory that you can't move to another drive. The only way to eliminate it is to disable sleep mode, which you may not want to do.

Technically you're correct. However the default sleep mode is "hybrid sleep mode" which I tend to prefer over standard sleep mode because the standard mode depends on continuous power to RAM to maintain the state of suspended programs. In hybrid mode the hibernation file is still required to store a copy of memory contents so that in the event of a power interruption you can still resume your work after it's reloaded from disk.

Wow, this thread has been fantastic. Thanks especially to sminlal and randomizer for all the information they shared. I just ordered 2 Intel X-25M SSDs and came to Tom's Hardware to make sure I was prepared to set them up correctly. From the information in this thread I pretty much know exactly what I need to do.

I just have one question left. I saw on another thread (http://www.tomshardware.com/forum/256086-32-which) someone advising to partition the drive shorter than its capacity (around 10 - 20 GB) "making sure that the last 10-20GB are never in its lifetime written to."
Is this sound advice?

Awesome, thanks geofelt. I am glad I don't have to do that, and also glad that Intel's engineers thought of that. Wow, SSDs have come a long way, but I am excited to see how much further they can go.