Scratch Disk Question

Hunt wrote:

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch Disk for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.
Any thoughts on this?

Hunt

Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

g-w

In article <Dt0Ec.155732$>,
g-w wrote:

[…]
Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

Since this is a PS group it may be good to mention that CS is not limited to 2gb image files. Dunno about the scratch disc thing, but I put my scratches on larger than 2gb discs, unpartitioned and used for other files. No harm, I hope.

g-w wrote in
news:Dt0Ec.155732$:

Hunt wrote:

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch Disk for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.

Any thoughts on this?

No need. CS broke the file size limitations.

Hunt

Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

That’s a limit of FAT16, the file system. An NTFS volume can handle a file of 16 *terabytes*, and that limit will likely go up in future windows releases.

The amount of *RAM* a single app can use under Windows 32 is 2GB minus some overhead, and that will change in 64-bit Windows.

"one_of_many" wrote in message

In article <Dt0Ec.155732$>,
g-w wrote:

[…]
Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

Since this is a PS group it may be good to mention that CS is not limited to 2gb image files. Dunno about the scratch disc thing, but I put my scratches on larger than 2gb discs, unpartitioned and used for other files. No harm, I hope.

g-w’s info is about 5 years obsolete. FAT32 can handle up to 4GB files without any problem, and NTFS is practically limited by volume size. Whether or not applications take advantage of these larger file sizes is up to the application.

Rick

In article , says…

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch

Disk

for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.
Any thoughts on this?

Hunt

I located max Scratch Disk size for PS CS and it’s a whopping 64EB, or 64 billion Gigabytes! Obviously it can use more than I will ever have, especially on this laptop. However, the partitioning part of my question remains: is there anything to be gained by establishing, say 4 logical drives (all that PS CS will allow) out of the 80GB, or am I better off (or maybe just the same) by leaving the drive as one partition, i.e 1 physical/logical drive? With older versions it was better to do the partitions as you could get 4GB x 4, where 4 GB was the Scratch Disk size limitation of PS, while if you left the partitioning out, you could only get 4GB x 1. It seems that a single partition is just as good as 4, with theses extreme Scratch Disk size limits.

Hunt

yup – no matter how good the program is it needs the janitorial support of a good operating system.

Don’t pin everything on Windows XP 64-bit though.

There are rumours that it will be OEM only – which actually makes sense given the complications of arraying periferals around an operating system.

Ah – all we (me?) need is a 64-bit OS, bundles of hardware running on new drivers, PSCS non-com version (non commercial I mean), now where is my flexible friend?

das B

"Eric Gill" wrote in message

g-w wrote in
news:Dt0Ec.155732$:

Hunt wrote:

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch Disk for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.

Any thoughts on this?

No need. CS broke the file size limitations.

Hunt

Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

That’s a limit of FAT16, the file system. An NTFS volume can handle a file of 16 *terabytes*, and that limit will likely go up in future windows releases.

The amount of *RAM* a single app can use under Windows 32 is 2GB minus

some

overhead, and that will change in 64-bit Windows.

In article <Dt0Ec.155732$>,
g-w wrote:

Hunt wrote:

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch Disk for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.
Any thoughts on this?

Hunt

Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

With w2k and XP disk partitions formatted NTFS the limit is huge, 1000s of times larger than any disk you can buy today.

FAT32 had a limit of 2GB maximim file size, which no longer exists in NTFS.
—
Al Dykes
———–
adykes at p a n i x . c o m

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

—

Hecate

veni, vidi, reliqui

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

(one_of_many) wrote in news:john-2906040711310001
@m-0-20.docsis.hbci.com:

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

No, she didn’t say that. A single scratch file on a SCSI U320 3-15K disc RAID setup would be *lots* faster than a single big, slow run-of-the-mill mechanism, since all three spindles are used concurrently.

The subject at hand was partitions, and in particular on a single disc. It makes no sense to place multiple scratch files on multiple partitions on a single spindle since the 4GB limit was broken.

In article ,
stafford.net says…

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

So far, this is where I am with the Scratch Disk debate:
1.) a second (or whatever) physical drive is better than a single physical
drive. The OS and PS are located on the first physical (boot in most cases) drive and the additional physical drive contains the scratch disk.
2.) the upper limit of Scratch Disk usage by PS CS is 64EB (exabytes = 1
billion GB’s.
3.) in past versions of PS, the Scratch Disk was best partitioned into a least four logical drives, i.e D:\, E:\, F:\, G:\, etc. but that was when 4GB was the largest amount of Scratch Disk space that PS could use. An ideal configuration then was 4 x 4GB with any leftover going to other types of storage.
4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Hunt

PS, now I just need to get one of those new 64EB drives!

:

4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Dead on.

PS, now I just need to get one of those new 64EB drives!

You mean at least three for a nice striped RAID setup, right?

In article wrote:

In article ,
stafford.net says…

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

So far, this is where I am with the Scratch Disk debate:
1.) a second (or whatever) physical drive is better than a single physical
drive. The OS and PS are located on the first physical (boot in most cases) drive and the additional physical drive contains the scratch disk.
2.) the upper limit of Scratch Disk usage by PS CS is 64EB (exabytes = 1
billion GB’s.
3.) in past versions of PS, the Scratch Disk was best partitioned into a least four logical drives, i.e D:\, E:\, F:\, G:\, etc. but that was when 4GB was the largest amount of Scratch Disk space that PS could use. An ideal configuration then was 4 x 4GB with any leftover going to other types of storage.
4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

PS, now I just need to get one of those new 64EB drives!

OT: Google "petabyte" (1,024 terabytes).

There are companies (and governments) that are beginning to operate disk farms in the hundreds of terrabytes. IBM has a research project underway to use part of the unused disk space on all the desktop PCs in a large company as centrally managed storage pool, with any given piece of data replicated across lots of disks for speed/reliability and cached so when a user requests some data it comes from a computer close to him. Lets see; 1,000 PC times 10GB is 10TB, raw space. Almost free.

—
Al Dykes
———–
adykes at p a n i x . c o m

In article ,
com says…

:

4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Dead on.

PS, now I just need to get one of those new 64EB drives!

You mean at least three for a nice striped RAID setup, right?

Yes!!! Maybe I’ll try e-Bay <G>.

In article wrote:

In article ,
com says…

:

4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Dead on.

PS, now I just need to get one of those new 64EB drives!

You mean at least three for a nice striped RAID setup, right?

Yes!!! Maybe I’ll try e-Bay <G>.

Your (and my) tax money has probably already purchased a couple of these in the name of Homeland Security/

There is work in the labs that shows we can increase the data per square inch by a couple more orders of magnitude over today’s disks. The bottleneck becomes the interface speed. And it won’t be cheap unless a mass-market develops. Home audio won’t do it. We’ve all gotta want to store our HDTV/DVD video collections online. Or a multilayer PSD of every crappy frame each of us has ever snapped.

—
Al Dykes
———–
adykes at p a n i x . c o m

On Tue, 29 Jun 2004 07:11:31 -0500,
(one_of_many) wrote:

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

Nope. But you have to realise that the hard disk you install is, ion fact, usually 3-4 platters. What I am saying is that if you install that *0ne* hard disk it makes no sense to partition it if you’re going to use it solely a Photoshop’s scratch disk.

OTOH, if you have a multidisk set up, then that’s different. RAID 0, for example, suing 2 identical disks will show you what looks like a single disk but is in fact two with reading/writing occurring simultaneously. You don’t make the "partition" but it’s there all the same.

—

Hecate

veni, vidi, reliqui

On Tue, 29 Jun 2004 14:22:37 GMT, Eric Gill
wrote:

(one_of_many) wrote in news:john-2906040711310001
@m-0-20.docsis.hbci.com:

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

No, she didn’t say that. A single scratch file on a SCSI U320 3-15K disc RAID setup would be *lots* faster than a single big, slow run-of-the-mill mechanism, since all three spindles are used concurrently.
The subject at hand was partitions, and in particular on a single disc. It makes no sense to place multiple scratch files on multiple partitions on a single spindle since the 4GB limit was broken.

I just said much the same thing. Should have read your post first. 😉

—

Hecate

veni, vidi, reliqui

On 29 Jun 2004 14:59:35 -0400, (Al Dykes) wrote:

Your (and my) tax money has probably already purchased a couple of these in the name of Homeland Security/

There is work in the labs that shows we can increase the data per square inch by a couple more orders of magnitude over today’s disks. The bottleneck becomes the interface speed. And it won’t be cheap unless a mass-market develops. Home audio won’t do it. We’ve all gotta want to store our HDTV/DVD video collections online. Or a multilayer PSD of every crappy frame each of us has ever snapped.

