I dont have any solid data on data/stripe/drivesize performance handy, but it is
a wise move to not span raid-groups over multiple FCAL controllers. There will
be write degredation involved with that that I have seen. With two F760s
rebuilding a manually failed drive while doing nothing else, the machine without
a stripe split across FCAL cards completed about 25% before the machine that did
span FCAL cards for a raid stripe.
mkfile tests from Solaris confirmed what Id heard..and saw in the reconstruct as
part of my test.
:-----Original Message-----
:From: mds(a)gbnet.net [mailto:mds@gbnet.net]
:Sent: Wednesday, February 23, 2000 5:04 PM
:To: toasters(a)mathworks.com
:Subject: Re: Disk drive technology
:
:
:On Wed 23 Feb, 2000, "Bruce Sterling Woodcock"
:<sirbruce(a)ix.netcom.com> wrote:
:
:> The article doesn't say, but bigger, faster disk drives
:often draw more
:> power. Thus, NetApp needs to have shelves that can support them
:> first, before they can test them for reliability. There are
:a lot of issues
:> involving mechanical vibration and so on that have to be
:assessed before
:> such a drive could be qualified. It may be that this
:particular drive is
:> not appropriate for certain shelves.
:
:Well, yeah, so much so obvious. So how soon was that? 8)
:
:> More spindles is better performance, if you are read-heavy.
:If your filer
:> seems slow and it's reading constantly but the CPU is still
:under 100%,
:> more spindles could help.
:
:So much for conventional wisdom. However, my question was trying to
:elicit something a little more, well, complete as a model of
:performance.
:
:I mean FCAL is a loop technology, and filers can come with 1, 2 or 3
:loops. How much does performance differ when using 1 chain as opposed
:to 3 balanced chains, using which drives, using what RAID set sizes and
:volume mappings? How does performance get affected by the size of the
:disks you use?
:
:See, if none of these things makes any difference to performance I'd
:love to know why. If they *do* then I'd love to know how to build
:faster filers.
:
:I'd be happy with an analytical model, or a set of tables taken from
:either real lab testing with real filers, or simulator results. As it
:stands though, all we have are rules of thumb that sound plausible.
:
:The same goes for backup performance. There's been so much discussion
:on the list about both topics, but I can't honestly hand-on-heart tell
:someone how best to set-up their filers. I'd write something if I knew
:the answers myself.
:
:The best I can find is things like:
:http://now.netapp.com/NOW/knowledge/contents/FAQ/FAQ_560.shtml
:
:I've been meaning to brush up on queueing theory so maybe I *will* try
:to work something up myself on this. I'd just hate to reinvent
:the wheel
:if someone's done it already. I also don't know anything about the
:buffers in the filer, on FCAL interfaces, the network interfaces, the
:precise use of the WAFL, etc.. So my model might be under-informed.
:
:Here's a thought to mull over: if you have 20 18 gig drives on 2 loops
:and 16MB nvram, will you see better or worse performance than
:with 40 9GB
:drives on 1 loop with 16MB nvram presuming your clients are all writing
:as fast as they are allowed? Please disregard any "such configs aren't
:shipped" objections as this is an in-principle hypothetical. Please do
:consider the effect of RAID sets, and incremental disk-additions over
:the lifetime of the filer in question. I picked writing as the task
:because I wanted to point out also that there's an impact on the DOT
:algorithms, based on the spindles, the RAID set sizes, and maybe the
:chains too.
:
:I don't know the answer, but I'd like to. Without such models we all
:have to purchase filers somewhat in the dark, and either pray that
:we got it right, or expend more time than we could in evaluating our
:purchases for suitability.
:
:One question - is anyone else interested in this or am I just shooting
:my mouth off needlessly?
:
:>-- End of excerpt from "Bruce Sterling Woodcock"
:
:--
:-Mark ... an Englishman in London ...
: