Ideally, you want a couple of different locations for sharepoint files. In
our installation, we have three physically separate sets of volumes:

- Mirrored C: partition
- RAID 5 F: partition
- Single L: partition

So sharepoint is installed on C:, the Data hierarchy is on F: and the logs
are on the L: partition. I must say that since splitting off the log files
(as referenced in the tuning whitepaper at microsoft), there's a performance
increase.

Probably you should mirror the log partition as well as extra
precaution. You can gain extra performance by putting the data hierarchy
on a RAID 10 partition.

I meant to say RAID 10. We originally set it up on RAID 5 (Dell
6300, PERC 2), then we set up another identical server but with RAID 10. We
saw minor performance increase on the RAID 10 but decided to run with it.

We intended on mirroring the log partition, but in a couple of weeks we
should get our SAN installed, and all of the drives will be logical volumes
on it instead, so performance and disk fault tolerance won't be an issue any
more.

btw, in case anyone cares.... I got on a big kick of performance tuning once
I saw how slooooooooow bringing up the initial workspace is. I mean, it's
10 seconds to load, and we have a kick-ass box, 100Mb to the desktop and all
sorts of horsepower. I learned that SPS has all these 30,000-line files  it
has to load in order to set up each session, and that's what takes it so
long.

Anyway, after following the tips in the optimizing whitepaper, moving to
RAID 10, splitting off the log files, setting cache settings, etc... the
initial page load time is now cut to 5 to 6 seconds. That's still way too
long for what I think it should be for user experience, but at least it's
faster.

I'd recommend to all to do testing, testing, testing if they have the
hardware. The backup/restore features of SPS makes it that much easier.
One could take your workspace on any number of different servers to measure
performance.