Sign in with
Sign up | Sign in
Your question

SSD for pagefile?

Last response: in Storage
Share
June 4, 2011 7:43:10 AM

I am planning a new system and was going to use a OCZ Vertex 3 120 gig as a system disk (Win 7 Ultimate x64). The system has 8 gigs of RAM. I will be doing lots of transcoding and Photoshop raw image editing. I am concerned that I'll get lots of pagefile activity and this will cause premature age failure of the MLC NAND. Does anyone have any experience here?

More about : ssd pagefile

June 4, 2011 8:44:15 AM

BassetBoy said:
The system has 8 gigs of RAM. I will be doing lots of transcoding and Photoshop raw image editing. I am concerned that I'll get lots of pagefile activity


When you have such large amounts of RAM it is possibly that the pagefile usage will be quite low, but you will have to monitor during usage. Check this article how to read the memory statistics in Windows 7:

http://rickardnobel.se/archives/89

m
0
l
June 4, 2011 1:35:39 PM

Photoshop needs a swap file/scratch disk regardless of how much memory you have. It is best to put it on your non-OS HDD drive.
m
0
l
Related resources
June 4, 2011 2:03:43 PM

timinator said:
Photoshop needs a swap file/scratch disk regardless of how much memory you have. It is best to put it on your non-OS HDD drive.


From what I understand this is kind of a mis-understanding. Some version of Photoshop looks for the drive Windows uses for its pagefile to be able to place it own scratch space on some other drive.

There is no program that actually "needs" a swapfile since it is invisible to the application how Windows manages the virtual memory.
m
0
l
June 4, 2011 3:51:55 PM

ricno said:
From what I understand this is kind of a mis-understanding. Some version of Photoshop looks for the drive Windows uses for its pagefile to be able to place it own scratch space on some other drive.

There is no program that actually "needs" a swapfile since it is invisible to the application how Windows manages the virtual memory.


Photoshop CS5 works just great with my swap/scratch on my data drive.
m
0
l
June 4, 2011 6:45:37 PM

timinator said:
Photoshop CS5 works just great with my swap/scratch on my data drive.


Then the potential need for the Windows pagefile from Photoshop should be gone.
m
0
l
June 4, 2011 6:58:07 PM

So if Photoshop is no problem and 8 gigs of RAM mean Win 7 will do little swapping normally, then it appears I should track transcoder memory usage and add RAM if it causes excessive paging. Otherwise, I'm good to go?

EDIT: What I SHOULD have said is that being able to configure photoshop to use a (relatively fast) HDD for scratch makes it a non issue for SSD activity.

I am still faced with Windows paging when it needs ram and specifically what kind of memory footprint is used by my transcoder programs. If I can virtually eliminate paging it doesn't matter where the pagefile is, because it won't be used (zero reads and writes take zero time no matter how slow each read and write would be).

To insure this, additional RAM may be needed. In any event the pagefile (such as it is) will go on a relatively fast HDD and my SSD will live forever.

Thanks all. This has been useful.
m
0
l
a b G Storage
June 4, 2011 6:58:33 PM

The Windows Pagefile is used when Windows gets low on RAM and is separate from the Photoshop scratch disks. Never have your Photoshop scratch disks or Windows Pagefile on an SSD if you can help it, as it will greatly reduce the life of your SSD. Photoshop is more than happy to use whatever memory it can get, depending on your projects even 8GB might not be enough.
m
0
l
June 4, 2011 7:45:42 PM

LordConrad said:
The Windows Pagefile is used when Windows gets low on RAM and is separate from the Photoshop scratch disks. Never have your Photoshop scratch disks or Windows Pagefile on an SSD if you can help it, as it will greatly reduce the life of your SSD. Photoshop is more than happy to use whatever memory it can get, depending on your projects even 8GB might not be enough.



Win pagefile and/or Photoshop scratchdisks are not going reduce the life of any current SSD to any noticeable degree. Saying "will greatly reduce the life of your SSD" is pure exageration and untrue. Not using your fastest medium (beyond RAM) for this type of temp storage use defeats the whole purpose and wastes the inherent strengths of how SSD's operate. What really reduces the life of SSD's are all the HD benchmarks that everyone runs and at a far greater magnitude than the Win pagefile and/or photoshop type scratchdisks will hurt the overall life of an SSD.
m
0
l
June 4, 2011 8:49:17 PM

You don't need a pagefile at all with 8 gigs of RAM -- turn it off.

Photoshop does complain that "Running windows without a swap file is dangerous!" but it's lying, especially with that much RAM. I've run Photoshop without a pagefile quite often and I don't think it's ever crashed on me (usually other stuff crashes first when you run out of memory :)  ).

I used to have an XP laptop with 384 MB of RAM that I ran without a pagefile, and I ran Photoshop CS2 on that without problems. (Couldn't run Firefox at the same time as CS2, but Opera ran alongside it just fine).

~Felix.
m
0
l
a b G Storage
June 5, 2011 6:16:44 PM

Xer0, Your free to use your SSDs as you like. I'm just saying that I know people (Photoshop and Premiere users) who had to buy a new SSD every six months, until they stopped using their SSDs for scratch and swap files.

If you do a lot of work with large temporary files (transcoding, scratch disks, etc.), it's much better to put those files on a hard disk RAID 0 setup. Hard drives don't have a limited number of program/erase cycles like SSDs do. You do lose a little reliability with RAID 0, but the files are temporary so who cares.
m
0
l
a c 415 G Storage
June 5, 2011 7:46:25 PM

ricno said:
Then the potential need for the Windows pagefile from Photoshop should be gone.
I can confirm that Photoshop CS4 works perfectly well with NO pagefile. I've been using it that way for a couple of years without any issues. That wasn't true of some older versions of Photoshop - for example I was never able to get Photoshop 6 to run properly without a pagefile.

thetrivialstuff said:
You don't need a pagefile at all with 8 gigs of RAM -- turn it off.
This may be true, but it could also cause grief. Each user is different, and it's dangerous to make generalizations such as this because people use different amounts of RAM depending on the combination of programs and documents/files that they have open at any one point in time.

To find out how much pagefile you need, run Task Manager (Ctrl+Shift+Esc) and click the "Performance" tab. The "Memory" bar graph (to the left of the "Physical Memory Usage History" graph) shows how much memory you're using. Start up all the programs you might possibly run at the same time and use them to open the biggest documents/files/photos/movies that you may ever have open at once. Note the amount of RAM in the bar graph and add perhaps 25% to 50% as a safety margin. For example, if your bar graph shows 6GB, then you'd probably be safe in assuming that you need no more than 8GB of memory.

If you've actually got that much or more physical RAM installed in your system then it should be safe to disable your pagefile altogether. If you have less actual RAM, then your pagefile needs to make up the difference. For example if you've determined that you need 8GB of memory (after adding your safety margin) but you only have 6GB of actual RAM installed in your machine, your pagefile(s) should have 2GB worth of space to make up the difference.
m
0
l
June 5, 2011 8:02:42 PM

LordConrad said:
Xer0, Your free to use your SSDs as you like. I'm just saying that I know people (Photoshop and Premiere users) who had to buy a new SSD every six months, until they stopped using their SSDs for scratch and swap files.

If you do a lot of work with large temporary files (transcoding, scratch disks, etc.), it's much better to put those files on a hard disk RAID 0 setup. Hard drives don't have a limited number of program/erase cycles like SSDs do. You do lose a little reliability with RAID 0, but the files are temporary so who cares.


Do you understand what happens to an SSD that has run out of write cycles on it's NAND? It becomes read-only memory. It doesn't simply stop working. I work in manufacturer's SSD R&D (who also makes much of the NAND used in many SSD's) and while typical "current" 25nm and 34nm MLC is rated between 3000-5000 write cycles, it is "conservatively" rated as such. Neither you or any of your friends who work with Photochop or Win Temp files are blowing through this many write cycles in a 6 month period without doing "other" much more destructive writing.

In fact it's extremely rare that any SSD has all of it's write cycles burned up. It is FAR more likely that there is a controller failure from firmware or other electrical burnouts/failures, that have nothing to do with the number of write cycle endurance left in the NAND. Even in our labs running 24x7 weeks-long full write tests, which is a thousand times more intensive than photoshop or win pagefiles, we rarely use up all the write cycles of the NAND before other failures occur. While these "other" (aka non NAND write-endurance related) failures suck when they happen, it has nothing to do with anything photoshop or win pagefiles is going to make occur faster or slower.

If your "friends" are buring out current SSD's in 6 month periods, they are either buying crappy SSD's, doing odd things to the SSD's, or simply have failures they are blaming erroneously on NAND write cycle limitations. Don't get me wrong, SSD's will fail, but unfortunately, very rarely will the failure be from write cycle endurance life of the NAND, and definately not because the SSD is used with photshop scrathdisks or win pagefiles.

To use a unpopular automotive analogy, the NAND write cycle life is like the engine of a car that is used where they use salt on the roads to melt ice. While it is possible for the engine to die from being used too much, it is much more likely the body of the car is going to rust/rot away before the engine has outlived it's useful life. And this car does not care if photoshop or win temp files are in the passenger seat. If the SSD fails under 2-3 years of normal use, it won't be because of photoshop or win pagefiles using up the NAND write cycles.
m
0
l
June 5, 2011 8:03:28 PM

sminlal said:
You don't need a pagefile at all with 8 gigs of RAM -- turn it off.[/msgquoted said:


This may be true, but it could also cause grief. Each user is different, and it's dangerous to make generalizations such as this because people use different amounts of RAM depending on the combination of programs and documents/files that they have open at any one point in time.

To find out how much pagefile you need, run Task Manager (Ctrl+Shift+Esc) and click the "Performance" tab. The "Memory" bar graph (to the left of the "Physical Memory Usage History" graph) shows how much memory you're using. Start up all the programs you might possibly run at the same time and use them to open the biggest documents/files/photos/movies that you may ever have open at once. Note the amount of RAM in the bar graph and add perhaps 25% to 50% as a safety margin. For example, if your bar graph shows 6GB, then you'd probably be safe in assuming that you need no more than 8GB of memory.]You don't need a pagefile at all with 8 gigs of RAM -- turn it off.


This may be true, but it could also cause grief. Each user is different, and it's dangerous to make generalizations such as this because people use different amounts of RAM depending on the combination of programs and documents/files that they have open at any one point in time.

To find out how much pagefile you need, run Task Manager (Ctrl+Shift+Esc) and click the "Performance" tab. The "Memory" bar graph (to the left of the "Physical Memory Usage History" graph) shows how much memory you're using. Start up all the programs you might possibly run at the same time and use them to open the biggest documents/files/photos/movies that you may ever have open at once. Note the amount of RAM in the bar graph and add perhaps 25% to 50% as a safety margin. For example, if your bar graph shows 6GB, then you'd probably be safe in assuming that you need no more than 8GB of memory.


Your bar graph should never show anything remotely close to 6 GB unless you're doing some *serious* work (large-scale 3D rendering, games, full-resolution HD movie CG effects processing, etc.) -- I know modern software is inefficient, but if it's getting that bad for everyday tasks I think we need to introduce the death penalty in software engineering :p 

No matter what combination of pagefile/physical RAM you use, the memory model is effectively the same: "you get this much RAM, the end." OK, pagefiles can be set to dynamically grow, but that's generally a bad idea -- the expanded pagefile gets fragmented (unless it's got a dedicated partition, but that's the same thing as setting a fixed pagefile the size of that partition), so performance is terrible. And virtual memory is dead slow to begin with -- if you're using it at all, it should really only be as last-resort space that programs can grow into if they have nowhere else to go and you don't want them to crash. You shouldn't use virtual memory as if it actually gives you more RAM unless you like waiting minutes for your hard drive to thrash when you hit Alt+Tab.

In the days when physical RAM was expensive and most computers didn't have "enough", virtual memory was a common crutch. But we've reached the days when RAM is so cheap that every computer, even the bargain basement ones from department stores, have way more RAM than they should ever need. No computer with more than 1 GB of RAM should need a pagefile, and with memory prices the way they are, you should just buy more physical RAM if you're thinking about turning on the pagefile.

~Felix.
m
0
l
June 5, 2011 9:50:01 PM

sminlal said:

To find out how much pagefile you need, run Task Manager (Ctrl+Shift+Esc) and click the "Performance" tab. The "Memory" bar graph (to the left of the "Physical Memory Usage History" graph) shows how much memory you're using.


I belive that you should not only look at the Memory bar, but also at the "available" and the Page file usage in Performance Monitor to get a somewhat more complete picture of how memory is used in Windows 7.

See this article: http://rickardnobel.se/archives/89
for an explanation of these numbers which have changed a lot, for example that ongoing pagefile usage must be observed through perfmon, as the green memory graph in Win7 is actually not showing how much Physical memory + pagefile we need, since a lot could already be swapped out and not visible here.

thetrivialstuff said:

OK, pagefiles can be set to dynamically grow, but that's generally a bad idea -- the expanded pagefile gets fragmented (unless it's got a dedicated partition, but that's the same thing as setting a fixed pagefile the size of that partition), so performance is terrible.


During the times I used a pagefile I always set a fixed min and max size because it felt good, but I actually belive that performance problems of fragmented pagefiles is not a reality.

thetrivialstuff said:

You shouldn't use virtual memory as if it actually gives you more RAM unless you like waiting minutes for your hard drive to thrash when you hit Alt+Tab.


There is also some confusion going on regarding some phrases here. Virtual Memory will always be in use and is extremely useful, however this does not mean that we use any paging file / swapping. Microsoft has however been a bit sloppy with this terms and given the incorrect view that Virtual Memory is the same as expanding Physical Memory into a hard disk located swap file (which I agree is a bad idea).
m
0
l
a c 415 G Storage
June 5, 2011 10:12:15 PM

thetrivialstuff said:
Your bar graph should never show anything remotely close to 6 GB unless you're doing some *serious* work (large-scale 3D rendering, games, full-resolution HD movie CG effects processing, etc.)
My point is that some people (including myself) actually do the kind of work that benefits from a lot of RAM and it's not a good idea to blindly advise them to disable their pagefile. I wouldn't have bought 12GB of ECC RAM if I didn't need it.

thetrivialstuff said:
No computer with more than 1 GB of RAM should need a pagefile
Is that a typo? 1GB is tight for a Windows 7 system and I'd never tell someone with only that much RAM to disable their pagefile.

ricno said:
See this article: http://rickardnobel.se/archives/89
That's quite a nice article, thanks for the link. While it's true that the "Memory" graph doesn't include the file cache, I don't think that's a real concern since Windows will simply use less RAM for caching in a memory-poor situation. But some your points are well taken - I think I'll have to do some experimenting with my old 1GB laptop to see how this works for myself.
m
0
l
June 5, 2011 11:31:47 PM

There is also some confusion going on regarding some phrases here. Virtual Memory will always be in use and is extremely useful said:
There is also some confusion going on regarding some phrases here. Virtual Memory will always be in use and is extremely useful


D'oh -- you're right; I should be more careful with my terminology.

(Quote tags are broken -- start parent quote)

No computer with more than 1 GB of RAM should need a pagefile said:
No computer with more than 1 GB of RAM should need a pagefile

Is that a typo? 1GB is tight for a Windows 7 system and I'd never tell someone with only that much RAM to disable their pagefile.

(/end parent quote)

I never said Windows 7 was a well-designed OS :)  (It's basically Vista under the hood, with only the absolute worst of the design decisions tidied up a little bit -- the user interface / front end is quite optimized, but it's mostly cosmetic. Someone did an amazing job of making it all run so reliably, but throwing it out and starting over with a clear set of designs would still have been a better course.)

I also probably would not tell someone running Windows 7 on 1 GB of RAM to disable their pagefile, but I *would* tell them that they shoudn't need one ;) 

And yes, I stand by what I said; 1 GB is way more than general software should need, and certainly way more than any OS should need just to run. If your OS requires more than a couple hundred megs (if that) to run itself, it was written by some of those software engineers I mentioned earlier (the ones who ought to be shot ;)  ).

On my main desktop, I have 2 GB of RAM and generally never go above the first GB unless:

- my web browser has a memory leak (happens saddeningly often, but not so much now that Opera has that "enable plugins only on demand" setting)

- one or more of my virtual machines are running

- I'm doing games or 3D work

I do have a Windows 7 partition on my laptop, which has 1 GB of RAM, and I think I run it without a pagefile -- though that's not really representative, as I've stripped it down a little bit, and only ever boot into it for one-off things that I want to try / have to do in Windows.

~Felix.

(edit: fixed quoting tags)
m
0
l
June 6, 2011 1:49:26 AM

Thanks guys. I know how virtual memory works and that has little to do with my issue. I think that the discussion has led me to an operational conclusion tho. If I add another 8 gigs of RAM making a total of 16 gigs, I can either a) set the pagefile to a HDD knowing that the memory manager will save me from making slow disk accesses because the disc will get little or no use or b) configure the extra RAM as a RAM Disk and put my pagefile there knowing it will be faster and more durable than a SSD (but probably slower than A (above) because of the extra CPU cycles needed to execute the Ram disk file system code).
m
0
l
a c 415 G Storage
June 6, 2011 2:06:12 AM

Unless you have some ancient program that won't run without a page file, don't bother putting the pagefile onto a RAM drive. You're far better off using the same RAM space directly for programs and file caching. You don't gain anything (and actually loose performance) by forcing a program to pagefault and have the OS perform a virtual I/O operation and memory remapping in order to access it's memory.
m
0
l
June 6, 2011 2:08:04 AM

BassetBoy said:
or b) configure the extra RAM as a RAM Disk and put my pagefile there


Wait, what? What would be the benefit of this over just using that RAM as RAM?

