X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7642C.747DD91F@onstor-exch02.onstor.net>; Sun, 11 Mar 2007 15:27:29 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C7642C.747DD91F"
Content-class: urn:content-classes:message
Subject: RE: Advice required
Date: Sun, 11 Mar 2007 15:27:29 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E2AD8B4@onstor-exch02.onstor.net>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Advice required
Thread-Index: AcdiQpfdHFiDog2KR8iUQgmlRfXZegAJFtLwAASDBYAAA/5U4AABmBXAAC8QbSAAN/4dMQ==
References: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B406@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E02C1B42B@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E02C1B759@onstor-exch02.onstor.net>
From: "Eric Barrett" <eric.barrett@onstor.com>
To: "Tim O'Callaghan" <tim.ocallaghan@onstor.com>
Cc: "dl-cstech" <dl-cstech@onstor.com>,
	"dl-se" <dl-se@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7642C.747DD91F
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C7642C.747DD91F"


------_=_NextPart_002_01C7642C.747DD91F
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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



------_=_NextPart_002_01C7642C.747DD91F
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: Advice required</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Tim,<BR>
<BR>
This sounds correct.&nbsp; 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.&nbsp; And even when churn eventually evens out =
the space on the volume you'll still have a sane config.<BR>
<BR>
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.&nbsp; 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 =
&quot;gotchas&quot; there may be to discover.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Tim O'Callaghan<BR>
Sent: Sat 3/10/2007 12:55 PM<BR>
To: Eric Barrett<BR>
Cc: dl-cstech; dl-se<BR>
Subject: RE: Advice required<BR>
<BR>
Eric,<BR>
<BR>
<BR>
<BR>
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)<BR>
<BR>
<BR>
<BR>
Our initial volume size should be 8Tb created on a system comprising a =
minimum of 2 controllers - with 16 spindles per 2TB lun<BR>
<BR>
<BR>
<BR>
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<BR>
<BR>
<BR>
<BR>
Do you agree or have I missed something obvious?<BR>
<BR>
<BR>
<BR>
Regards<BR>
<BR>
<BR>
<BR>
Tim<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Eric Barrett<BR>
Sent: 09 March 2007 21:11<BR>
To: Steffen Thuemmel; Eric Crutchlow; Tim O'Callaghan; dl-cstech; =
dl-se<BR>
Subject: RE: Advice required<BR>
<BR>
<BR>
<BR>
It simply means that there is no significant performance gain beyond 4 =
LUNs.&nbsp; Performance does not get worse, as far as I'm aware.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Steffen Thuemmel<BR>
Sent: Friday, March 09, 2007 12:26 PM<BR>
To: Eric Barrett; Eric Crutchlow; Tim O'Callaghan; dl-cstech; dl-se<BR>
Subject: RE: Advice required<BR>
<BR>
Eric,<BR>
<BR>
<BR>
<BR>
What does this mean in perspective to the LUN limit of 2 TB ? Any volume =
greater than 8TB performs badly ?<BR>
<BR>
<BR>
<BR>
St.<BR>
<BR>
<BR>
<BR>
Steffen Thuemmel<BR>
<BR>
ONStor<BR>
<BR>
mobil. +49 173 673 3434<BR>
<BR>
mail. steffen.thuemmel@onstor.com<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Eric Barrett<BR>
Sent: Freitag, 9. M=E4rz 2007 19:32<BR>
To: Eric Crutchlow; Tim O'Callaghan; dl-cstech; dl-se<BR>
Subject: RE: Advice required<BR>
<BR>
<BR>
<BR>
Let me throw in that I think it would be wasteful to use more =
LUNs.&nbsp; The default allocator misbalances I/O pretty badly anyway, =
and the alternate (&quot;vol modify &lt;volume&gt; -a 1&quot;) allocator =
pretty much ignores any LUN over 4.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Eric Crutchlow<BR>
Sent: Friday, March 09, 2007 8:28 AM<BR>
To: Tim O'Callaghan; dl-cstech; dl-se<BR>
Subject: RE: Advice required<BR>
<BR>
Tim,<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
Regards,<BR>
<BR>
Eric Crutchlow<BR>
Professional Services Manager<BR>
t: 408-376-3113<BR>
f: 408-963-2409<BR>
m: 408-596-1155<BR>
<BR>
________________________________<BR>
<BR>
From: Tim O'Callaghan<BR>
Sent: Friday, March 09, 2007 4:01 AM<BR>
To: dl-cstech; dl-se<BR>
Subject: Advice required<BR>
<BR>
<BR>
<BR>
Guys,<BR>
<BR>
<BR>
<BR>
I have had the following questions from a potential client,<BR>
<BR>
<BR>
<BR>
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&nbsp; 8, 12 or 16 luns etc?<BR>
<BR>
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?<BR>
<BR>
<BR>
<BR>
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?<BR>
<BR>
<BR>
<BR>
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<BR>
<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
Thanks in advance<BR>
<BR>
<BR>
<BR>
Tim<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Tim O'Callaghan<BR>
Senior S.E.<BR>
<BR>
ONStor, Inc.<BR>
office:&nbsp; +44 1189 635866<BR>
mobile: +44 7767 435472<BR>
<BR>
tim.ocallaghan@onstor.com &lt;<A =
HREF=3D"mailto:tim.ocallaghan@onstor.com">mailto:tim.ocallaghan@onstor.co=
m</A>&gt;<BR>
<A HREF=3D"http://www.onstor.com">http://www.onstor.com</A> &lt;<A =
HREF=3D"http://www.onstor.com">http://www.onstor.com</A>&gt;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C7642C.747DD91F--