New out in the next 18 months at roughly $20k a pop – a 1tb holographic storage disk measuring 1 inch cube. Was just reading the article about it next month. They reckon 5 years before they’ll be having workable sensibly priced drives, but they should be about 5Tb. 😉

—

Hecate

veni, vidi, reliqui

In article , Hecate wrote:

On Tue, 29 Jun 2004 07:11:31 -0500,
(one_of_many) wrote:

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

Nope. But you have to realise that the hard disk you install is, ion fact, usually 3-4 platters. What I am saying is that if you install that *0ne* hard disk it makes no sense to partition it if you’re going to use it solely a Photoshop’s scratch disk.

Uh, yeah. I know that a disc has a few platters. I was just checking to be sure someone wasn’t saying more spindles were not a good thing.

OTOH, if you have a multidisk set up, then that’s different. RAID 0, for example, suing 2 identical disks will show you what looks like a single disk but is in fact two with reading/writing occurring simultaneously. You don’t make the "partition" but it’s there all the same.

Not sure a RAID is going to be any better than the same number of separate spindles – overlap seeks are a good thing to make up for latency.

(one_of_many) wrote in
news::

Not sure a RAID is going to be any better than the same number of separate spindles – overlap seeks are a good thing to make up for latency.

Photoshop doesn’t do overlap seeks by itself, bud. You won’t use more than one scratch file unless you fill the first to capacity.

OTOH, RAID does concurrent read/write/seek with whatever application you use.

On Mon, 28 Jun 2004 21:55:47 GMT, g-w wrote:

Hunt wrote:

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch Disk for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.
Any thoughts on this?

Hunt

Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

Win NT and descendants (W2k, XP) can handle files as large as your available diskspace.

Michael

On Mon, 28 Jun 2004 22:38:42 GMT, Eric Gill
wrote:

g-w wrote in
news:Dt0Ec.155732$:

Hunt wrote:

I’m adding a separate 80GB HDD to my laptop, mainly to act as the Scratch Disk for PS CS. In older versions, PS had a limitation on the size of partition ( logical drive) that PS could use, and up through v6 this was 4GBx4. I can’t find data on CS’s Scratch Disk usage, and wonder if I need to do a partitioning of the new drive to make PS CS most comfortable.

Any thoughts on this?

No need. CS broke the file size limitations.

Hunt

Probably did not change, the largest file Windows and any windows app can use is 2GB last I knew. That win 95 and up limit will not change until 64-bit Windows.

That’s a limit of FAT16, the file system. An NTFS volume can handle a file of 16 *terabytes*, and that limit will likely go up in future windows releases.

The amount of *RAM* a single app can use under Windows 32 is 2GB minus some overhead, and that will change in 64-bit Windows.

The 2GB limit is the adress space limit of a single process. Not the limit for the system.

If an application consists of several processes, each process can use its own 2GB (minus something) address space.

This is also fine if you have multiple processors.

Michael

On 29 Jun 2004 14:31:49 GMT, (Hunt) wrote:

In article ,
stafford.net says…

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

So far, this is where I am with the Scratch Disk debate:
1.) a second (or whatever) physical drive is better than a single physical
drive. The OS and PS are located on the first physical (boot in most cases) drive and the additional physical drive contains the scratch disk.
2.) the upper limit of Scratch Disk usage by PS CS is 64EB (exabytes = 1
billion GB’s.
3.) in past versions of PS, the Scratch Disk was best partitioned into a least four logical drives, i.e D:\, E:\, F:\, G:\, etc. but that was when 4GB was the largest amount of Scratch Disk space that PS could use. An ideal configuration then was 4 x 4GB with any leftover going to other types of storage.
4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Except to avoid sharing a partition for lots of files and your scratch space – avoid fragmentation.

Another reason would be to make sure your scratch files are in the fastest part of the disk, that is, the area that is covered by the first partition.

So creating a 16 or 20 GB partition for the scratch files and a second partition for other data would make sense.

Michael

Hunt

PS, now I just need to get one of those new 64EB drives!

In article , Eric Gill
wrote:

(one_of_many) wrote in
news::

Not sure a RAID is going to be any better than the same number of separate spindles – overlap seeks are a good thing to make up for latency.

Photoshop doesn’t do overlap seeks by itself, bud. You won’t use more than one scratch file unless you fill the first to capacity.

Now, Eric. Hold on here. I understand the OS subsystem is responsible for disc access at that level (overlap seeks/write), but are you _certain_ that CS doesn’t use concurrent scratch files? If I specify three, does it really wait until one is full before using the other?

OTOH, RAID does concurrent read/write/seek with whatever application you use.

Huh? It would be harder to keep a subsystem from doing overlap seeks than not.

In article ,
says…

On Tue, 29 Jun 2004 07:11:31 -0500,
(one_of_many) wrote:

In article , Hecate wrote:

On 28 Jun 2004 23:01:44 GMT, (Hunt) wrote:

It seems that a single partition
is just as good as 4, with theses extreme Scratch Disk size limits.

Absolutely 🙂

Just to be sure – are you saying that for scratch-devices one large disc is as good as multiple discs (spindles)?

Nope. But you have to realise that the hard disk you install is, ion fact, usually 3-4 platters. What I am saying is that if you install that *0ne* hard disk it makes no sense to partition it if you’re going to use it solely a Photoshop’s scratch disk.

OTOH, if you have a multidisk set up, then that’s different. RAID 0, for example, suing 2 identical disks will show you what looks like a single disk but is in fact two with reading/writing occurring simultaneously. You don’t make the "partition" but it’s there all the same.

—

Hecate

veni, vidi, reliqui

In the specific case, my Toshiba P25, I only have room for one additional physical HDD, which has to replace the battery and preculudes its use, except when tethered to the AC. My #2 workstation has RAID 0 on two 250GB HDD’s and that functions nicely. To get the additional physical Scratch Disk there, I added another un-striped 250GB. With HHD costs coming down, I may add another and strip it to the third (now un-striped) 250. Only concern is whether I need to add another RAID controller, or whether mine can handle 4 HDD’s in two RAID arrays.

Thanks for the feedback,
Hunt

(one_of_many) wrote in
news::

In article , Eric Gill
wrote:

(one_of_many) wrote in
news::

Not sure a RAID is going to be any better than the same number of separate spindles – overlap seeks are a good thing to make up for latency.

Photoshop doesn’t do overlap seeks by itself, bud. You won’t use more than one scratch file unless you fill the first to capacity.

Now, Eric. Hold on here. I understand the OS subsystem is responsible for disc access at that level (overlap seeks/write), but are you _certain_ that CS doesn’t use concurrent scratch files?

Unqualified yes. It isn’t some sort of soft RAID system.

If I specify
three, does it really wait until one is full before using the other?

OTOH, RAID does concurrent read/write/seek with whatever application you use.

Huh? It would be harder to keep a subsystem from doing overlap seeks than not.

What?!?

In article , Eric Gill
wrote:

(one_of_many) wrote in
news::

Now, Eric. Hold on here. I understand the OS subsystem is responsible for disc access at that level (overlap seeks/write), but are you _certain_ that CS doesn’t use concurrent scratch files?

Unqualified yes. It isn’t some sort of soft RAID system.

"Some sort" doesn’t inspire my confidence.

I have to believe we have some technical terminology misunderstanding. I’ll leave this to Chris Cox or another PS code wizard to answer. Until then, I’ll assert that it is highly unlikely that CS subverts subsystem overlap seeks/writes. That would be rather diifficult to do, to say the least. It also seems unlikely that CS waits until one scratch device is full before hitting the other(s). Distributing the writes and reads across spindles makes more sense, at least to me. Anyway, I don’t mind being corrected if I am wrong.

In article ,
(one_of_many) wrote:

In article , Eric Gill
wrote:

(one_of_many) wrote in
news::

Now, Eric. Hold on here. I understand the OS subsystem is responsible for disc access at that level (overlap seeks/write), but are you _certain_ that CS doesn’t use concurrent scratch files?

Unqualified yes. It isn’t some sort of soft RAID system.

"Some sort" doesn’t inspire my confidence.

Sorry about that comment. I read it as "IS some sort of soft RAID…"

In any event, we can put this aside for now. I just can’t see how it could be rational to somehow eliminate the subsystem that permits concurrent, overlap reads and writes to separate spindles. The disc controllers "want" to do that. Making them stupid (somehow) just seems crazy.

On Wed, 30 Jun 2004 07:46:08 -0500,
(one_of_many) wrote:

In article , Eric Gill
wrote:

(one_of_many) wrote in
news::

Not sure a RAID is going to be any better than the same number of separate spindles – overlap seeks are a good thing to make up for latency.

Photoshop doesn’t do overlap seeks by itself, bud. You won’t use more than one scratch file unless you fill the first to capacity.

Now, Eric. Hold on here. I understand the OS subsystem is responsible for disc access at that level (overlap seeks/write), but are you _certain_ that CS doesn’t use concurrent scratch files? If I specify three, does it really wait until one is full before using the other?

PS does not use the files concurrently,. It uses them in the order you have input. Which is why they are called First, Second, etc. And it doesn’t use Second until First is full.

—

Hecate

veni, vidi, reliqui

On Wed, 30 Jun 2004 12:59:19 -0500,
(one_of_many) wrote:

In article , Eric Gill
wrote:

(one_of_many) wrote in
news::

Now, Eric. Hold on here. I understand the OS subsystem is responsible for disc access at that level (overlap seeks/write), but are you _certain_ that CS doesn’t use concurrent scratch files?

Unqualified yes. It isn’t some sort of soft RAID system.

"Some sort" doesn’t inspire my confidence.

I have to believe we have some technical terminology misunderstanding. I’ll leave this to Chris Cox or another PS code wizard to answer. Until then, I’ll assert that it is highly unlikely that CS subverts subsystem overlap seeks/writes. That would be rather diifficult to do, to say the least. It also seems unlikely that CS waits until one scratch device is full before hitting the other(s). Distributing the writes and reads across spindles makes more sense, at least to me. Anyway, I don’t mind being corrected if I am wrong.

You’re wrong.

—

Hecate

veni, vidi, reliqui

On 30 Jun 2004 16:22:26 GMT, (Hunt) wrote:

In the specific case, my Toshiba P25, I only have room for one additional physical HDD, which has to replace the battery and preculudes its use, except when tethered to the AC. My #2 workstation has RAID 0 on two 250GB HDD’s and that functions nicely. To get the additional physical Scratch Disk there, I added another un-striped 250GB. With HHD costs coming down, I may add another and strip it to the third (now un-striped) 250. Only concern is whether I need to add another RAID controller, or whether mine can handle 4 HDD’s in two RAID arrays.

Thanks for the feedback,
Hunt

If you have that many disk do a RAD 0+1 set up. You get the speed advantage of RADI 0 and the safety of RAID 1.

—

Hecate

veni, vidi, reliqui

In article , Hecate wrote:

On Wed, 30 Jun 2004 12:59:19 -0500,
(one_of_many) wrote:

have to believe we have some technical terminology misunderstanding.

I’ll leave this to Chris Cox or another PS code wizard to answer. Until then, I’ll assert that it is highly unlikely that CS subverts subsystem overlap seeks/writes. That would be rather diifficult to do, to say the least. It also seems unlikely that CS waits until one scratch device is full before hitting the other(s). Distributing the writes and reads across spindles makes more sense, at least to me. Anyway, I don’t mind being corrected if I am wrong.

You’re wrong.

Okay. Could you direct me to the authoritative source of this info? Or do you know this because you can watch the file activity?

Hunt wrote:

In article ,
com says…

:

4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Dead on.

PS, now I just need to get one of those new 64EB drives!

You mean at least three for a nice striped RAID setup, right?

Yes!!! Maybe I’ll try e-Bay <G>.

One down side of RAID is that if one drive dies, you lose all the data. Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

On Wed, 30 Jun 2004 23:55:25 -0500,
(one_of_many) wrote:

In article , Hecate wrote:

On Wed, 30 Jun 2004 12:59:19 -0500,
(one_of_many) wrote:

have to believe we have some technical terminology misunderstanding.

I’ll leave this to Chris Cox or another PS code wizard to answer. Until then, I’ll assert that it is highly unlikely that CS subverts subsystem overlap seeks/writes. That would be rather diifficult to do, to say the least. It also seems unlikely that CS waits until one scratch device is full before hitting the other(s). Distributing the writes and reads across spindles makes more sense, at least to me. Anyway, I don’t mind being corrected if I am wrong.

You’re wrong.

Okay. Could you direct me to the authoritative source of this info? Or do you know this because you can watch the file activity?

Read what Adobe says about scratch disks.

—

Hecate

veni, vidi, reliqui

wrote:

One down side of RAID is that if one drive dies, you lose all the data.

That is only correct for RAID0…

Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

….but if you have RAID1 it may not be as fast but doesn’t cost anymore, just a different configuration.

Stuart

On Thu, 01 Jul 2004 12:30:33 GMT, wrote:

Hunt wrote:

In article ,
com says…