~Felix.
m
0
l
June 6, 2011 6:03:53 AM

thetrivialstuff said:
Wait, what? What would be the benefit of this over just using that RAM as RAM?

~Felix.

Works great for 32-bit systems, allowing them to use more physical ram as a RAMdisk, then dropping the swap file right in there. An article is on this very website about it too.

I'd have gone 16gb and ramdisk part of it myself if my budget wasnt so tight...
m
0
l
a c 415 G Storage
June 6, 2011 6:26:35 AM

> Works great for 32-bit systems, allowing them to use more physical ram as a RAMdisk

Fortunately we've finally reached the point where we no longer need to fiddle around with jury-rig solutions in order to overcome the limitations of 32-bit addressing. Just install a 64-bit OS and have done with it.
m
0
l
June 6, 2011 6:32:45 AM

KazumaCTHDWE said:
Works great for 32-bit systems, allowing them to use more physical ram as a RAMdisk, then dropping the swap file right in there. An article is on this very website about it too.

I'd have gone 16gb and ramdisk part of it myself if my budget wasnt so tight...


I thought that was just for XP? (Googles...) oh, right Microsoft likes to arbitrarily limit memory support for the "home" editions... ~sigh~ been using Linux too long ;) 

I admit I haven't actually tried to run a 32-bit system with more than 2 GB of RAM, mostly 'cause computers I own are about 5 years old minimum (I'm cheap), and I'm already running a 64-bit kernel on my laptop with no problems, so by the time I do end up with that much RAM it'll be a 64-bit system.

It seems to me though, that if a 32-bit system can access the higher memory at *all*, then it should be able to use it normally -- how can it access it as a RAMdisk but somehow not use the same technique to just put normal memory there? They're using address extensions (or something) in there *somewhere*; seems weird that they couldn't just plug it into the main memory management system directly.

~Felix.
m
0
l
June 6, 2011 7:38:34 AM

KazumaCTHDWE said:
Works great for 32-bit systems, allowing them to use more physical ram as a RAMdisk, then dropping the swap file right in there.


There are several confusing points here. A 32-bit operating system has a Virtual Memory limit of (default) 2 GB per process and this will not change no matter where you place your pagefile.

A 32-bit operating system kernel could without problem address up to 64 GB of memory using a CPU feature known as PAE, which Microsofts server line does, for exampel Win2003 and Win2008 has no problem using more than 4 GB.

(This could also be true with Windows XP, Win 7 and similar 32-bit operating systems, it is just disabled in the license from Microsoft.)

Nothing of this has to do with the pagefile placement and if needed it should be placed on a physical drive or if not needed much better to disable it. To put the swap into a RAM disk makes actually no sense to me.
m
0
l
a c 415 G Storage
June 6, 2011 7:47:10 AM

thetrivialstuff said:
It seems to me though, that if a 32-bit system can access the higher memory at *all*, then it should be able to use it normally -- how can it access it as a RAMdisk but somehow not use the same technique to just put normal memory there? They're using address extensions (or something) in there *somewhere*; seems weird that they couldn't just plug it into the main memory management system directly.
32-bit Server versions of Windows allowed application programs to call the AWE (Address Windowing Extensions) API to map more than 2GB of memory (by swapping pages into and out of the 32-bit virtual address space) on hardware that supported PAE (Physical Address Extensions). But it was only used by a few types server software such as SQL.
m
0
l
June 6, 2011 8:41:20 AM



sminlal said:
See this article: http://rickardnobel.se/archives/89[/msgquoted said:


That's quite a nice article, thanks for the link. While it's true that the "Memory" graph doesn't include the file cache, I don't think that's a real concern since Windows will simply use less RAM for caching in a memory-poor situation.]See this article: http://rickardnobel.se/archives/89


That's quite a nice article, thanks for the link. While it's true that the "Memory" graph doesn't include the file cache, I don't think that's a real concern since Windows will simply use less RAM for caching in a memory-poor situation.


Thanks, and it is correct that the amount of memory used for caching will depend on the total memory pressure, but we will still have to look out for the already going on swapping that could already taken place if we do a "load test" and starting all our applications for a worst-case-scenario. At some point of physical memory usage the disk paging will start to take place which is not clearly visible with Taskmgr only.
m
0
l
a b G Storage
June 6, 2011 6:52:25 PM

xer0 said:
Do you understand what happens to an SSD that has run out of write cycles on it's NAND? It becomes read-only memory. It doesn't simply stop working. I work in manufacturer's SSD R&D (who also makes much of the NAND used in many SSD's) and while typical "current" 25nm and 34nm MLC is rated between 3000-5000 write cycles, it is "conservatively" rated as such. Neither you or any of your friends who work with Photochop or Win Temp files are blowing through this many write cycles in a 6 month period without doing "other" much more destructive writing.

In fact it's extremely rare that any SSD has all of it's write cycles burned up. It is FAR more likely that there is a controller failure from firmware or other electrical burnouts/failures, that have nothing to do with the number of write cycle endurance left in the NAND. Even in our labs running 24x7 weeks-long full write tests, which is a thousand times more intensive than photoshop or win pagefiles, we rarely use up all the write cycles of the NAND before other failures occur. While these "other" (aka non NAND write-endurance related) failures suck when they happen, it has nothing to do with anything photoshop or win pagefiles is going to make occur faster or slower.

If your "friends" are buring out current SSD's in 6 month periods, they are either buying crappy SSD's, doing odd things to the SSD's, or simply have failures they are blaming erroneously on NAND write cycle limitations. Don't get me wrong, SSD's will fail, but unfortunately, very rarely will the failure be from write cycle endurance life of the NAND, and definately not because the SSD is used with photshop scrathdisks or win pagefiles.

To use a unpopular automotive analogy, the NAND write cycle life is like the engine of a car that is used where they use salt on the roads to melt ice. While it is possible for the engine to die from being used too much, it is much more likely the body of the car is going to rust/rot away before the engine has outlived it's useful life. And this car does not care if photoshop or win temp files are in the passenger seat. If the SSD fails under 2-3 years of normal use, it won't be because of photoshop or win pagefiles using up the NAND write cycles.

Don't shoot the messenger. I'm just telling you what happened, do with it what you will. FYI, their SSDs are intel, and they quit failing since the scratch disks were switched to a HDD RAID 0 array.
m
0
l
June 7, 2011 12:13:25 PM

LordConrad said:
Don't shoot the messenger. I'm just telling you what happened, do with it what you will. FYI, their SSDs are intel, and they quit failing since the scratch disks were switched to a HDD RAID 0 array.


The difference is that you as a "messenger" spout this same nonsense about pagefiles and scratchdisks in different threads while you attempt to speak under the guise of some sort of knowledgeable authority.
m
0
l
June 9, 2011 3:55:21 PM

(Thought I would post this here) . Yesterday I bought a Crucial M4 (128gb) and although I don't have it yet, I've been reading articles on SSD maintenance. The issue related to the page file I found most confusing. People seem really devided on this.

Anyway, I'm also using a 300GB int. HDD next to the SSD, and 4GB of memory. I'm not really using photo and/or video editing software, just normal applications and games. Still, with only 4GB I'd definitely need a pagefile. So what is the best solution, put it on a SSD, HDD, create a seperate partition..? I'm tending more towards the HDD solution since I hardly see myself cross 60% RAM usage. BTW, I can always upgrade to 8GB ram but for now I feel 4GB is enough.
m
0
l
a c 415 G Storage
June 9, 2011 5:03:45 PM

A big reason why the location of Photoshop's scratch files may not make a difference is because of Windows 7's ability to cache file reads and writes. Writes to the drive appear to finish immediately because the data is cached in RAM, and reads to the same data are also immediate if it hasn't been flushed out of RAM yet. The writes are still actually done to the drive so that Windows can read them back again if the file cache gets flushed - but the program doesn't have to wait for the writes to complete.

Most modern systems have plenty of RAM, so the net effect is that if you're not doing work that's heavy enough to flush the cached copy of the scratch file, the I/O speed of the disk is irrelevant. But if you're short on RAM or if the work you're doing in Photoshop generates enough scratch file activity to exceed the RAM available for caching, then scratch file placement will make a difference.
m
0
l
June 9, 2011 6:14:58 PM

Quote:
Regardless of how much memory you have, photoshop can and does write hundreds of MB to Gigabytes to its scratch disk during a session. As soon as you exit Photoshop, that gets deleted. I imagine if you are a heavy photoshop user this could reduce the lifetime of your drive.

I also found that putting the scratch on an SSD or even RAMdisk didn't really improve performance. So I have moved my scratch off of the SSD, though I still use the SSD for Photoshop ACR and Bridge caches, which does improve performance, and is more persistent than scratch.


