PDA

View Full Version : Startup Disk Almost Full



MysteryMonkey
09-22-2007, 11:13 PM
Startup Disk Almost Full. Make more room on your startup disk (or something to that effect)

I'm puzzled why I got this message earlier when rendering out some Quickshade frames. I was about halfway through rendering out 1530 frames of a scene containing 1,010,717 Polygons using 144.6 MB of memory when I got that message. I was rendering the individual frames to a folder on a 160 GB, USB external HD. That USB drive had in excess of 128 GB of free space on it, and BTW the startup disk had 560 MB of free space on it. I'm running Lightwave v9.2 on my IntelMac Macbook Pro that has 2 GB SDRAM installed on it. It also has OSX 10.4.10 installed.

Now that I've quit and restarted my render session(s) a couple of times I discover that once completed the frames themselves only take up 156.3 MB of disk space.

So does anyone know what the deal is? Why did I get that message about my startup disk being full? Why would that even matter when I am not saving my files to the startup disk anyway? It was easy enough to take care of this time, but if I wasn't around to correct the situation would it have finished rendering or stopped?

I'm just puzzled why that came up?

M. Monkey

brian.coates
09-23-2007, 12:14 AM
I'm no expert but I believe OSX uses the same amount of virtual memory on your startup disk as you have installed as RAM, something to do with the fact that OSX is based on Unix. In other words the actual free space on your startup disk is 560Mb + 2Gb, but you never see that extra 2Gb because the system allocates it as VM at startup.

It sounds like LW is taking up extra memory as it renders, gradually chewing into the 560Mb which is giving you the 'disk full' error.

An immediate solution is to clear out cache folders and other temporary stuff on your HD to free up disk space, (try Cocktail (http://www.maintain.se/cocktail/index.php) to automate the process).

You could also try switching to the 9.3 Universal Binary version of LW which I'm told has much better memory management and faster render speeds on Intel machines.

Hope that helps.

dsol
09-23-2007, 04:58 AM
Unfortunately, OSX doesn't give you - the user - any options to change the device you use as a scratch disk for VM. There are some hacky 3rd party utils out there to do it though:

http://www.ehmac.ca/mac-ipod-help-troubleshooting/39804-change-vm-location-osx-10-3-a.html

Otherwise you'll just have to shift some files off from your startup disk and free up a few gigs.

avkills
09-23-2007, 06:59 AM
Unfortunately, OSX doesn't give you - the user - any options to change the device you use as a scratch disk for VM. There are some hacky 3rd party utils out there to do it though:

http://www.ehmac.ca/mac-ipod-help-troubleshooting/39804-change-vm-location-osx-10-3-a.html

Otherwise you'll just have to shift some files off from your startup disk and free up a few gigs.

You can change it via unix and the shell, which really isn't a hack; but yes it would a lot nicer if the OS X install allowed you to make a scratch partition during the install process.

-mark

MysteryMonkey
09-23-2007, 07:27 AM
You can change it via unix and the shell, which really isn't a hack; but yes it would a lot nicer if the OS X install allowed you to make a scratch partition during the install process...-mark

Well it is just irritating. I do have a Scratch Disk partition that was made for PhotoShop & Illustrator usage. Within both of those applications I can designate that part of the HD to use when/if virtual memory is ever needed. It would be nice if I could also do that with ALL my applications. But what is really irritating is that given the 2 GB of RAM I have installed, and the memory usage numbers I listed above I shouldn't even need virtual memory.

MysteryMonkey
09-23-2007, 08:27 AM
Thanks for your replies folks.

M. Monkey

mlinde
09-24-2007, 09:12 AM
You can change it via unix and the shell, which really isn't a hack; but yes it would a lot nicer if the OS X install allowed you to make a scratch partition during the install process.

-mark
Why?

The only reason I can think of to have multiple partitions on a single disk is booting to multiple OS's. There is no logical benefit to a separate partition on a single internal drive as a "scratch" partition.

Having a separate physical scratch disk for things like Photoshop/After Effects/FCP and such makes sense as much as having a separate "projects" disk. Having a separate partition on the same disk doesn't. The point of a separate scratch disk is speed more than capacity. I know you can buy a 750GB HDD as your sole internal drive, and repartition it to pretend you have multiple drives, but you don't get any benefit with that.

MysteryMonkey
09-24-2007, 10:14 AM
Why? . . . There is no logical benefit to a separate partition on a single internal drive as a "scratch" partition.

Having a separate physical scratch disk for things like Photoshop/After Effects/FCP and such makes sense as much as having a separate "projects" disk. Having a separate partition on the same disk doesn't. The point of a separate scratch disk is speed more than capacity. I know you can buy a 750GB HDD as your sole internal drive, and repartition it to pretend you have multiple drives, but you don't get any benefit with that.

Perhaps you should say you don't understand why there is a logical benefit to having a scratch disk partition instead of saying, "There is no logical benefit" to doing it that way.

You might first ask why does Adobe make Photoshop and Illustrator so the programs can specify a scratch disk? It has to do with the speed of performance of using a space where no permanent files have been written and or deleted, or using a space where there is an expanse of blank disk space. A specified scratch disk is never used to save files, thus it always operates at peak performance when acting as virtual memory. Do you ever defrag a drive? Do you know why you do that? It is to have uninterrupted space which improves the performance of your computer.

brunopeixoto
09-24-2007, 11:49 AM
I've been giving support for Macs since 2002, and the most concurrent problems involves HD's! Give a try: get a brand new installed OS X on a HD formatted with zero out data, upgrade the OS, install your software and then run DiskWarrior... You will see some problems. Using the same partition to store the OS, Scratch and files results in fragmentation and directory corruption! Ok, with journaling turned on these problems are not so severe.
In your HD it's stored a file called VIB (volume information block (?)), that tells to your HD and OS how much space are free. If it's corrupted you will get less or more space than the actual true space free. Other tip: in Activity monitor you can see how much disk space it's used for VM (overall and for each process - attache image). I have 4 GB of RAM and 9GB for VM!
Remeber that Photoshop and other apps also use scratch space in their own way (aside OS X VM). Garageband, iDVD, iMovie and other apps have libraries that use large amounts of disk space. Check your trash (files in the trash are not deletd).

mlinde
09-24-2007, 01:00 PM
Perhaps you should say you don't understand why there is a logical benefit to having a scratch disk partition instead of saying, "There is no logical benefit" to doing it that way.

You might first ask why does Adobe make Photoshop and Illustrator so the programs can specify a scratch disk? It has to do with the speed of performance of using a space where no permanent files have been written and or deleted, or using a space where there is an expanse of blank disk space. A specified scratch disk is never used to save files, thus it always operates at peak performance when acting as virtual memory. Do you ever defrag a drive? Do you know why you do that? It is to have uninterrupted space which improves the performance of your computer.

Hm. Without belaboring the point, I've been in the digital media industry in both production and support for 15 years. I simply believe there is no logical benefit to a scratch partition on the same physical drive. I understand why there are scratch disks. Applications utilize scratch disks because they generate large volumes of temporary content. The reason Photoshop allows you to specify that scratch disk is that when you have a separate physical device, you may see speed improvements once you begin utilizing the scratch disk on large files.

The logic of a separate partition on the same drive does not apply. That drive already has to spin when reading application data, user data, and system files. A separate partition doesn't eliminate that action - it is simply additional read time on the same drive. In addition, as the separate partition is a secondary logical section of the drive, it is a "slower" section of the same disk, since partitions are usually written in large, contiguous spaces.

And no, I don't defrag drives anymore. Modern disks, disk I/O, and memory capacities eliminate the need for defragmentation - with one exception. If you use a scratch disk for large audio or video and you do not erase it completely between projects, you can experience degredation without defragmentation. So, the only real reason to defragment a disk is if you are working on large, long-form audio or video files, which often require contiguous space to maintain appropriate throughput.

MysteryMonkey
09-24-2007, 04:28 PM
Hm. Without belaboring the point, I've been in the digital media industry in both production and support for 15 years. I simply believe there is no logical benefit to a scratch partition on the same physical drive.

Whether or not you believe there are any logical benefits for having a partioned scratch disk there are thousands of Mac PhotoShop users that have seen the benefit of doing it that way. I guess I'm supposed to take your word as from on high since you've been in the industry for "15 years." All I can say in response to that is that some of us learn faster than others or learn from better sources than others. I learned my scratch disk trick from a man that was a beta tester for PhotoShop before it was even called PhotoShop. There are plenty of websites out there to explain why. I'm not going to try to convince you the method I use is logical, or even useful. What's the point of wasting my time? If you want to know more do a Google search and you'll find plenty of references as to the virtues of setting up a scratch disk partition.

dsol
09-24-2007, 05:06 PM
So, the only real reason to defragment a disk is if you are working on large, long-form audio or video files, which often require contiguous space to maintain appropriate throughput.

Or are using a program that generates large single cache files while you work. Like, um... Photoshop?

It's certainly true that OSX and NT don't suffer from fragmentation as much as earlier OS's. But having a clean (and crucially - smaller) partition available for fast scratch operations can confer a speed advantage. You can optimise the cluster size on that partition for speed rather than minimum filesize.

And also - if there's a hardware failure while writing to that partition, there's far less danger of corruption of the data on that drive in the other partitions. It is a physical thing after all - not just a software veneer put on by the OS ;)

brunopeixoto
09-24-2007, 05:42 PM
Whether or not you believe there are any logical benefits for having a partioned scratch disk there are thousands of Mac PhotoShop users that have seen the benefit of doing it that way. I guess I'm supposed to take your word as from on high since you've been in the industry for "15 years." All I can say in response to that is that some of us learn faster than others or learn from better sources than others. I learned my scratch disk trick from a man that was a beta tester for PhotoShop before it was even called PhotoShop. There are plenty of websites out there to explain why. I'm not going to try to convince you the method I use is logical, or even useful. What's the point of wasting my time? If you want to know more do a Google search and you'll find plenty of references as to the virtues of setting up a scratch disk partition.

Looks like you can read minds...
:agree:

mlinde
09-25-2007, 12:59 PM
dsol - could you please explain how a separate partition on the same physical disk would save you in the event of a hardware failure?

MysteryMonkey - I'm not saying there isn't a benefit to a separate physical scratch disk. I'm saying there isn't a benefit to a separate partition on the same physical disk. I've been a Photoshop user that entire 15 years - and although I have used scratch disks I have not used scratch partitions since I had access to computers that could have more than one HD installed, either internal or external. And my point (to make this clear, as you seem to have missed it) is that a separate partition on the boot drive has no benefit. I guess I should have qualified that with "has no benefit if you have free space available on your one and only hard drive"

If you are saying that the only way you can have free space available is to set aside a separate partition on the one and only drive you own, then you are absolutely correct - a separate scratch partition is the way for you to go. If, however, you have more than one hard drive connected to your computer, the "way to go" is to have a separate, dedicated scratch disk, ideally multiple physical disks in a RAID0 configuration. I will stand by that statment, and you can ask your
man that was a beta tester for PhotoShop before it was even called PhotoShop and I'm willing to bet that he would agree - a separate physical scratch disk is the way to go.

MysteryMonkey
09-25-2007, 02:22 PM
. . . MysteryMonkey . . . I'm saying there isn't a benefit to a separate partition on the same physical disk. I've been a Photoshop user that entire 15 years . . . If you are saying that the only way you can have free space available is to set aside a separate partition on the one and only drive you own, then you are absolutely correct - a separate scratch partition is the way for you to go. . .

You know all of that sounds a whole lot different than


. . . There is no logical benefit to have a separate partition on a single internal drive as a "scratch" partition.

So i guess there is a logical reason for me to do it the way I've been doing it (and will continue to do it) afterall. See now wouldn't it have been much easier to just say what you meant in the first place. It really doesn't matter to me if you've been doing it for 15 years or not. Just because someone has been doing something for 15 year doesn't necessarily make them an authority on anything. Especially when they make a bold statement that I know is wrong.

MysteryMonkey
09-25-2007, 03:50 PM
. . . And my point (to make this clear, as you seem to have missed it) is that a separate partition on the boot drive has no benefit. I guess I should have qualified that with "has no benefit if you have free space available on your one and only hard drive"

You know rereading your post it seems apparent to me that you really do not comprehend the benefit of a scratch disk on the startup disk EVEN if there is free space available on the one and only hard drive. Geez, it is such a simple concept. Free space on a fragmented section of a hard drive is not efficient in anyway. However a scratch disk on that very same hard drive NEVER becomes fragmented because the space is only ever used for temp files. Thus it operates at peek efficiency.

It isn't necessarily the best solution, but it is a logical and useful means to an end.

gatz
09-25-2007, 04:26 PM
I agree it's useful have a dedicated scratch partition. Easier to keep clean and fragment free. The problem with redirecting the scratch disk for OSX is that even if you make the new vm assignment the boot disk still requires atleast 5BG to burn a DVD. I gave up redirecting the vm temp because it had to be reset after ever system upgrade. I just got tired of monkeying around in terminal. The problem is that not only does Apple not allow the scratch disk to be (easily) reassigned. But they insist on every app and the support files be installed on the boot drive. The FinalCut suite and Logic (which nows comes with the Jams library) with eat hundreds of gigs.

rg

brunopeixoto
09-25-2007, 05:04 PM
I am so tired of ignorance. Some great people try to share the knowledge they acquire and some time later a battle start to see who is the best, who is right, who knows more, etc.

Ok, to understand what we are saing, ok.

I remember that in any war everybody looses, including winners...

I am stupid, I know nothing, I am wrong, I am guilt of everything...

Peace.

MysteryMonkey
09-25-2007, 09:43 PM
I agree it's useful have a dedicated scratch partition. Easier to keep clean and fragment free. . . rg

Well now back on topic . . . I have to wonder if Lightwave could be written so the user could assign a primary and secondary scratch disk to use when rendering out frames? I assume that many Lightwave users also dabble with PhotoShop and probably have a designated scratch disk partition (or drive) so why not put that to use when working with LW too?

jwiede
09-25-2007, 09:45 PM
Thus it operates at peek efficiency.

Well, except for all those times it needs to relocate the heads back to the other partition to do operations with the non-scratch partition, which turns out to be a rather common activity. Oh, and that you're blowing out the on-disk cache for the physical disk with big accesses no matter what, which impacts all OS & application threads which were accessing the storage system. And then there's the performance cost of maintaining separate partition journaling structures while the storage system interleaves transactions across both partitions. And so on. Frankly, your definition of "peak efficiency" is a bit...unfounded.

Things have changed much since the MacOS 9 days in terms of what happens when any given application accesses storage, and modern multithreaded OS storage systems do vastly more caching and traffic management and aggregation of application accesses. What you described was true when applications (or the VM subsystem) were essential "exclusive users" of storage at any given moment, but the storage access picture has changed very substantially since then in MacOS X. Larger on-disk caches and on-disk traffic management firmware further alter traffic access, and disassociate any given application's disk transactions from actual read/write access to the underlying physical disk surface by its heads.

OS storage/filesystem logic has become MUCH smarter about physical disk transactions and allocations. Fragmentation impact has been greatly deprecated in all but the most serious scarcity cases (and even there in the case of pagefiles) -- and if you're already operating in such a scarcity case, then the overhead consumed by a second partition caused more systemic harm than good (in performance, stability, etc.). If your system suffers from critical lack of free disk space, another physical drive is the ONLY way to achieve a reliable ongoing performance improvement.

Go read books on modern filesystem design and OS internals and you'll quickly discover that MOST old "application tuning" tricks actually do more harm with modern OS and storage systems than good. All the tricks wind up doing these days is interfering with the technically more-advanced (and with more solidly-founded research and benchmark testing) OS mechanisms that already achieve any such gains to be had.

The OS storage system is the REASON that modern OSX partitions keep such low fragmentation levels until at the most dire scarcity levels. It's also the reason paging files start as contiguous disk sectors, and remain that way over time despite extraordinary intervening usage by the OS and applications.

Moving said to a separate scratch partition on same physical disk where the partition for the OS and apps reside just isn't as clear a win as you're portraying it. It used to be, when storage access was more of an exclusive proposition at the system level, but given modern heavily-concurrent storage access patterns, it is far more often a detriment than a benefit.

Spend a little time understanding how those components work will rapidly divest you of some of these beliefs you have about what represent "beneficial" storage performance tuning tricks. Then spend a little time reading on what industry-accepted benchmarking has shown to ACTUALLY produce storage performance benefits systemically, and focus on those. Chief among those, as has already been stated, is moving paging and scratch to a _separate physical disk_.

Modern desktop system software now put the paging structures on the same partition as the OS by default (given a single physical disk), and default formatting to a single large partition. This was done as a change from past versions which often defaulted to favoring secondary non-boot/non-OS/App partition for paging/pagefiles. The responsible engineers made that decision based on long analysis, extensive benchmarking of the system impacts, and with a deep understanding of the complete chain of handling of storage transactions from top to bottom.

Perhaps it would be wise to at least understand why they reached those conclusions before widely announcing that you know better. Likewise, providing hard numbers from similar industry-validated system benchmarks to base your arguments (instead of anonymous citations and hearsay) would go a long ways to giving your arguments credibility.

MysteryMonkey
09-25-2007, 10:03 PM
. . . Frankly, your definition of "peak efficiency" is a bit...unfounded. . .

My Bad.

Peek efficiency when compared to using fragmented free disk space on the same frickin drive.

There, you happy?

jwiede
09-25-2007, 10:21 PM
*sigh* Forgot to cut&paste my own citation list into the article...

See:

Singh, A. (2006). Mac OS X Internals: A Systems Approach. Addison-Wesley Professional.

Examine the internals of storage transactions and how journaling changes the actual disk transactions output, as well as the details on zoning. Zoning, in particular, plays a rather important role in mitigating partition fragmentation in modern filesystems, and by default already mitigates the issues you're attempting to address using a second scratch partition on the same physical disk.

See also:

Pate, S. D. (2003). UNIX Filesystems: Evolution, Design, and Implementation. Wiley.

Russinovich, M. E. & Solomon, D. A. (2004). Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000 (4th Edition ed.). Microsoft Press.

jwiede
09-25-2007, 10:23 PM
My Bad.

Peek efficiency when compared to using fragmented free disk space on the same frickin drive.

There, you happy?

Again, please go look into how modern storage filesystems using zoning. Just because free space is fragmented does not, in and of itself, reduce the performance of the partition. Zoning is the canonical example of how fragmenting free space deliberately can greatly INCREASE performance (and mitigate unwanted fragmentation of the zones' free space regions).

MysteryMonkey
09-25-2007, 10:30 PM
[QUOTE=jwiede. . .Zoning is the canonical example of how fragmenting free space deliberately can greatly INCREASE performance (and mitigate unwanted fragmentation of the zones' free space regions).[/QUOTE]

You win. I give up. I'm going to completely fill my hard drive with every bit of data I can find and then I'm going to go in and delete every other file so I can improve the efficiency of my Virtual Memory.

There, Are you Happy Yet?

dsol
09-26-2007, 08:12 AM
You win. I give up.

The funny thing is, both sides of this little debate are arguing about different things. Yes, we all know that having a separate dedicated disk for VM is faster than using a partition on the same disk. For some users though - laptop, iMac, mac mini owners, they'll only have the option of using a single disk (and if you even mention using USB or Firewire external drives as scratch disks I will twonk you on the head). In that scenario, it's simply about optimising your (single disk) system to run as speedily as possible.

There are three advantages to using a separate scratch partition. Feel free to debate the relevance of them. They are:

1. the ability to format that partition using a filesystem and cluster size optimised for speed rather than filesize efficiency. In the past when running NT on a PC, I had a separate 2GB partition formatted as FAT16. This was faster (at the time) than using NTFS (under Win NT4). I'm not sure what the fastest file system is on OSX. HFS+ non-journalled perhaps?

2. Preventing Virtual Memory usage unexpectedly using up all available space on your startup disk - for example when you're rendering an image sequence to the desktop. If it's using a dedicated partition you know for sure that VM won't have an impact on your free space for saving files.

3. Lastly, as partitioning is handled at a hardware level by the Hard disk itself there is - apparently - a better chance of not losing all data on the drive if the heads crash. The use of Journalling in modern filesystems has reduced the danger of this admittedly.

Of course, in reality the speed gains you gain from a dedicated scratch partition or drive are minimal. If you're using so much RAM in an app it's having to use VM extensively, it's going to crawl no matter what tweaks you do. VM is no substitute for real RAM. Which is why I have 6GB on my Mac :)

mlinde
09-26-2007, 12:10 PM
It was an educational debate though!

And Dan, why will you "twonk me on the head" if I mention using a FWHDD? Are you saying that it's even less efficient than the separate scratch partition? I know (on the Mac) that FW has better sustained throughput than USB2.0, which is why that would be my choice with a Mac Mini or Portable - but you suggest that isn't a good option - why?

jwiede
09-26-2007, 01:10 PM
1. the ability to format that partition using a filesystem and cluster size optimised for speed rather than filesize efficiency. In the past when running NT on a PC, I had a separate 2GB partition formatted as FAT16. This was faster (at the time) than using NTFS (under Win NT4). I'm not sure what the fastest file system is on OSX. HFS+ non-journalled perhaps?Once on-disk caches became ubiquitous, this kind of coarse tuning lost most relevance. The granularity of access to the physical disk itself became solely the domain of the disk firmware, and without a deep understanding of the precise caching mechanisms implemented on any given model of disk, such tuning became more likely to reduce rather than increase performance.

A legitimate case can be made that filesystems which omit techniques such as journaling perform faster for certain classes of access. Even there, though, the benefits are often "lost in the noise" of normal storage access overhead. The risks, however, rise very sharply, and a single failure/corruption incident would likely cost more time than any performance win of this approach across the lifetime of the physical drive.

Given that modern storage filesystems and drivers already go to substantial lengths to optimize zone allocation and access patterns for paging files, it is not a clear win that any given user-selected configuration would beat that done by the configuration analysis of the storage system itself. Unless the user had a very clear understanding of what settings were optimal for their precise disk model, there's a substantially greater chance of their settings harming performance than them lucking into beneficial settings.


2. Preventing Virtual Memory usage unexpectedly using up all available space on your startup disk - for example when you're rendering an image sequence to the desktop. If it's using a dedicated partition you know for sure that VM won't have an impact on your free space for saving files.If the VM partition's free space is exhausted when attempting to allocate more, having free space on the working set partition (as opposed to the paging partition) is largely irrelevant. In exhausting VM, the system has entered a serious exception state, and your system is almost certainly heading down a terminal path as a result. Whether you still have space on your working set / apps / OS disk at that point is generally moot.

In the converse case, being able to continue allocating VM space is really not going to do much to aid (or harm) the situation where you run out of working set disk space at a critical moment. You're going to need some space to write your data files, period, and unless you're willing to write them to your paging partition (at which point there is no different that using a single partition for both uses), VM consumption is irrelevant to solving that problem.

There is an cost to having additional partitions, and associated directory structures on a physical disk. With a single partition, all the sectors which were consumed for such overhead can be used to solve scarcity issues. That's a clear benefit to having a single partition on a physical disk.


3. Lastly, as partitioning is handled at a hardware level by the Hard disk itself there is - apparently - a better chance of not losing all data on the drive if the heads crash. The use of Journalling in modern filesystems has reduced the danger of this admittedly.

Physical drives don't have any concept of partitions. They know about sectors, tracks, heads, and so forth. Their firmware may provide abstractions to avoid revealing physical sector/track/head topologies, but those abstractions don't involve any knowledge of partitions either.

See the IDE and SCSI specs to understand how disk transactions are addressed -- said addressing has no concept of partitions. Partitions are strictly an OS storage software-implemented mechanism, and while there are some cross-platform conventions about the format and placement of partition tables, from the drive's perspective that info is still just arbitrary data written to the device.

-JFW

brunopeixoto
09-26-2007, 02:08 PM
Do you know xbench? Or a disk speed utility from AJA. try then on your HD's.
Single SATA HD's on health state have average speed of 45 MB/s, FireWire HD's (health too - maybe SATA or ATA) 35 MB/s (remember, average speed, not peak speed). When any HD have problems with heavy frag (OK, OS X keep the files on continous space, but not organized, and after some time, it's hard to find enough free space contonuous), directory problems, and so on, speed decreases (dificult to find files or part of it). I've noted that in Intel machines something change!!! I really know don't what change, but VM files are not so easy to be found (on PPC machines it was on the home folder, invisible). If VM files it's stored on a separate partition, all problems related will be isolated to it, and the os partition will be safe and all related problems gone.

dsol
09-26-2007, 03:16 PM
FireWire HD's (health too - maybe SATA or ATA) 35 MB/s (remember, average speed, not peak speed)

Yeah Firewire drives are usually noticeably slower than SATA drives, since AFAIK there are no "native" firewire - or USB2 for that matter - drives on the market. As a result, they all use bridge chips to convert between USB/firewire to SATA/P-ATA - said conversion will incur some level of overhead compared to native devices.

That's why using FW externals for VM scratch is a bad thing. Unless you've got a REALLY slow internal drive (like the 4200rpm units in some laptops and early mac minis). USB is a CPU hog and has lower sustained transfer rates than FW (no idea how it compares for latency), so it's even worse.

Thanks for the good info JFW - as you can gather, most of my knowledge of partitioning is probably a bit out of date. It was all true in the day though! :) The fact that OSX doesn't have a simple preference pane to set the devices to be used for VM means I haven't bothered to set up a dedicated scratch partition in a while anyway. As I said, I just make sure I have plenty of real RAM :)