------_=_NextPart_001_01C7642C.747DD91F
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-Description: image001.gif
Content-Disposition: attachment;
	filename="image001.gif"

R0lGODlhTAEmANUAAP6zNQBRiP3+/ZeFTQFShkWAp4+xxrTH02uVsVVuZ017moyltiNpl8zZ4hRd
jDZjceioOXN2VyhcdPevNsPS29bg5reTRHejwKG6yxdXfXyetcubP+3y9jBwmtihPg1UguLo7DV2
oGR2ZfP19+nt8UlmZSZjh1uIpoR+VDtukh5gjPj6+wdViA1ZjDBpjgBTif///wFSiQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAABMASYAAAb/wJhw
SCwaj8ikcslsOp/QqHRKrVqv2CzxRYi9vuCweEwum8/otHrNbrvf8Lh8Tq/bwYRArKvt+/+AgYKD
hIVXL0ovAQF5XI5eMYx7XJB6lkJfRJdglopZiJGRBJl6e16IlIaqq6ytqqigSIujoJadpaFCowSj
XryRjF2zeZGZh129yFy4pnx7zq7R0tPURrBJAcuYjcbZX7zfxbbOvc/eyH3ek5RcxOulsdXy8/SB
10eoeo3wpYx67JKQeWtXDBO8LvGo1BL4r9GebJPA1ZtIsaKUe0b00eLziJe6bMJulePTixElcNAU
CsvDIESBAg70pRKizqLNmzgxnUoSS4+D/w4dHIzcNeScJ1PZPkiQkIFFkTwpqawM4ODAiBUVPoR6
0UIBJI8Jc4odGw3jU5MEQmAgMWIEiAMFEHY4QKFuCkwd6hpwGuPBAA8QAm8Y8CDGhxKIMzCj8i9A
iwMwIt/VF0OFAQ1fIEYly7mzILNPuWgQEBkGadMIuoQYcZqC1hgFTINwWgICgNu4AWz48GDC7Qdh
p/TSEJmCgUleXChgYUABIo+eo0v/A3qIMAWlK2jQ0MA0DK8hOHj/nq0A6QovJPgG4AFFggEbdLOQ
YHvCgzwQJ5VCaBJeLV8ukGaAA1oJU5VWVWXw0GLTNejgE9XRVBkIkR0QE1cYREaCA+GVBv8DCFrF
BkMDMaBwmwcZPMfCexKgUB8KIoigWAwSiIDCjSV8oIgJMSbwQgYJlCDBA0sFwAIGAlDg1AsMtMAI
BgqAc8IJyTxo5ZVLREgTdjCskEIqJowQ2QkdiOdWZAjARhqJA9wGgQTIjMKCCLitB0AJAdSWGwAW
6CiCbxuUYIFuQ0YgwgsqUOgcFwpoEIACGJxCgAoYqIAOlphmCokxGcVggAACNHAhIyx0J4ABDIhH
wgkrfKhCB5GRGAEAvkFgQQQPpPhCCR5M4KsHG3iwFG4WDGAbAAPEQKev623AAgEfhOhqQwtoQIED
uhiJQQeSaOqtlVpyAZkAB7QwE2QwHFD/ZpcOLBCZBgEKUAELGdSXmwciaPUABL4BB+2gAKAwCn2/
JYDbYANEMIo+CMBAQQtEOFCBAg1xASVy32YsnZbZUFDhs0UdQNoBIZBAmgOJwjCCBivI65QE8e0J
QAR91Xffj75NIAEobQZsMHtwemLLCQ4vSQwDz5J0JMW/aOw0Z1pGMm65oRDAgscCYJCqaSoE0LBp
a7YwCpDwHXvbUjYv8oCbEphiIrI/76aLRC+kgBW2iwAzUgxVMXDU04DnpOUoX3OAbSgOUAiDBuuu
wIBhisf6gTsvKPU2AAnsSytwAawNAATAIfL2AHFPLko2erTQgAB3IYL6V1yksADEnAZu/ztF4cbg
QmkIhHMCaaw3zkAXXEqOQgm+dEHwnZoDsHMMGeRcWDY9R1C6Kdh/8fsCC8OiGQEYuODJZreXP024
jIz2LgMdINAqDNx36LgXH1DQGgsbTDCAkCb45WYGy0sAAD/QswFk4DD80lncFGSdYFgNMikoR0O6
cALuicN8GJQHxyLxge5EhgMkKE0DFLQa0wxPDwoAXgPwhxsI9Ao3PvoAwCZgAQ8Q6VgbsMB6BEYn
3WgFFUV4gQkqMAKvBAMXJ8DA5C6VwSaWZSdHAMcLHIABDpxGAByolGrYMgIT0AR8KxjBCkWwAbPR
ygMJAEfzblOCXb3wNvqb3J8msAHFEP8DF4oggAtWt60WsIAFHMLAAXS0DScashXoEwUB2neBC5Bp
CFN8SQFYMIvKvCQEeeBNjAyVo4IQAEg9eg2QIgCjwnghA4i5jxQRAgkhOMBa8joAXQ5wAqdIwh+H
zGUhckcU7K0kE8ughU6St6lgPERoedSJME5HkmEq4plFAcVPEIAAMkGsJJrRpTbtAcWMuOMU/XDd
L/TRiVCYhCaxyCNEKkkJ1IFkIcRoBH6U0U1FgAQf2NumPj/RzadIqmqQTEWaGPA4BhRADwW4gN9i
wAADcIIjz0kTKO74gkb6rZ3qaAcQ3RGXqnmjkh/dp0j5WTvGgMAlcbmAAfRwgSl6AQP/IWBSCBjq
N6qgSqEzfQFMaHKBPRA0pie4AAFaQgAHMMCoISgoAwJw0BDENKnCHKlU+xA1KFwAAy95gQEUSoBG
/gKmCb1AQlNDFa05UqFnNQkF0BpUBiDgAg4wwJQKMCAMnGBAF0jTBUKg0LA+jnxTDSwUquqEAOwV
qyE4wFaFwFde9FSoXb0ASAwbg56+BAONLEVPKwsbSRYAs5Lk7EskW9GKvtWiMxGsaqNAWCdI1gB0
xRYGIlsARAiVARi4qU7E2tKX3LV3eVhrQjuL2xdg1qAHxWykNotWhWI2IquNLoT6KZXMOCJvuihm
3nApDKHdsZkOkRBaKroLXiDEGfZsn6V018sT6k7hOfrRDzQlgg5ovG6dqHBGQLZBi+FN9Jjo5AZ7
B4zPkkrlIV7Ipiho0g9zttMTR3FIhLMrIYSkQp7P+S+BN6wTA18Eww3eT3Zvac6iPCPBuWAlJFGn
0XC+s5yA5fBqWyvjGj/NdR7KsY53zOMe+/jHQA6ykIdM5CIb+chITrKSl8zkJgf5DlCOspSnTOUq
W/nKWKaDLwIQBAA7

------_=_NextPart_001_01C7642C.747DD91F--