:

4.) with the extreme capability of Scratch Disk utilization, is there any reason to partition the second physical drive to be used as Scratch Disk space? Doesn’t seem that there is one, as far as I can find.

Dead on.

PS, now I just need to get one of those new 64EB drives!

You mean at least three for a nice striped RAID setup, right?

Yes!!! Maybe I’ll try e-Bay <G>.

One down side of RAID is that if one drive dies, you lose all the data. Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

That depends on your configuration. RAID-0 means no redundancy and high risk, only useful for temporary data. It’s actually RAID without
R.

Only real RAID configurations (Raid 1+0, Raid 5) can give you the benefit of multiple spindles (minus a little overhead when writing) plus the safety of redundant disks.

Michael

"Stuart" wrote in message

wrote:

One down side of RAID is that if one drive dies, you lose all the data.

That is only correct for RAID0…

Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

…but if you have RAID1 it may not be as fast but doesn’t cost anymore, just a different configuration.

The problem with RAID is that it can potentially provide a false sense of security. Yes, it does protect against drive failures, but in my experience 98% of system failures are a result of software corruption (virus attacks, bad drivers, OS or application updates etc etc). RAID doesn’t protect against any of these problems. So the best overall defense is a good backup scheme such as frequent drive imaging.

Given that, the usefulness of RAID for hardware protection is greatly diminished — if a drive fails, one can simply restore from the last image backup. But it *is* still useful for performance enhancement.

Rick

"Hecate" wrote in message

On Wed, 30 Jun 2004 23:55:25 -0500,
(one_of_many) wrote:

Read what Adobe says about scratch disks.

I did not find any _explicit_ statement such as "CS writes to one scratch file until it is full, then opens the next", but I will take your word for it. FWIW, here’s a registry edit that might be useful for strictly local image files.

Use Async Scratch Registry Key

UseAsyncScratch_OFF_D.reg
UseAsyncScratch_ON.reg

By default, Adobe Photoshop CS does not use asynchronous file handling, data transfer that doesn’t occur at predetermined or regular intervals, when writing to its virtual memory file, the scratch disk. Asyncronous I/O (Input/Output), can improve performance when acessessing the scratch disk.

Asynchronous file handling can conflict with networking software, causing damage when saving images to or opening them from a network drive.To turn this function off, use these instructions to run the
UseAsyncScratch_OFF_D.reg file.

On Fri, 2 Jul 2004 03:19:50 -0700, "Rick" wrote:

"Stuart" wrote in message

wrote:

One down side of RAID is that if one drive dies, you lose all the data.

That is only correct for RAID0…

Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

…but if you have RAID1 it may not be as fast but doesn’t cost anymore, just a different configuration.

The problem with RAID is that it can potentially provide a false sense of security. Yes, it does protect against drive failures, but in my experience 98% of system failures are a result of software corruption (virus attacks, bad drivers, OS or application updates etc etc). RAID doesn’t protect against any of these problems. So the best overall defense is a good backup scheme such as frequent drive imaging.

Given that, the usefulness of RAID for hardware protection is greatly diminished — if a drive fails, one can simply restore from the last image backup. But it *is* still useful for performance enhancement.

How long does a restore take for a 300 GB array?

RAID is to avoid restore times from hardware faults.

And, yes, you still need a backup against user errors.

BTW: There are organizations that do not allow users to delete files on network drives – deletion from the online data is only done via request to the administrators, and they keep a backup.

Michael

"Xalinai" wrote in message

On Fri, 2 Jul 2004 03:19:50 -0700, "Rick" wrote:

"Stuart" wrote in message

wrote:

One down side of RAID is that if one drive dies, you lose all the data.

That is only correct for RAID0…

Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

…but if you have RAID1 it may not be as fast but doesn’t cost anymore, just a different configuration.

The problem with RAID is that it can potentially provide a false sense of security. Yes, it does protect against drive failures, but in my experience 98% of system failures are a result of software corruption (virus attacks, bad drivers, OS or application updates etc etc). RAID doesn’t protect against any of these problems. So the best overall defense is a good backup scheme such as frequent drive imaging.

Given that, the usefulness of RAID for hardware protection is greatly diminished — if a drive fails, one can simply restore from the last image backup. But it *is* still useful for performance enhancement.

How long does a restore take for a 300 GB array?

Depends on the hardware. In many cases not much (or any) longer than it takes to rebuild one.

Rick

