So how does this affect mount points hosted on a single volume?  I'm guessing you would still need to look at how the underlying storage was provisioned (cluster size and alignment) but are there any special issues not mentioned in this article?

Nice write up by the way.

Thanks.

Why do people always still look at me strange when I tell them that allocation unit size and stripe sizes mean something and should be completely turned up? The worst case I think I've seen was an iSCSI 17tb RAID 5 stripe (bad idea no. 1) and the cluster block size was 4K (bad idea no. 2). Thank you for spreading the word.

So I have one question: Why is the recommened cluster size 64K? Wouldn't it make sense to chosse a size that corresponds to the page size of the DB?(32K in 2010)? Wouldn't choosing 64K waste space, since 32K of Data would be written to a 64K cluster? Thanks, Christian

In this post, does volume mean "partition" or "logical disk (as seen by Windows, might be a RAID set)"?

You mentioned that 200GB Is the recommended database size. Is there an article that reference this? We are going to build an exchange 2010 servers with TB of database size. With the correct cluster size, will this lead to problem?

Thanks fir the great artivke

Why create a single 1TB database?  Create multiple databases based on organizational factors such as department names.  Finance, HR, Marketing, etc.  Exchange 2010 makes this super easy, it controls the maximum database size you need to manage, and it keeps users compartmentalized.  If you need to work on one DB, you can do so without having to take down the entire organization.

The articles does not mention what to do, particulary on datacenter scenarios, if the Exchane is beeing installed on a 3rd-part storage solution and they have a "black box". Example: Our IBM Lotus Notes will be migrated later this year to MS Exchange 2010 and the Datacenter will use a VMWare Enterprise and a Hitachi Storage. We can´t control any of the recommendations, it´s ooff our hands. VMWare uses a "proprietary" file system, the storage uses it own cluster sizes. I think the recomendations are valid for physical systems, not for virtual systems, am I right? There is a real difference if i use a 4K or 32K cluster in a storage i can´t control? There is a sense in worring about the number of databases per volume in a virtual environment?

Mike,

Great post!!! I hope you guys post the link on the internal Exchange distribution groups because I know some PFEs could really use this as a reference with their customers.

I do have one question though, why is there a 2TB Volume size limit recommendation for Exchange 2010 in your post (that's how I read the recommendation currently)? I understand the database sizes are recommended not to exceed 2TB (even though I think the v14.4 storage calculator for 2010 will go past this):

technet.microsoft.com/.../ee832792.aspx

Our current plan is to have GPT volumes (on RAID 5 arrays) the size of 2.5TB, with 6 databases on them. So we were keeping well under the 2TB database size, but having seen your comment about the volume size I wanted to double check why you were making the recommendation before I potentially shot myself in the foot by exceeding it.

Great article.  We are currently migrating from Exchange 2003 to Exchange 2010 and would have completely missed this.  Luckily Exchange 2010 is so easy to work with I was able to reformat our entire disk to 64k in around an hour with zero down time.  Where was this in Microsoft’s documentation as an initial pre installation step for Exchange 2010?  

Mike,

I was hoping you could address my question the 2TB volume size limit recommendation. I am about to deploy a 2.5 TB LUN, and want to make sure I am not about to shoot myself in the foot.