Jim,
>That's an interesting perspective. But I'm not sure it would be that helpful.

My usage pattern is very different from that used by spreadsheets or documents. I am coming from working queries on multi-megabyte cursors and tables.
>
>I stopped partitioning my HDs as soon as it was feasible, but that's beside the point.
Since I am a strict believer in at least a double boot OS, my primary disk houses only the boot loader and then I have some small OS partitions. All application programs are in one common partition to save space, and the registry entries from all OS point to that partition. That takes only a few GB. Much of the space is needed for storing base tables query results and sendouts: inefficient but necessary, since processing to re-create takes to long in case some question has to answered.

I had to work one of the typical mining scenarios on a machine not installed to my preferences, but to a boot disk and large rest. This disk had still more than 100 GB free, but other saving stuff was already on it. I was wondering, why times took so long and watched a simple copy operation: speeds of 6 - 18 MB/sec, mostly in the lower area. These machines when working as I wish them to have a copy speed between 45 - 56 MB/sec (always source and target on different physical disks to eliminate head thrashing).

>I understand that many (most?) people like to partition their HD so that C: has all the OS and products and D: has all their working (personal) data.
>In such a case they are paying a penalty every time they access their working data because chances are good that the OS or the active programs refer to C: frequently, for anything from their executable components to their temp files in Documents and settings...
>This means crossing the whole of C: including a bunch of empty space every time that happens. And in the reverse direction too.
Yes, but the pattern is usually "chunky", so it is not that bad. But imagine you have loaded vfp totally and you join a couple of tables with a total size of about 5-7 GB and these are spread over the total "surface" of a 300GB disk (even on multiple platters) in non-contigous areas. Your temp space is either on the OS disk (default setting, probably a small area already filled with oodles of temp internet files<g>) or you have placed it as well on the large data disk (there also adding to head movements brought courtesy of defragmentation - at least in *my* case it really hurts measurably, even more so when doing SQL).

Minimizing head movement is best strategy. So my arrangement is: if there are reusable source tables, they live on small, easily formatable areas of their disk(s), feed cursors in a special working partition having nothing else on it (every temp file in the root<g>) on another disk and the results are exported to a third disk are a clean partition on the "source disk". When everything is done, the results are sent away and saved to tape and to "saving" partions (usually deleted after 6 month, as most questions come earlier and we still have backup. We have not experimented with soft-raiding our disks, as I fear the multiplying error rate and there is not enough room for 6 to 10 disks in each machine. The perf is quite adequate, each machine is faster than our old trusty workhorses on which we started: 8-way SCSI RAID with a 2 1.1GHz P3 server on 2 Gigs of RAM on one machine, 6-way SCSI RAID on the other. They are feed websites now: there the RAID shines even more.

>I think people are better off not using partitioning, most particularly for the HD housing C:.
You got a point as "more" can make things unstable. The Boot disks on my personal machines here are old drives which can be swapped easily in case of failure: some old 4GB SCSI, some 10GB PATA. They house nothing important, and spare space is used as "scratch" common space for data. My OS partitions are reasonably small and easily saved/restored, while the bulk of the machine is untouched, but this is not "mainstream" computing. And Vista's reported tendency to assign "C:" to the partition it lives on makes me wonder how I will cope there...

regards

thomas