Proposed Partion/Drive/Volume sizes

[PUgrad]

I have a new W2K cluster for file services that will have 500GB of disk space online. The space is coming from a SAN, so I can allocate the space as any size drives.

What would be the best way to allocate the space? 1 500GB volume seems a bit overboard and risky. 2 - 250GB would be a minimum for the number of drives as each 250 would come in via a different preferred path. However I am wondering about the time for Chkdsk to run if the server goes down dirty. 5 100GB would be possible too.

Any suggestions from experience as to what would be the best allocation of space? The shares on all of the disks will all be put together logically with DFS.

Thanks,
PUgrad

 

[xmsre]

Chkdsk actually has improved from the old NT 4 days and is much faster. The time is more a funtion of the number of files, directories, ACEs on ACLs, MFT size, etc. so it varies. Basically, it depends on how much work chkdsk has to do. There's actually a whitepaper on that subject.

Bringing cluster into the picture adds the failover time factor to the equation. Then there's always the time it takes to restore a given volume. Generally, breaking it up into more managable pieces and then stitching it back together isn't a bad idea. The size of the volumes would depend on the size of the "leaves" in your DFS namespace.

With DFS, you add a little complexity to gain a lot of flexibility. You can run shares on both nodes, using their NICs and HBAs. Restore times are faster. Chkdsk runs faster. Remember, however, that you can only have a single non-AD integrated DFS root on a W2K cluster. Basically, you can create a highly robust, scalable, and available solution. For an example, see Q301588.

John
MOSMWNMTK