toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

RE: informix and netapps
by Marchi, Michael 25 Feb '00

25 Feb '00

Note the press release with Informix on 1/25 which confirms NetApp certification with Informix. I believe the person you spoke to at Informix is misinformed. If you pass us the Informix contacts we will follow up. http://www.netapp.com/news/press/news_rel_20000125a.html Hope this helps. Mike -----Original Message----- From: Stephen C. Woods [mailto:scw@seas.ucla.edu] Sent: February 24, 2000 3:39 PM To: toasters(a)mathworks.com Subject: informix and netapps Out admin folks have a bunch of INFORMIX(tm) databases that we're thinking about moving to a filer (740 5.3.2). The issue is database locking we've been told by Informix that they don't support databases on nfs filesystems because of locking problems. Is anyone here using INFORMIX on an NFS filsystem imported from a filer? On one machine? Multiple machines? Multiple databases? ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

1 0

RE: informix and netapps
by Moore, Duncan 25 Feb '00

25 Feb '00

Network Appliance and Informix announced Certification for Filers in a Informix database environments this year in January. Press release link below: http://www.netapp.com/news/press/news_rel_20000125a.html I hope this helps. Duncan -----Original Message----- From: Stephen C. Woods [mailto:scw@seas.ucla.edu] Sent: Thursday, February 24, 2000 3:39 PM To: toasters(a)mathworks.com Subject: informix and netapps Out admin folks have a bunch of INFORMIX(tm) databases that we're thinking about moving to a filer (740 5.3.2). The issue is database locking we've been told by Informix that they don't support databases on nfs filesystems because of locking problems. Is anyone here using INFORMIX on an NFS filsystem imported from a filer? On one machine? Multiple machines? Multiple databases? ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

1 0

RE: informix and netapps
by Mohler,Anissa 25 Feb '00

25 Feb '00

That's interesting... Informix has certified NetApp for storage... see this release. http://www.netapp.com/news/press/news_rel_20000125a.html I'm sure your local NetApp sales rep can give you more details about which specific versions of Informix products we are certified for. :-----Original Message----- :From: Stephen C. Woods [mailto:scw@seas.ucla.edu] :Sent: Thursday, February 24, 2000 3:39 PM :To: toasters(a)mathworks.com :Subject: informix and netapps : : : Out admin folks have a bunch of INFORMIX(tm) databases that :we're thinking :about moving to a filer (740 5.3.2). : : The issue is database locking we've been told by Informix :that they don't :support databases on nfs filesystems because of locking problems. : : Is anyone here using INFORMIX on an NFS filsystem imported from a :filer? On one machine? Multiple machines? Multiple databases? : :----- :Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA :90095; (310)-825-8614 :Finger for public key scw(a)cirrus.seas.ucla.edu,Internet :mail:scw@SEAS.UCLA.EDU :

1 0

Re: Disk drive technology
by mds＠gbnet.net 24 Feb '00

24 Feb '00

On Thu 24 Feb, 2000, Noah <sitz(a)onastick.net> wrote: > > In a similar vein, I find that my raid-fu is not has good as I'd like it > to be. Anyone know of any resources (on/offline) that goes into a fair > amount of detail on RAID, RAID sets, configuring for performance, and/or > whatever else I should know but may not? Well I believe these books are a pretty good grounder in such matters: The RAID Book, A Storage System Technology Handbook (6th ed) by Paul Massiglia, Copyright the RAID Advisory Board, 1997, published by Peer-to-Peer Redundant Disk Arrays, Reliable, Parallel Secondary Storage by Garth A Gibson, The MIT Press, 1992 Configuration and Capacity Planning for Solaris Servers by Brian Wong, Prentice Hall, 1997 The first book is very clear and covers RAID well. Gibson's book is the dissertation he wrote developing the ideas of the original RAID papers that he had been involved in earlier. And Wong's book has lots of fairly transferable ideas about (large) server configuration. I've yet to find anything specific to filers, apart from: http://www.netapp.com/tech_library/3008.html Unfortunately it's now 4 years old and covers soon-to-be-obsoleted equipment, though the universals ring true. I'd be interested in other recommendations myself! -- End of excerpt from Noah -- -Mark ... an Englishman in London ...

1 0

Re: Rename a qtree?
by tkaczma＠gryf.net 24 Feb '00

24 Feb '00

And the right answer is (I just tried it on a non-production filer) the qtree is copied as a directory. All the underlying files also change their inodes. Tom On Thu, 24 Feb 2000, Timothy A. McCarthy wrote: > Well, since the qtree exists at the top level anyway, > I would expect the move to be from a client at which > point it would be an illegal move across filesystems. > > --tmac > > tkaczma(a)gryf.net wrote: > > > On Tue, 22 Feb 2000, Eyal Traitel wrote: > > > > > You've did everything fine from my experience. > > > "mv"-ing the qtree's name does not change its inode, so it doesn't change > > > its internal essence as a qtree. > > > > Speaking of which, I've never tried it, but what would happen if you tried > > to move a qtree up the directory hierarchy? Would it be converted to a > > plain ol'e directory, ... ? > > > > Tom > > >

2 1

DLT 8000's
by Jay Orr 24 Feb '00

24 Feb '00

Humm, dunno if there are others who were waiting for DLT 8000 drives/jukeboxes. I know overland had a hold on theirs because of an "engineering hold". That said, I received my Loader Express 810 today, so looks like things have bee resolved. FYI... ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

1 0

Re: Disk drive technology
by mds＠gbnet.net 24 Feb '00

24 Feb '00

On Wed 23 Feb, 2000, "Mohler, Jeff" <jeff.mohler(a)netapp.com> wrote: > 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. This strikes me as very interesting. Until now I'd have reasoned that having two times the bandwidth to the spindles, and the lower latency that implies as well, (having only a proportion of io's in flight on each channel getting in the way of subsequent io's), would have benefitted RAID rebuilding - which is the nastiest case where all stripes must be read, XOR'd-over and blocks written to one disk. Can anyone explain why this would be so? >-- End of excerpt from "Mohler, Jeff" On Wed 23 Feb, 2000, "Bruce Sterling Woodcock" <sirbruce(a)ix.netcom.com> wrote: > Probably not until late this year or next. Fair enough. I imagine they might appear with new product, as it's been a while.. *speculates wildly* > The complete model depends entirely on your filer model, the OS version, > exactly what disks you have, how much memory, what your op mix is, etc. Well, yes, but that's not impossible to plug into an analytical model. I'd also hope that these low-level functions were pretty finely tuned in DOT and not as amenable to radical change.. > The make very little difference. On the order of 10% for most people. > As to WHY, it's because Netapp finely balances their filers for maximum > performance at typical op mixes. They are not like a competitor, which > throws a bunch of hardware at a problem and you are expected to juggle > it to figure out what works. Netapp wants to deliver a simple solution. Yeees. However, there's a touch of faith creeping in here. I don't think it's misplaced, certainly, I think NetApp's are my favourite fileservers for these reasons. I guess I'm just getting more cycnical and evidence-biased as I get older. 8) > There are some performance papers on Netapp's web site that address > some of your questions, and people are free to post their personal > experiences here, but what works for one environment may not work > for another. I would be reluctant to tell you to go out and buy more > drives you don't need if it won't help you. Indeed, me too. But how can we quantitatively be confident ahead of time? > Given that those tables constantly change with the variables (drives, > memory, OS, etc.) rules of thumb is probably the best you can do, unless > you have a few million to spend on testing every possible configuration > and reporting the results. :) Well I know only one place and one group of people that could undertake this, and they sell the boxes. I'd be very susprised if the creators, the engineers, haven't got *something* going on in this line. > There is no best. There is only what is best for your environment. Yes, I'd like to think my 'best' would be considered as predicated on the requirements. I'm not an absolutist, or at least I try not to be. > I would guess slightly better, since the 18 gig drives are probably faster > and you have 2 loops to share the load. However, since the bottleneck > will be the NVRAM, I doubt there will be a major noticeable difference. Ah, I was thinking more about this - the nvram emptying after a cp takes time and that is a key determinant in whether you'll be taking a cp from a cp or not, in turn being a key determinant in user-visible performance. This nvram emptying is surely determined in turn by how rapidly the blocks can be pushed to disk, in which case the speed of the disks and the utility of multiple loops may have some impact, surely? Or is the WAFL so good at distributing writes, and the bandwidth and latency of a single loop such a good match for the nvram that this is a null-term? > I can't consider them if you don't say what they are. I meant, consider whether they're a big factor or not. I was thinking about the two scenarios using the same 10-spindle RAID set size. In the average case the DOT algorithm has to read a few blocks from each of a few disks from a given RAID set, perform the parity XOR over those blocks and the blocks it intends to write, generate the parity, and then write all those new blocks to the disks that it has elected to write to during a cp flush, always including the parity disk. Having fewer spindles means more load per spindle, having fewer loops means more load per loop. How much does the cpu have to do, how much can be DMA'd or otherwise fobbed-off. How little time can you whittle the nvram empty down to? I mean, to be reliable you have to await the completion notice from each disk for each io sent, and I don't believe 18GB disks to be capable of 2x the io's of 9GB disks. Serialising 4 RAID sets on one loop though, even with more disk-ios/second, will probably increase the final-response time to do a full nvram flush by a goodly chunk over the scenario with 2 loops. Given a pathalogical filer setup I could see that increasing the nvram on a write-burdened filer might actually make the problem worse rather than better. How does an admin, especially one not so very interested and aware of these things, approach a filer that is struggling but they don't know why or how to fix it? > You can't know if you got it right unless you have an exact simulation > of your particular ops mix and traffic patterns. Since you don't have > that, then basically you have to use rules of thumb and guess and adjust > when needed. Your environment changes over time, too, so what works > one day may not work another. Mmm, all of which makes me lean toward an analytical model, as it should be more powerful in dealing with these imponderables: plug in the numbers and see how it comes out. Real testing and simulation would make useful checks against such a model, natch. > Maybe it's just me, but while I love having numbers and data, I've always > found such tuning tasks to be far more intuitive and situational. Well, yes, I guess this is because we're human and quite good at dealing with vague and wooly things that nevertheless have patterns that can be extracted with experience. > I mean, if > I have a chart that says such-and-such filer with such-and-such configuration > can handle 200 users, and the filer in my environment overloads at 100 > users, I'm not gonna keep adding users. Conversely, if it runs at 50% and > high cache age with 200 users, I'm not going to worry about adding more. True. Computers aren't as deterministic as they once were and we have to deal with what's really there, however I think there is scope for better models than none-at-all, or 'ask Bruce or Mark, they're good with filers'. I also wouldn't advocate *such* a simple model, at least not alone. > If a filer is overloaded with reads, and I haven't maxxed the RAM yet, I'm > probably going to max the RAM first. Then I'll worry about adding more > disks, and if that doesn't help, I'll know I need to reduce traffic and get > another filer. There are some minor variations to this, of course, but I'm > not going to waste a lot of time beforehand trying to predict exactly how > many disks and how much memory I need when the reality can quickly > change. Estimate, yes, but I won't follow a strict chart. Okey, so perhaps I've overemphasised the model and chart thing, or perhaps you're playing devil's advocate to my credulous believer. As a tool in the salesman's, field engineer's and admin's box'o'tricks though, a configurator other than than the SPEC result-sheets would be a very neat thing to have. And as for wasting a lot of time beforehand - that's rather my point. You wouldn't have to waste time, or a lot of it. So long as the results of a model were within a few tens of percent then your putative admin has gotten close enough to start tuning, rather than transhipping for the larger machine they thought they might need but chickened out of. Better, they find they're peaking just below the capability of the box they ordered and didn't cough up for the big-expensive beast they'd otherwise have bought "just in case". >-- End of excerpt from "Bruce Sterling Woodcock" -- -Mark ... an Englishman in London ...

2 1

Common MIB's wanted.
by Brian Hostetter 24 Feb '00

24 Feb '00

I am looking for a list of common mibs used to monitor filers. Specifically I am looking for cpu percent and number of disk writes. We are looking to do a snap mirror over a wan connection and need to know what kind of bandwidth will be needed. Has anyone compiled a list of commonly used mibs? I will be graphing these results with mrtg if that helps. --Brian

2 1

rsync and nfs file systems
by Greg Kitch 24 Feb '00

24 Feb '00

We have experienced the following problem with the --delete option when using rsync to mirror data... When a directory on the source file system is replaced by a symbolic link with the same name, the directory is deleted from the destination file system by rsync by unlinking the directory without having recursively removed all files/directories under the parent (deleted) directory. The net effect on our local destination file system seems to be that this leaves unreferenced files and directories that must be cleaned up by fsck at some future date. We noticed this by accident simply because we decided to take an rsync-mirrored disk offline and fsck it to check its integrity. Our question is...What will happen to a wafl file system if rsync deletes a directory in this fashion? Does NFS deal with this properly or is it a potential issue? Thanks in advance. Greg Kitch UCLA SEASnet Computing Facility

6 7

RE: Disk drive technology
by Mohler, Jeff 24 Feb '00

24 Feb '00

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 ... :

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters