Advice for large volume creation in Windows 2003, R2?

We have an application running on Windows 2003 that is very space-hungry and needs to be
tied to a drive letter for its storage location (ex: k:\datastore, m:\datastore). We've
tried taking LUNs - (Dynamic, GPT disks) from our SAN and concatenating them to spanned
volumes to aggregate their size, but I think the performance problems we're running into
may be due to this overhead in the software striping department (SAN is new & running RAID
6 groups).

Basically, we'd like to end up with several volumes in the 5 - 10 TB range, so we don't
get squeezed on space or run out of available drive letters... Are there better methods
to go about taking a collection of 1.8TB LUNs and creating volumes this large?

TIA,
BM

 

One recommended way to save drive letters and consistency when something
goes wrong is to use mount points instead of drive letters.

"Brian MXP" <brian@nospam.mit.edu> wrote in message
news:Or8sf4D1JHA.5684@TK2MSFTNGP04.phx.gbl...
> We have an application running on Windows 2003 that is very space-hungry
> and needs to be tied to a drive letter for its storage location (ex:
> k:\datastore, m:\datastore). We've tried taking LUNs - (Dynamic, GPT
> disks) from our SAN and concatenating them to spanned volumes to aggregate
> their size, but I think the performance problems we're running into may be
> due to this overhead in the software striping department (SAN is new &
> running RAID 6 groups).
>
> Basically, we'd like to end up with several volumes in the 5 - 10 TB
> range, so we don't get squeezed on space or run out of available drive
> letters... Are there better methods to go about taking a collection of
> 1.8TB LUNs and creating volumes this large?
>
> TIA,
> BM

 

Thanks, Dusko. I haven't done a whole lot with mount points to be honest, so I wonder
about the following:

- How does this affect monitoring the size/free space of the volume? Does the OS 'know' if
the basic disk plus the added mount points get near capacity?

- Does this aid disk I/O performance in any way?

Thanks,
Brian

Dusko Savatovic wrote:
> One recommended way to save drive letters and consistency when something
> goes wrong is to use mount points instead of drive letters.
>
> "Brian MXP" <brian@nospam.mit.edu> wrote in message
> news:Or8sf4D1JHA.5684@TK2MSFTNGP04.phx.gbl...
>> We have an application running on Windows 2003 that is very
>> space-hungry and needs to be tied to a drive letter for its storage
>> location (ex: k:\datastore, m:\datastore). We've tried taking LUNs -
>> (Dynamic, GPT disks) from our SAN and concatenating them to spanned
>> volumes to aggregate their size, but I think the performance problems
>> we're running into may be due to this overhead in the software
>> striping department (SAN is new & running RAID 6 groups).
>>
>> Basically, we'd like to end up with several volumes in the 5 - 10 TB
>> range, so we don't get squeezed on space or run out of available drive
>> letters... Are there better methods to go about taking a collection
>> of 1.8TB LUNs and creating volumes this large?
>>
>> TIA,
>> BM
>

 

And I guess I would love to hear from anyone who would know what benefits in storage
(larger native volumes can be addressed? are there any of the limitations from 2003 gone?)
there are in going from Server 2003 to 2008 or 64-bit...

Thanks again,
B

Brian MXP wrote:
> Thanks, Dusko. I haven't done a whole lot with mount points to be
> honest, so I wonder about the following:
>
> - How does this affect monitoring the size/free space of the volume?
> Does the OS 'know' if the basic disk plus the added mount points get
> near capacity?
>
> - Does this aid disk I/O performance in any way?
>
> Thanks,
> Brian
>
> Dusko Savatovic wrote:
>> One recommended way to save drive letters and consistency when
>> something goes wrong is to use mount points instead of drive letters.
>>
>> "Brian MXP" <brian@nospam.mit.edu> wrote in message
>> news:Or8sf4D1JHA.5684@TK2MSFTNGP04.phx.gbl...
>>> We have an application running on Windows 2003 that is very
>>> space-hungry and needs to be tied to a drive letter for its storage
>>> location (ex: k:\datastore, m:\datastore). We've tried taking LUNs -
>>> (Dynamic, GPT disks) from our SAN and concatenating them to spanned
>>> volumes to aggregate their size, but I think the performance problems
>>> we're running into may be due to this overhead in the software
>>> striping department (SAN is new & running RAID 6 groups).
>>>
>>> Basically, we'd like to end up with several volumes in the 5 - 10 TB
>>> range, so we don't get squeezed on space or run out of available
>>> drive letters... Are there better methods to go about taking a
>>> collection of 1.8TB LUNs and creating volumes this large?
>>>
>>> TIA,
>>> BM
>>

 

On 5/14/2009 5:53 AM, Brian MXP wrote:
> - How does this affect monitoring the size/free space of the volume?

It depends on the application.

Free space is per file system. With mount points (DDO) a directory
structure can cross file systems. Thus you can end up with more free
space in one part of a directory structure than in another.

With this in mind, applications that check free space for the (root of)
the drive may not be aware of the actual free space where their data is
stored. If the file system the data is stored on has more free space
than the root of the directory structure this will usually error in a
good way by reporting less free space than there actually is. However
as long as there is more free space than what an application is trying
to write, things are usually "Ok".

Using DDO you really need to check free space at the directory you are
storing things in to know the real amount of free space of that file
system. Of course this does not take in to account spreading
sub-directories of the data directory across other DDO mounted file systems.

> Does the OS 'know' if the basic disk plus the added mount points get
> near capacity?

DDO does not combine space between two different file systems. DDO
really mounts a file system on a directory, thus giving it separate
space from the other file system(s). These are still separate file
systems that do not share space with each other.

If you are wanting to aggregate file systems together you will need to
use a spanned dynamic disk volume to create a (single) larger file system.

> - Does this aid disk I/O performance in any way?

If these file systems are on the same physical disk you will increase
the distance that the drive head has to travel to get from file system
to file system. Thus you may actually slow things down a bit.

If these file systems are on different physical disks, you will be able
to access them (much more so) in parallel. Thus you may actually speed
things up a bit.

If for example you use the (Exchange) Mailroot and MDBDATA directories
on as mount points on different physical disks, you will probably speed
things up. All the while, Exchange still sees things where they would
be by default. The OS is abstracting the physical location from the
logical path.



Grant. . . .