First Terabyte-class SSD's released!

[Mike Barnes]

Did you manually delete N:\pagefile.sys? In my experience using the GUI
tools to move the pagefile from one volume to another does not always
delete the original pagefile.

I "moved" it using Control Panel. The result was that N:\pagefile.sys
was deleted, and C:\pagefile.sys was created, on rebooting.

It's not a good idea to put the pagefile on a SSD, IMO, unless you have
no spinning rust to use for it.

I don't.

 

[Paul]

Actually, it has everything to do with it. Some people see putting the
pagefile on SSD, because it's faster than HDD, as a substitute for
adding real RAM. It's a bad idea.

On a modern system, a pagefile is a write-once read-never store.

You should install enough RAM, to meet your peak every-day requirements.
Which the Task Manager can help measure for you.

If you're running a WinXP machine with 256MB of memory installed and an
SSD with a 4GB pagefile defined, well that wouldn't be a good idea.
It implies you want to "run out of the pagefile" as your
normal operating strategy. In that case, the pagefile
isn't being defined for "emergencies". If you ran Photoshop
on billboard sized posters with such a setup, maybe after
two or three years, the SSD would die

If it was a Vista machine with 8GB physical RAM, set your
pagefile to 512MB (big enough to hold 300MB of write-once
info) and you're done.

If you have an older system, with inferior max RAM capability,
stick an actual RAMDisk in it, if you really want to run out
of the pagefile all the time. The problem with that, is the
system busses on older computers suck, and there is no
practical way to do that. On a system modern enough to have
good chipset busses, chances are the max RAM is already high
enough, to use a modestly sized page file.

If you want a stress test for your memory subsystem
(since this is posted to the Windows 7 group),
try the 64 bit version of CHKDSK on a modern system.
Keep the Resource Monitor open and watch the fun. For
a partition with a sufficiently large number of files,
CHKDSK will use (practically) all of the available
RAM (7GB on an 8GB system), and you will see a tiny bit
of paging as other applications are squeezed by the activity.
(CHKDSK isn't as aggressive as I expected, but it
still pushes hard enough to affect other programs.)
That's in case you'd never seen any pagefile
activity on your system, to date.

What matters to the SSD, is the number of writes to
flash locations. Because of the wear leveling algorithm,
it amounts to storage_size * max_write_cycles_per_flash_cell.
On modern MLC, the max_write is down to about 3000 cycles.
If you had a 1TB SSD, you have 3000TB total writes possible.
If, when the system starts up, the OS writes out 300MB of write-once
material, you've used up 300MB of that large number of
lifetime write cycles. If you select the "clean my pagefile
at shutdown" option, now you're paying for writes to the
entire pagefile.

With a little effort, you should be able to study the
wisdom of using an SSD for pagefile, for yourself.
Since I don't own an SSD, I'm in no position to
do this experiment.

Paul

 

[s|b]

It'll last a lot less long than that, but hey, it's your SSD.

I'm positive it'll last more than 10 years. Where do you get your
information claiming that a page file on an SSD will tear down the drive
within 10 years?

I've searched Google (startpage.com actually) - again - for 'page file
ssd'. I recommend you do the same. It seems to me a majority of the
results are positive (= put the page file on a SSD).

<http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx>

<quote>

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.

</quote>

Anyway, I'm not one of those people who keeps using the same computer
(and OS) for over 10 years, so when the SSD eventually breaks down, I'm
probably not using it anymore...

 

[Paul]

I'm positive it'll last more than 10 years. Where do you get your
information claiming that a page file on an SSD will tear down the drive
within 10 years?

I've searched Google (startpage.com actually) - again - for 'page file
ssd'. I recommend you do the same. It seems to me a majority of the
results are positive (= put the page file on a SSD).

<http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx>

<quote>

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.

</quote>

Anyway, I'm not one of those people who keeps using the same computer
(and OS) for over 10 years, so when the SSD eventually breaks down, I'm
probably not using it anymore...

Paging works with 4KB quanta. That means the transaction
size will never be smaller than 4KB. The 4KB size is common
to a lot of OSes, not just Windows.

When the pagefile is fragmented, after a long enough uptime,
you may find "unwinding" the file on a hard drive, is
extremely slow. This is because the system starts reading
randomly placed 4KB chunks. This causes a lot of head
movement on regular hard drives. It can take a minute or
two of time, with the hard drive light on the entire time,
to "virtually remove" some pagefile content by reading it.

An SSD does a better job, because the seek time on an
SSD is anywhere from 20 to 100 microseconds. The 20 microseconds
is roughly the time to read anything of note, out of the flash
chip. So it can't get much shorter than that. And if you
take the inverse of that number, as an estimator, the
SSD can ably handle a random sequence of 4KB accesses
to the page file area. For SSDs with actual cache RAM
inside, they may even have enough read-ahead, to go faster
than those kinds of estimates imply.

*******

Paging policy on OSes, isn't always that predictable,
in the sense that the "paging threshold" can vary from
one implementation to another. There are OSes that start
paging out stuff, when the system RAM is half full. And
other OSes, where paging out begins when the RAM reserve
is quite low.

If you use Resource Monitor in Windows 7, you may be able to
determine just what policies are in place for it. You only
care about the writes - while technically, reads can cause
issues with flash, I'd be more worried about the writes.
I think the argument here, is about reduced write life on
the drive, due to having a pagefile on SSD. You have some
resources on the machine, to check this out for yourself.
Put the pagefile on the SSD, then test it.

Paul

 

[J. P. Gilliver (John)]

Also true, but essentially irrelevant. That has nothing to do with
whether the page file is on a HD or SSD.

Surely, _if_ you have sufficiently little RAM that the page file is
actually _used_ a lot, then whether it is on a "drive" with a known
limited number of write cycles _is_ relevant. (Obviously I agree that
adding more RAM is the better solution, but if that's not been done or
is impossible ...)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

There should be a place on the ballot paper for 'None of the above', and if
enough people filled that in, the system might start to change. - Jeremy
Paxman in RT, 2014/1/25-31

 

[Mark]

Surely, _if_ you have sufficiently little RAM that the page file is
actually _used_ a lot, then whether it is on a "drive" with a known
limited number of write cycles _is_ relevant. (Obviously I agree that
adding more RAM is the better solution, but if that's not been done or
is impossible ...)

Also bear in mind that Windows will use the page file (if it exists)
even when you are not low on memory.

 

[Flasherly]

Also bear in mind that Windows will use the page file (if it exists)
even when you are not low on memory.

&bear in mind, two, a page file is generally preferred for general
principles of programming integrity (some programs expecting it may
throw in operational instabilities w/out a pagefile).

XP here. So - what's with W7 and W8's pagefile status, and if
present/true what's that indicate. . .of course, what we need now is
better, newer and improved SSD, T-class HDs with minature token-sized
platters for securing unruly W-X pagefiles. At under $1000US for such
a SSD would be a steal, for sure.