X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7653C.970C4BEA@onstor-exch02.onstor.net>; Mon, 12 Mar 2007 23:55:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Advice required
Date: Mon, 12 Mar 2007 23:55:26 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02CF931F@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E2AD8B4@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Advice required
Thread-Index: AcdiQpfdHFiDog2KR8iUQgmlRfXZegAJFtLwAASDBYAAA/5U4AABmBXAAC8QbSAAN/4dMQBD+EHQ
References: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B406@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E02C1B42B@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E02C1B759@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E2AD8B4@onstor-exch02.onstor.net>
From: "John Klokkenga" <john.klokkenga@onstor.com>
To: "Eric Barrett" <eric.barrett@onstor.com>,
	"Tim O'Callaghan" <tim.ocallaghan@onstor.com>
Cc: "dl-cstech" <dl-cstech@onstor.com>,
	"dl-se" <dl-se@onstor.com>

I think the Pantera performance paper discusses the best performing =
Pantera config. Not sure I agree with accessing an ONStor volume through =
DH controllers is the best performing config. Nor am I sure I agree that =
16 spindles is necessarily the best performing Pantera config. Believe =
we were maxing the controller on streaming writes using 12 disks. Going =
to 16 may cause thrashing.

Also, I didn't see any response to Eric C's comments about application =
and access pattern.

John Klokkenga
Storage Integration Manager
ONStor, Inc
408.963.2471 (w)
408.306.0072 (c)=20


-----Original Message-----
From: Eric Barrett=20
Sent: Sunday, March 11, 2007 3:27 PM
To: Tim O'Callaghan
Cc: dl-cstech; dl-se
Subject: RE: Advice required

Tim,

This sounds correct.  You will still be at the mercy of the default =
allocator, but I think with the entire first half of the volume full, it =
will have no choice but to send all writes to the second half -- pending =
file churn, of course.  And even when churn eventually evens out the =
space on the volume you'll still have a sane config.

However, note that in some testing we've found with certain arrays -- =
and I'm not sure if DotHill is one of them -- there is inexplicable =
degredation in performance (~10% in parallel-request, single-client =
throughput) when using a volume against two controllers instead of one, =
even if the two controllers are in front of separate storage.  I don't =
think it really changes your proposal, but it does highlight how little =
testing we've done in this area and how many more "gotchas" there may be =
to discover.


-----Original Message-----
From: Tim O'Callaghan
Sent: Sat 3/10/2007 12:55 PM
To: Eric Barrett
Cc: dl-cstech; dl-se
Subject: RE: Advice required
=20
Eric,

=20

What I take from all the responses to my questions is; that in order to =
achieve maximum speed on the Pantera system (with an eye to growing the =
file system)

=20

Our initial volume size should be 8Tb created on a system comprising a =
minimum of 2 controllers - with 16 spindles per 2TB lun=20

=20

Growing the volume should be manual and not until usage reaches 99.99% =
(until we are able to have autogrow select 1 lun from each controller =
when increasing volume size) - the manual process should replicate the =
initial volume creation using 2TB luns from as many different =
controllers as possible - again with 16 spindles per LUN

=20

Do you agree or have I missed something obvious?

=20

Regards

=20

Tim

=20

=20

=20

________________________________

From: Eric Barrett=20
Sent: 09 March 2007 21:11
To: Steffen Thuemmel; Eric Crutchlow; Tim O'Callaghan; dl-cstech; dl-se
Subject: RE: Advice required

=20

It simply means that there is no significant performance gain beyond 4 =
LUNs.  Performance does not get worse, as far as I'm aware.

=20

=20

=20

________________________________

From: Steffen Thuemmel=20
Sent: Friday, March 09, 2007 12:26 PM
To: Eric Barrett; Eric Crutchlow; Tim O'Callaghan; dl-cstech; dl-se
Subject: RE: Advice required

Eric,

=20

What does this mean in perspective to the LUN limit of 2 TB ? Any volume =
greater than 8TB performs badly ?

=20

St.

=20

Steffen Thuemmel=20

ONStor

mobil. +49 173 673 3434

mail. steffen.thuemmel@onstor.com

=20

________________________________

From: Eric Barrett=20
Sent: Freitag, 9. M=E4rz 2007 19:32
To: Eric Crutchlow; Tim O'Callaghan; dl-cstech; dl-se
Subject: RE: Advice required

=20

Let me throw in that I think it would be wasteful to use more LUNs.  The =
default allocator misbalances I/O pretty badly anyway, and the alternate =
("vol modify <volume> -a 1") allocator pretty much ignores any LUN over =
4.

=20

=20

=20

________________________________

From: Eric Crutchlow=20
Sent: Friday, March 09, 2007 8:28 AM
To: Tim O'Callaghan; dl-cstech; dl-se
Subject: RE: Advice required

Tim,

=20

First question would be what type of storage. If you are talking about a =
3Par, they do a bunch of stuff on the backend that offsets what we do.=20

=20

If you are talking about a 'generic' type of storage, then the way you =
configure the luns need to be looked at in term of how many total =
spindles do you have. More spindles are better.=20

=20

The most important component (IHMO), is the application. There is a big =
difference in using storage for a video capture app versus hosting of =
websites. Video capture would involve sequential writes of large blocks =
of data. Websites would be large number of inodes, small files.=20

=20

So I think before a general question like the one you asked can be =
correctly answered, you will need to give us more info about the type of =
storage and the application.

Regards,=20

Eric Crutchlow=20
Professional Services Manager=20
t: 408-376-3113=20
f: 408-963-2409=20
m: 408-596-1155=20

________________________________

From: Tim O'Callaghan=20
Sent: Friday, March 09, 2007 4:01 AM
To: dl-cstech; dl-se
Subject: Advice required

=20

Guys,

=20

I have had the following questions from a potential client,=20

=20

Given our best practise of 4 luns per volume - what is the likely =
performance gain (if any) we would see by setting up a volume consisting =
of  8, 12 or 16 luns etc?

When writing data, how many luns will the file be striped across - =
assuming a multi gigabyte file - will it just write to a group of 4 luns =
or stripe across the entire volume?

=20

Assuming the file system has been created, with 4, 8 or 16 luns - is not =
full but then has another 4 luns added, will there be a performance =
increase?

=20

I believe that adding more luns to the file system must give improved =
performance (else how can we gain performance by adding spindles?) but I =
would like confirmation

=20

Any help would be gratefully received - do we have any definitive =
documentation regarding how we utilise the luns etc within the file =
system? I've looked in the wiki but must be using the wrong phraseology.

=20

Thanks in advance

=20

Tim

=20



Tim O'Callaghan
Senior S.E.

ONStor, Inc.
office:  +44 1189 635866
mobile: +44 7767 435472=20

tim.ocallaghan@onstor.com <mailto:tim.ocallaghan@onstor.com>=20
http://www.onstor.com <http://www.onstor.com>=20

=09

=09

=20