On Sat, 3 Jul 2004 04:39:53 -0700, "Rick" wrote:

"Xalinai" wrote in message

On Fri, 2 Jul 2004 03:19:50 -0700, "Rick" wrote:

"Stuart" wrote in message

wrote:

One down side of RAID is that if one drive dies, you lose all the data.

That is only correct for RAID0…

Unless the RAID has extra drive(s) for correction/recovery, which means more cost.

…but if you have RAID1 it may not be as fast but doesn’t cost anymore, just a different configuration.

The problem with RAID is that it can potentially provide a false sense of security. Yes, it does protect against drive failures, but in my experience 98% of system failures are a result of software corruption (virus attacks, bad drivers, OS or application updates etc etc). RAID doesn’t protect against any of these problems. So the best overall defense is a good backup scheme such as frequent drive imaging.

Given that, the usefulness of RAID for hardware protection is greatly diminished — if a drive fails, one can simply restore from the last image backup. But it *is* still useful for performance enhancement.

How long does a restore take for a 300 GB array?

Depends on the hardware. In many cases not much (or any) longer than it takes to rebuild one.

A backup of 240 GB multimedia data AIT3 tape from a NTFS partition usally takes about 3.5 hours plus the time to change the tape. Then again the same time for the verify run.

Restore takes more than twice the backup time (using NTBackup) and defragmenting the disk after restoring is thoroughly recommended.

Rebuild of the 240GB RAID5 (6 drives 60GB each, 5-disk array, one hot spare) takes 3 hours.

But: Data is available even with one bad drive and during rebuild – for read and write. People can work, be productive and earn money.

Even simple IDE to SCSI raid subsystems provide hot plugging of replacement disks or even hot spare drives that automaticly switch to a new good disk.

Having a RAID controller without hot replacement option is like a spare tire that can only be changed when you are at home.

I need the system to work – I can’t wait until some rebuild is done.

On Thu, 01 Jul 2004 04:43:55 +0100, Hecate wrote:

On 30 Jun 2004 16:22:26 GMT, (Hunt) wrote:

In the specific case, my Toshiba P25, I only have room for one additional physical HDD, which has to replace the battery and preculudes its use, except when tethered to the AC. My #2 workstation has RAID 0 on two 250GB HDD’s and that functions nicely. To get the additional physical Scratch Disk there, I added another un-striped 250GB. With HHD costs coming down, I may add another and strip it to the third (now un-striped) 250. Only concern is whether I need to add another RAID controller, or whether mine can handle 4 HDD’s in two RAID arrays.

Thanks for the feedback,
Hunt

If you have that many disk do a RAD 0+1 set up. You get the speed advantage of RADI 0 and the safety of RAID 1.

—

Hecate

veni, vidi, reliqui

Interesting article at
http://www.anandtech.com/storage/showdoc.html?i=2101
suggests that RAID 0 in the real world offers nothing like a doubling of speed more like <5% an increase which is offset by the decrease in reliability of spreading the striping the data over two disks.

The result that includes Photoshop is on page 6
http://www.anandtech.com/storage/showdoc.html?i=2101&p=6

Berenger

On Sun, 4 Jul 2004 17:46:57 +0000 (UTC), Berenger
wrote:

On Thu, 01 Jul 2004 04:43:55 +0100, Hecate wrote:

On 30 Jun 2004 16:22:26 GMT, (Hunt) wrote:

In the specific case, my Toshiba P25, I only have room for one additional physical HDD, which has to replace the battery and preculudes its use, except when tethered to the AC. My #2 workstation has RAID 0 on two 250GB HDD’s and that functions nicely. To get the additional physical Scratch Disk there, I added another un-striped 250GB. With HHD costs coming down, I may add another and strip it to the third (now un-striped) 250. Only concern is whether I need to add another RAID controller, or whether mine can handle 4 HDD’s in two RAID arrays.

Thanks for the feedback,
Hunt

If you have that many disk do a RAD 0+1 set up. You get the speed advantage of RADI 0 and the safety of RAID 1.

Interesting article at
http://www.anandtech.com/storage/showdoc.html?i=2101
suggests that RAID 0 in the real world offers nothing like a doubling of speed more like <5% an increase which is offset by the decrease in reliability of spreading the striping the data over two disks.

I only said there was a speed advantage – not how much 🙂

And that’s why I said 0+1 (or 5) is best. You get the speed advantage plus the safety.

—

Hecate

veni, vidi, reliqui