First Terabyte-class SSD's released!

Paul wrote:
Mike Barnes wrote:


N: used to contain the (only) pagefile (pagefile.sys being probably the
best qualified file in the universe for a NOT BACKED UP volume), and I
was as suspicious as you. As an experiment I tried moving the pagefile
to C: and that made no difference. With my new larger SSD I've now moved
the pagefile permanently to C: and the problem persists.

It's possible that the fact that the pagefile was once on N: is
prompting the unwanted behaviour. But (a) the pagefile isn't there now,
and (b) I would hope that the pagefile is very definitely *excluded*
from any backup so I don't understand the relevance of its location.

My lengthy attempts at exploring the issue with Microsoft, to find out
what criteria or registry settings are consulted in order to establish
the AllCritical list, have got me precisely nowhere.


I lust took a look in the Registry, and I can still see
an entry for a previous attempt to add a second pagefile.
But it's in an "old" ControlSet.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Se ssion Manager\Memory Management
PagingFiles F:\pagefile.sys 3980 3980

Now, if I go to the Performance Options in the System control panel,
that one on F: isn't enabled and the value in question is not
visible. And this is because there are several ControlSet
groups. And I think that is an old one.

In my CurrentControlSet, it's set to this. And this is my
"standard" setting on this system.

PagingFiles C:\pagefile.sys 2048 2048

Take a look at your CurrentControlSet. And if you suspect
Microsoft is actually looking at the others, you could
try editing the other entries back to the way they should be.

Maybe the backup isn't even looking at reg keys, and it did
a quick check for the presence of pagefiles on the other
partitions. (It would be looking for N:\pagefile... type
entries, and not scanning the entire partition or anything.)

Thanks for that. I made similar checks when I looked at this some time
ago, and I've just looked again. There are no occurrences of
"N:\pagefile.sys" in the registry and no such file.

And I've been through much the same process with the TEMP directory:
reasoned that you'd never want to back it up, moved it from N: to C:
anyway, and observed that that had no effect.

It's all getting a bit far fetched, with guesswork layered on
assumptions, and once again, in the absence of any assistance from
Microsoft, I'm going to have to give up. Thanks for your help and for
taking an interest.

--
Mike Barnes
Cheshire, England

In article , Mike Barnes
writes

As an experiment I tried moving the pagefile
to C: and that made no difference.

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.

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

--
(\_/)
(='.'=)
(")_(")

On Thu, 27 Mar 2014 11:20:11 +0000, Mike Tomlinson wrote:

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've read that too, but then some users asked me why I'm using a SSD and
not store the page file on it. I've disabled Superfetch/Prefetch, I'm
not using ReadyBoost, I don't defragment the SSD and moved my temp
folders to another hdd (SATA). So what harm can the page file really do?

--
s|b

In article , s|b
writes

So what harm can the page file really do?

1) If the pagefile gets busy, it'll decrease the lifetime of your SSD,
which can only take a finite number of writes per flash cell.

2) putting the pagefile on SSD to speed up paging operations is a really
bad idea. It not a substitute for real memory. If your machine is so
busy that it needs to use the pagefile, you should fit more physical
memory or close some apps.

--
(\_/)
(='.'=)
(")_(")

On Thu, 27 Mar 2014 14:11:13 +0000, Mike Tomlinson
wrote:

In article , s|b
writes

So what harm can the page file really do?

1) If the pagefile gets busy, it'll decrease the lifetime of your SSD,
which can only take a finite number of writes per flash cell.


True.


2) putting the pagefile on SSD to speed up paging operations is a really
bad idea. It not a substitute for real memory. If your machine is so
busy that it needs to use the pagefile, you should fit more physical
memory or close some apps.


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

In article , Ken Blake
writes

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

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 Thu, 27 Mar 2014 14:11:13 +0000, Mike Tomlinson wrote:

So what harm can the page file really do?

1) If the pagefile gets busy, it'll decrease the lifetime of your SSD,
which can only take a finite number of writes per flash cell.

So it will only last 10 years instead of 20? I'm sorry if I'm not going
to loose any sleep over that.

2) putting the pagefile on SSD to speed up paging operations is a really
bad idea. It not a substitute for real memory. If your machine is so
busy that it needs to use the pagefile, you should fit more physical
memory or close some apps.

I have 8 GiB of RAM installed; that's more than enough for me. People
claim disabling the page file is a bad idea, so I leave it enabled,
system managed size, on my SSD.

--
s|b

In article , s|b
writes

So it will only last 10 years instead of 20? I'm sorry if I'm not going
to loose any sleep over that.

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

--
(\_/)
(='.'=)
(")_(")

Mike Tomlinson wrote:
In article , Mike Barnes
writes

As an experiment I tried moving the pagefile
to C: and that made no difference.

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.

--
Mike Barnes
Cheshire, England

Mike Tomlinson wrote:
In article , Ken Blake
writes

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

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