While photoshop scratch and windows page files "will" reduce the life of an SSD, so will any other writes. It's all about degree. The original claim was photoshop and pagefiles made SSD's fail in 6 months, which is pure BS. Now if someone claimed that instead of 5 years of normal usage, they only got 4 years because of heavy photoshop usage, that "might" be legitimate (of course the photoshop user would have to work 7x24 for those four years, but that's besides the point), however to imply an SSD will fail from lack of write endurance in 6 months simply because of photoshop is pure balogne..

An SSD might fail for lots of reason in 6 months, but it isn't going to fail from lack of write endurance, unless someone is running write benchmarks all day, every day, which is not normal usage.
m
0
l
a c 415 G Storage
June 9, 2011 6:41:03 PM

Quote:
Then I switch scratch to a RAMdisk or SSD and do this and the operation takes just as long.
This is a pretty solid indication that Photoshop is not waiting for the scratch file writes.
m
0
l
June 9, 2011 7:47:55 PM

xer0 said:
[...]
An SSD might fail for lots of reason in 6 months, but it isn't going to fail from lack of write endurance, unless someone is running write benchmarks all day, every day, which is not normal usage.


Is it really still possible to exhaust the write cycles on an SSD in that amount of time? I was under the impression (from articles like http://www.storagesearch.com/ssdmyths-endurance.html) that write endurance was in the high hundreds of thousands or millions of cycles nowadays, and pretty much irrelevant.

Is that only for super-expensive SDD's?

~Felix.
m
0
l
a c 415 G Storage
June 9, 2011 8:18:00 PM

Let's try scrawling some figures on a napkin here... The write limit for flash memory cells is something like 10,000 erase cycles. That means if you completely overwrite the entire drive 10,000 times, you'll wear it out.

For a 60GB SSD with a write transfer rate of 100MByte/sec, it takes 10 minutes to completely overwrite the entire drive once. To overwrite the drive 10,000 times would require about 70 days.

So yes, it is possible to wear out the drive in that amount of time, but you'd have to be abusing it pretty badly.
m
0
l
June 9, 2011 9:27:32 PM

So who of you is having the pagefile on the SSD? I'm receiving one shortly, and I'm wondering what would be best.
m
0
l
June 10, 2011 1:40:45 AM

Quote:
They are more like 3000 cycles now at 25 nm SSDs so how about less than a month.



Yes, it's easy to wear out a small SSD if you want to and work at it, however not with "Photoshop" and Win7 pagefiles, which was the entire point. Photoshop isn't churning scratchfiles over and over at 100MB/sec no matter how hard you work photoshop. While Win pagefiles might be constant, they are tiny. Like I said, yes you can burn out an SSD write cycles if you intend to, but you aint going to do it with photoshop or win pagefiles in 6 months.
m
0
l
a b G Storage
June 10, 2011 5:41:21 PM

xer0 said:
The difference is that you as a "messenger" spout this same nonsense about pagefiles and scratchdisks in different threads while you attempt to speak under the guise of some sort of knowledgeable authority.


How can it be a guise of knowledge when I've seen proof? As I stated in my earlier post: "FYI, their SSDs are intel, and they quit failing since the scratch disks were switched to a HDD RAID 0 array." Just because you don't believe it doesn't mean it didn't happen.
m
0
l
June 10, 2011 9:53:11 PM

Quote:
You may be right, but it is a big hog on scratchdisk. I have it configured for 5.5 GB of RAM. I open a 10 Mp RAW image. I create a luminosity layer. I convert it to a smart object. I apply smart sharpening. CS5 wrote 1.6 GB to scratch. That took me around 15-20 seconds to do. That is a lot of scratch for just 3 operations :D  I expect it might push you into write throttling mode.

Now I am wondering. Is Photshop actually writing that much data to disk or just reserving most of it? I had just monitored the scratch file size, which grew, but doesn't necessarily mean it was being written to commensurate with the file growth. I think that would explain a lot. I will post here once I figure this out, but I am in no hurry.


Let's pretend the PS actually re-writes every bit of the scratch files, versus simply reserving space and only using portions of it.

Now let's use a typical 128GB M4 SSD as an example. The M4 128GB is "conservatively" rated by Micron to be able to support 72TB of writes over it's life.

Now breaking this down to numbers:
Using your numbers, if you repeated the exact operation you performed an actual 1.6GB complete write every 20 seconds for 24 hours straight, you'd write 6.9TB to the drive (86.4Ksec / 20sec * 1.6GB). Doing this 7 x 24 would mean the drive would take about 10.4 days to run out of write cycles (72TB / 6.9TB).


As to LordConrad above: If the photoshop users you know are using little SSD's, filling it up near full with applications, OS and whatnot, and then using what little space remains on the SSD for the scratchdisk, then I'll contend that they can have drive issues, as SSD's are not meant to be used in this manner. If they are using the SSD for scratchdisk use only as I understand your contention, then they should not be having these 6 month dying issues.
If you did this particular operation every 20 secs for 8 hours straight (typical work day), you'd write 1.4TB per day, which means the drive would run out of writes in 51 days (7.3 weeks, and not taking any weekends off) (72TB / 1.4TB).

Now break it down so you only do this type of operation only once per minute, but still over and over 8 hours per day, and the drive gets 768GB written to it per day (8hrs*60min*1.6GB), and the drive is up to 94 days (13.4) weeks) life (72TB / 0.768TB).

Now break it down to doing this particular operation once every 5 minutes 8 hours a day, and the drive gets 153.6GB written to it per day (((8hrs * 60min)/5min)*1.6GB). The drive is up to 468 days (66 weeks) write-cycle life (72TB / 0.1536TB.

Add in "weekends", breaks, lunches, reading e-mails, browsing porn, general human laziness, etc, etc and the numbers don't add up to wearing out the write cycles from simply Photoshop use within a 6 month time frame.

So yes, you could wear out the write cycles on a 128GB SSD with photoshop, but you'd have to be a inhuman working-machine, working non-stop to do it. Change the the SSD to a 256GB model and the life numbers double. Change it to an SSD using 34nm NAND (instead of 25nm)and the life numbers go up near double again.

And that's assuming Photoshop actually is writing that much versus simply reserving space.

Yes, these are theoretical numbers, but that's all we have to work with. Like I mentioned previously, SSD's will much more likely fail from firmware, or other hardware issues before you run out of write cycles in real-world usage.

As to LordCornrad's post, if your photoshop users are filling a smaller SSD near full with application, OS, etc and simply using what little space remains for scratchfile/pagefile purposes, then yes I'll concede that the will have SSD issues as they are not meant to be used in that manner. If your contention was that an SSD by itself only as a place to hold scratchfiles/pagefiles, then I stand by my statement and numbers that it's not going to wear out the SSD's write cycles in 6 months.
m
0
l
June 11, 2011 4:59:53 AM

Quote:
If your a professional using Photoshop 5x8 then it doesn't seem implausible (like you say) that someone could wear it out in 6 months like Lordconrad observed.



Anything is possible, however for the particular scenario given, highly improbable. I do have access to my company's SSD return statistics, and never do they come back in 6 months because of using up write cycles. The only time they come back with burned out write cycles is from OEM test shops or review sites who do nothing but perform burning tests and benchmarks. SSD's come back with firmware failures, electronic components/hardware failures, SATA connector failures, sabotaged drives, ran over laptop with car, you name it, but being out of NAND write cycles is not one of them (and yes we can tell what kind of write usage returned SSD'd get). Hell we even get back our drive shells with other company's broken SSD's stuffed in them; as if we wouldn't notice.

I do happen to know professional graphics artists who use Photoshop and the like. Not a one of them works anywhere near the rates indicated by the numbers needed to burn out the write cycles of a typical SSD in 6 months. Sure you can do a few particular operations that can create very large scratch files, but most user operations don't and no one that I'm aware of uses the same big-file operations hour after hour, day in and day out to match the numbers indicated. If they are truly "professionals", they have lots of RAM and CPU matched to their needs so even less writing is done to the drive. Graphic Pro's who are in it for the money, aren't doing this work with crappy hardware.

Now maybe the SSD's LordConrad's is aware of failed in 6 months, which is entirely and easily possible, however it is still "highly" unlikely it was a failure from NAND cycle burnout from any retail application run by a "human". I don't know what hardware/OS was used with the SSD's is question. There might be a a lot of reasons why the SSD's failed in 6 months, however I still contend it had nothing to do with Photoshop scratchfiles burning out all the write cycles in 6 months, especially as they were Intel SSD's. If they were SLC NAND, then the write cycles endurance is an order of magnitude even greater than MLC SSD's.

This all goes doubly for Windows pagefiles. The net affect of Win pagefiles is irrelevant to the lifespan of the SSD. Sure it has an effect, because NAND life is finite; but will it be noticeable to the end-user? No.

m
0
l
a c 415 G Storage
June 11, 2011 3:41:49 PM

xer0 said:
Now maybe the SSD's LordConrad's is aware of failed in 6 months, which is entirely and easily possible, however it is still "highly" unlikely it was a failure from NAND cycle burnout from any retail application run by a "human".
I can easily imagine a business in the graphics industry that could push through a large enough volume of Photoshop work to do it, but I agree that it's not something to be held up as an example against SSDs in general.
m
0
l
!