<p>Scratch disks should never be external.  I'm not sure where you heard that.  External drives can be used for long term asset storage, but it is best to move assets local to work on them.</p>

<p>The point of scratch disks is to be the highest speed work area you have available to work from.  Scratch disks are used for data that needs to be moved in and out of memory quickly, so internal SSDs are the best bet.</p>

<p>The one thing you don't want to do is you don't want assets and scratch disks on the same magnetic drive because of seek time.  This isn't a concern with SSDs though, so you can generally have them on the same drive.  If you are working with very large files, then there may be a bandwidth advantage to having them on different SSDs, but in order of importance you want memory to be the fastest possible, then scratch disk, then working asset storage, then long term asset storage.</p>

<p>The point is to keep data supplied to the CPU and GPU as much as possible.</p>

CC BY-SA 3.0
2014-03-22T00:22:15.513Z
Just so I understand, are you saying that all media currently being used for a project should be on an internal drive?
Crowder
CC BY-SA 3.0
2014-03-22T00:24:52.880Z
@NathanLucy - all media should be on the fastest appropriate storage available without negatively impacting faster levels.  So if you have enough room and bandwidth to put video files on SSDs without impacting your scratch, do it.  If not, put it on the fastest thing you can without impacting scratch.  Your system will work from memory the most, followed by scratch, then from media assets.
AJ Henderson
CC BY-SA 4.0
2020-06-24T23:02:57.987Z
The "external drive" advice of yore also reflects this issue of keeping your video files off of the system drive. The OS itself will be competing for the use of this drive -- swap space, executables of the video editing and other programs that are running, etc -- and especially with OS's that weren't developed to be real-time. It was a bigger deal with physical hard drives and a bigger deal in an era when there was one internal drive: the boot drive.
Wayne
CC BY-SA 4.0
2020-06-25T19:37:12.687Z
@Wayne - I'm not sure what period had only one internal drive in any serious workstation.  Most of my earliest machines even in the early 90s had multiple HDDs to separate OS access from program data access.  Back then it was even worse to try to work from external drives as the connection speeds available were incredibly slow, the exact opposite of what you'd want for a scratch disk.
AJ Henderson
CC BY-SA 4.0
2020-06-25T21:17:13.770Z
@AJ Jenderson I mainly started video in the SCSI era, and external SCSI disk arrays were the answer.
Wayne
CC BY-SA 4.0
2020-06-26T14:27:33.470Z
@Wayne ah yeah, if you were doing SCSI, though SCSI wasn't so much "external" as it was "internal in another box."  I was a bit after SCSI but that makes more sense as to where the idea came from.  I'm still not sure why you'd have scratch on an external SCSI vs an internal array aside from maybe space in the case.  It's interesting how we kind of took a step back to firewire for a long time until finally getting to USB-C and thunderbolt that can provide a full PCI-E connection over a wire.
AJ Henderson
CC BY-SA 3.0
2014-03-21T22:14:48.573Z
2014-03-21T22:14:48.573Z
AJ Henderson
<p>I've heard that all project assets should be stored on a separate "scratch" disk for the sake of increased performance. I'm wondering if that conventional wisdom holds even when your "scratch" disk is HDD and your internal disk is SSD. (I'm aware that the cost/capacity ratio is lower for HDDs. My question concerns performance issues, not capacity.)</p>

<p>Here's how my question originated: I am experiencing lag using my mid-2012 MacBook Air (i5, 8GB RAM) to edit Final Cut Pro X. I'm wondering if re-arranging my assets would stand a change of improving performance. Here's where things are right now:</p>

<ul>
<li>The application (the *.app file for Final Cut Pro X) is on my internal SSD.</li>
<li>The library (the *.fcplibrary file) is on my thunderbolt-attached HDD.</li>
<li>The digital assets (stills and video) are on the same external HDD.</li>
</ul>

<p>My library file merely references the digital assets; I am not copying them into the resource fork. For that reason, my library file is small enough that I could store it on my local drive. The new arrangement would be:</p>

<ul>
<li>The application (the *.app file for Final Cut Pro X) is on my internal SSD.</li>
<li>The library (the *.fcplibrary file) is <em>on my internal SSD.</em></li>
<li>The digital assets (stills and video) are on the same external HDD.</li>
</ul>

<p>So, would I be breaking some law of the universe with this configuration? And where did the conventional wisdom on "scratch" disks come from, anyway? Does it still apply to SSDs? (Again, in terms of performance only please, not capacity.)</p>

<editing><hardware><final-cut-pro-x><ssd><thunderbolt>
Do internal SSDs challenge the conventional wisdom of storing digital assets on external "scratch" disks?
Crowder
# Do internal SSDs challenge the conventional wisdom of storing digital assets on external "scratch" disks?

(Asked by: username_0 on 2014-03-21)

I've heard that all project assets should be stored on a separate "scratch" disk for the sake of increased performance. I'm wondering if that conventional wisdom holds even when your "scratch" disk is HDD and your internal disk is SSD. (I'm aware that the cost/capacity ratio is lower for HDDs. My question concerns performance issues, not capacity.)

Here's how my question originated: I am experiencing lag using my mid-2012 MacBook Air (i5, 8GB RAM) to edit Final Cut Pro X. I'm wondering if re-arranging my assets would stand a change of improving performance. Here's where things are right now:

* The application (the \*.app file for Final Cut Pro X) is on my internal SSD.
* The library (the \*.fcplibrary file) is on my thunderbolt-attached HDD.
* The digital assets (stills and video) are on the same external HDD.

My library file merely references the digital assets; I am not copying them into the resource fork. For that reason, my library file is small enough that I could store it on my local drive. The new arrangement would be:

* The application (the \*.app file for Final Cut Pro X) is on my internal SSD.
* The library (the \*.fcplibrary file) is *on my internal SSD.*
* The digital assets (stills and video) are on the same external HDD.

So, would I be breaking some law of the universe with this configuration? And where did the conventional wisdom on "scratch" disks come from, anyway? Does it still apply to SSDs? (Again, in terms of performance only please, not capacity.)

**Tags:** editing, hardware, final-cut-pro-x, ssd, thunderbolt


---

## 1 answers

### Answer by username_1 on 2014-03-21. Score: 1 | Accepted answer

Scratch disks should never be external. I'm not sure where you heard that. External drives can be used for long term asset storage, but it is best to move assets local to work on them.

The point of scratch disks is to be the highest speed work area you have available to work from. Scratch disks are used for data that needs to be moved in and out of memory quickly, so internal SSDs are the best bet.

The one thing you don't want to do is you don't want assets and scratch disks on the same magnetic drive because of seek time. This isn't a concern with SSDs though, so you can generally have them on the same drive. If you are working with very large files, then there may be a bandwidth advantage to having them on different SSDs, but in order of importance you want memory to be the fastest possible, then scratch disk, then working asset storage, then long term asset storage.

The point is to keep data supplied to the CPU and GPU as much as possible.

> **Comments:**
> **username_0**: Just so I understand, are you saying that all media currently being used for a project should be on an internal drive?  
> **username_1**: @NathanLucy - all media should be on the fastest appropriate storage available without negatively impacting faster levels.  So if you have enough room and bandwidth to put video files on SSDs without impacting your scratch, do it.  If not, put it on the fastest thing you can without impacting scratch.  Your system will work from memory the most, followed by scratch, then from media assets.  
> **username_2**: The "external drive" advice of yore also reflects this issue of keeping your video files off of the system drive. The OS itself will be competing for the use of this drive -- swap space, executables of the video editing and other programs that are running, etc -- and especially with OS's that weren't developed to be real-time. It was a bigger deal with physical hard drives and a bigger deal in an era when there was one internal drive: the boot drive.  
> **username_1**: @username_2 - I'm not sure what period had only one internal drive in any serious workstation.  Most of my earliest machines even in the early 90s had multiple HDDs to separate OS access from program data access.  Back then it was even worse to try to work from external drives as the connection speeds available were incredibly slow, the exact opposite of what you'd want for a scratch disk.  
> **username_2**: @AJ Jenderson I mainly started video in the SCSI era, and external SCSI disk arrays were the answer.  
> **username_1**: @username_2 ah yeah, if you were doing SCSI, though SCSI wasn't so much "external" as it was "internal in another box."  I was a bit after SCSI but that makes more sense as to where the idea came from.  I'm still not sure why you'd have scratch on an external SCSI vs an internal array aside from maybe space in the case.  It's interesting how we kind of took a step back to firewire for a long time until finally getting to USB-C and thunderbolt that can provide a full PCI-E connection over a wire.  

---

