Just to point out: it's not the space as much as the separate spindles that
you're after. That separation is one of the best performance related
investments you can make.  As was explained earlier and as you've noticed,
Exchange is very disk dependent. Very. Several things can be done to help
reduce the impact, but at the end of it all, the io has to be handled at
some point.

Understand that there are several different things going on for the life
span of a message submission/delivery/retrieval event (all of these can be
going on at the same time.)  A lot of it is going to utilize the disk.
There will be several different io types i.e. sequential write, random
read/write, and sequential read are primarily what you'll have to account
for. Putting them all on the same physical spindles can have a serious
impact on performance due to disk contention. Of those, the one io type most
noticable to users is the sequential write of the log files.  This is an
artifact of the two-phase commit database technology employed by the jet
engine.  You want that to occur, trust me. But if that write to the log file
is slowed, then store gets blocked and your users may notice it.

So what can you do about it? For starters, you can optimize the disk
subsystem so that these events don't impact one another nearly as much.
Separating io types is the way to achieve that and by far putting the log
files on their own separate set of write-optimized physical disks is a low
cost, and easy way to do that.  Using raid5 for log files is not recommended
for that reason. raid 10 or 1 depending on the sizing information is often
recommended and used with great success.

Another thing you can do is use cached mode for your users.  This has a
bigger impact when first fired up, but the user is less impacted later.

You may also want to check out your global catalog servers.  If the majority
of your users are OWA users, then the impact on the server should be much
different than what you describe and disk should be less of a concern in
many cases.  Your case may be different, but generally speaking. You should
also take the advice posted and find out what the message patterns are: are
there a lot of large blobs being submitted? Are there other applications
affecting you? etc.

My $0.04 anyway.

Yes log files grow in increments of 5MB. 73GB is overkill for logfiles.
36GB is the smallest HD you can get for the HP servers, which will
suffice.

James Chong

Ariel wrote: