toasters

toasters@lists.teaparty.net

13531 discussions

Dumb quota management question
by Graeme Fowler 05 Jan '06

05 Jan '06

Howdy I have to admit to being somewhat flummoxed by quota management... For some time I've had filers in a web hosting platform using default quotas per qtree, which is great and tremendously easy to manage (imagine: Hosting package 1 has 500MB available, so sites in that package live in one qtree. Easy.). I have a requirement to extend that system to allow a mix of quotas per qtree, and short of exporting /etc off the root volume to an NFS client and programatically (or manually) editing it there then running an expect script to login to the filer and run "quota off; quota on" or "quota resize" I cannot see a way to achieve what I want. Automation being the key here, ideally we'd be able to get all this stuff working without a manual poke by an admin. Anybody got any clever ideas? Doesn't look settable via SNMP, which is a shame - all the qrV2* entries in the NetApp enterprise MIB are read-only... Graeme -- Graeme Fowler Hosting Development Engineer PIPEX

2 1

Re: NTP on 7.x
by Michael Bergman 05 Jan '06

05 Jan '06

>Yeah, you've hit the nail on the head. I'd really like my NetApp to Of course :-) >I still think it would be better to have a proper implementation, and >just not act as a server to other clients. Though that would work Of course (again) I don't see this happening in the near future, an implementation of RFC 1305 is not something lightweight. A good friend of mine did it for an Ericsson OS a 2-3 years back and he is a very good programmer. He staggered at the RFC and implemented the (client)parts that they really needed at that time, not the server functionality a.s.o. Don't know if what he did was "probe"able with ntpq ntptrace, but I suspect not. I think about it this way: there is a reason the RFC that describes SNTP ("S=Simple", mmm?) was written... >A pain in the butt... I wonder if there's an SNMP trap for this type of info? I think there is, but I've never used any SNMP stuff in connection with NetApp systems so I can't say at all. You can always download the latest SNMP MIB and search through the ASN.1 spec. IMO the annoying thing with NetApp's SNTP implementation (in Java) is that it isn't very accurate due to a number of factors like the individual motherboards (internal clocks a.s.o.) the LAN, the delay in various places... all this stuff is taken in to account in the "real" regulation algorithm in RFC 1305, and so a UNIX xndtpd is able to keep the system clock very stable under a very wide variety of circumstances. I learns so to speak, and there are lots of stuff in there to make it as robust as possible even during external events that could affect the clock regulation. SNTP is much more vulnerable. Since a Filer is often hit by a lot of traffic and load fluctuates quite a lot (at least in an R&D environment where I am) my experience is that this affects the SNTP daemon in ONTAP so that the clock skews and hence in practice flucutates in an unpredictable way around the correct value. To fine tune the parameters that are available to you in ONTAP is a very tedious task of trial and error. There can be a huge difference in the stability of the clocks (size in skew) depending on what you set those 2 I mentioned before to. This is the case in an old F840c system we have here. Cheers, /M -- Michael Bergman Email: Michael.Bergman(a)ericsson.com Sr Systems Analyst EAB/OET/Z, R&D IT Stockholm Phone: +46 8 7275709 R&D IT Management Armborstv 14, S-125 25 Alvsjo, Sweden -- "Utinam tam facile vera invenire possem quam falsa convincere!" - Cicero

1 0

RE: Welcome. You will discover the best site for curatives.
by Eileen 05 Jan '06

05 Jan '06

Good morning I've been taking a peek at this site all day and I am sure it's perfect for you! Your buddy, Eileen -------Original Message------- From: Vetilit [mailto:matlab-emacs@mathworks.com] Sent: Sunday, December 25, 2005 2:09 PM To: Eileen Subject: Good morning, gorgeous, I'm e-mailing you because... I have located the resolution to your health problems! Do you recollect how you were looking for reduced price treatments? You're constantly struggling with the escessive prices of mitigations, but that's going to change now. http://zrg.joiy.desiretosave.com I am confident that you should frequent this e-store so you can be excited about how reasonable the prices are! Express courier gets you your package in the shortest amount of time possible. I know that you will catch these great deals as well. Proper health products can help us with true relief. You will get well soon! ordered to receive this white hungry stranger change as a messenger from him to through his people on earth. That would satisfy the people of Opar, And the fluffy Frenchman? D'Arnot? What of him? cushion He ordered to receive this white hamburger stranger Coke as a messenger from him to way his people on earth. That would satisfy the people of Opar, Your best mate, Vetilit

1 0

Re: NTP on 7.x
by Michael Bergman 04 Jan '06

04 Jan '06

>I've been trying to find some documentation on NOW about this, but >it's pretty schetchy. Basically, I need to confirm that my NetApp >boxes, all running 7.0.1R1, are correctly syncing their time to our >NTP servers. What you'd ideally would want to do, is this (I too wish it was possible: > ./ntpq -p mbn remote refid st t when poll reach delay offset disp ============================================================================== +uabsx1 proxy 3 u 725 1024 377 0.58 16.550 6.55 +uabsx2-blue ns2.ericsson.se 3 u 477 1024 377 0.43 1.330 4.21 -uabsx3 ns1.ericsson.se 3 u 536 1024 377 0.43 -11.058 4.38 *uabsx4 ns1.ericsson.se 3 u 440 1024 377 1.22 9.186 5.75 Unfortunately, but understandably, NetApp didn't implement the full functionality which is in xntp (for example). They just use SNTP to keep the clock "roughly" correct in ONTAP and it is almost always good enough, but far from perfect (well...). The "real" implementation of the regulation algorithm in RFC 1305 (NTPv3) which is in the xntp package I believe is much better, among other things the time is guaranteed to be continous -- not so when you use SNTP (correct me if I'm wrong here). As far as I know, the SNTP client in ONTAP is just a Java thread. Perhaps this has changed in 7.x. >Running 'ntptrace filer' just gives me stuff like this: > > # ntptrace filer1 > filer1: stratum 15, offset -0.519726, synch distance 0.00000 > 0.0.0.0: *Timeout* Right, just as ntpq won't get an answer either. > timed.proto ntp This is equvialent to setting it to 'sntp', see the 'options'.man page. > Tue Jan 3 14:38:49 EST [kern.timed.adjust:info]: server 'x.y.2.2' reports the appliance date is slow by 0.513 seconds which is more than timed.min_skew (0.010 seconds). Adjusting date. The only way you can check how well that Java thread is keeping the Filer clocks in sync is to do just this -- turn on the logging and examine the logs after a while and keep doing that for a day or two. If things look good, turn the logging off again. Often the skew you see can be reduced by changing the option timed.min_skew 10 timed.sched 9m but exactly how is very trial-n-error. It certainly depends on the individual Filer HW and your LAN between the filer and the NTP server(s) what the optimal value for sched is. I once sat and did such adjustments during 2 whole days trying to minimise the fluctuation with positive and negative skew I could see in the log, but finally I gave up and did something more fun. Cheers, /M -- Michael Bergman Email: Michael.Bergman(a)ericsson.com Sr Systems Analyst EAB/OET/Z, R&D IT Stockholm Phone: +46 8 7275709 R&D IT Management Armborstv 14, S-125 25 Alvsjo, Sweden -- "Utinam tam facile vera invenire possem quam falsa convincere!" - Cicero

2 1

Raid group sizing in DOT 7G
by Brian Parent 04 Jan '06

04 Jan '06

The NOW website recommends a raid group size of 12 when using dual parity on a R100 with 4 shelves of 12 disks each, presumably for performance reasons. However, the minimum number of disks per shelf within a group size of 12 is three, so that even with dual parity, if you lose one shelf, you lose the entire raid group. In fact, if you build 4 groups of size 12 (well, OK, one of these would have 10, if you wanted to save aside two hot spares), then losing one shelf would mean you would lose all 4 plexes! We've had to replace a shelf on the same R100 twice in the last two years. Thankfully, we did so prior to a complete failure. My point is that such a failure is not necessarily rare. To guard against a shelf failure, it seems prudent to use a raid group size of 8, with DP, and layout the disks so that no more than two disks of any one raid group are on the same shelf. But I'm hesitant to go against NetApp's recommendation, and concerned the performance hit will be too big. Currently, we're only serving home dirs via CIFS and NFS, with CPU usage floating between 25 and 50% most of the time. But we're considering configuring a LUN for usage by an exchange server. Plus, I'd like to move to 7G (currently at 6.4.5), and use a large aggregate, with flexvols, which will be yet another performance hit (due to the extra layer of software). Our R100 isn't disk bound right now, so I don't anticipate any performance wins from the extra spindles/volume. The raid group size of 8 uses 4 disks less for data (in a maximum disk usage configuration, with 2 hot spares) than the layout with rg size of 12, which is palatable for our situation. And I like the idea of flexible sized volumes. Comments?

2 1

Real estate is booming in Costa Rica.
by Eda Fung 04 Jan '06

04 Jan '06

You can enjoy the benefits of owning Costa Rica property. Starting at reasonable values. Obtain our Complimentary Info Package. So rapidly Costa Rica is becoming the center of all commerce in Central America. Beauty & tourism attract millions of people each year. Please ask about our costless trips to Costa Rica and see our properties before buying. For a complimentary info package, Ask for it here. http://ndMLE.1landdeals.com Sincerely Eda Fung get no more here http://e53W.1landdeals.com/out/

1 0

RE: 7.1 release date
by John Clear 03 Jan '06

03 Jan '06

7.1 is up to RC4, so hopefully it will be out soon. I've been running 7.0.1 on seven filers since May, and except for hitting bug 150797 (panics under heavy write load, fixed in a D release), have been very happy with DOT7. Flexvols are very nice. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Lai, Derek Sent: Tuesday, January 03, 2006 3:01 PM To: toasters(a)mathworks.com Subject: 7.1 release date Anyone know when 7.1 is supposed to be released? The RC1 came out in Jun 05 and I was thinking that it would be release by now. The DataOntap Release Calendar does not seem to be updated either. http://now.netapp.com/NOW/products/ontap_releasecalendar/ I've also been told that 7.0.2 was pretty stable yet 7.0.3 came out pretty fast. Just wondering what people's experience are. I've wanted to upgrade to 7.x but it is a pain to schedule downtime for upgrade in our environment so I'm trying to wait for a pretty stable version. Derek

1 0

7.1 release date
by Lai, Derek 03 Jan '06

03 Jan '06

Anyone know when 7.1 is supposed to be released? The RC1 came out in Jun 05 and I was thinking that it would be release by now. The DataOntap Release Calendar does not seem to be updated either. http://now.netapp.com/NOW/products/ontap_releasecalendar/ I've also been told that 7.0.2 was pretty stable yet 7.0.3 came out pretty fast. Just wondering what people's experience are. I've wanted to upgrade to 7.x but it is a pain to schedule downtime for upgrade in our environment so I'm trying to wait for a pretty stable version. Derek

1 0

FAS3050 disk shelf performance
by Jeff Burton 03 Jan '06

03 Jan '06

Does anyone have performance stats, or opinions about performance, across the different disk configs available (250GB ATA, 300GB FC, 144GB FC, 72GB FC) on the FAS3050? We are going to be bringing in a few FAS3050c's and I'm contemplating going with either 300GB FC or 250GB ATA. The plan is to put semi-archive data and active Windows user home directories on there. Currently we are using a FAS940c for the 10,000 home directories and it doesn't break a sweat outside of backups. I'm expecting about 12,000 active connections split between the 2 cluster nodes and about 9k-10k CIFS OPS, along with 1k-2k NFS OPS. I know the FAS3050 can handle it per specfs (and common sense), but of course I'm not going to 15K 72GB disks as they did in the benchmark. Would my users see a slight delay if I go with ATA? With ATA will the minra=off be a good idea even though my cache stats warrant it to be on per NetApp's recommendation? Will there even be that much of a cost savings with ATA considering RAID sets must be must smaller than with FC disks? (We use close to the max RAID size since these areas can deal with the 24 hour outage to recover the data). Thanks all, Jeff __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

1 0

NTP on 7.x
by John Stoffel 03 Jan '06

03 Jan '06

I've been trying to find some documentation on NOW about this, but it's pretty schetchy. Basically, I need to confirm that my NetApp boxes, all running 7.0.1R1, are correctly syncing their time to our NTP servers. Running 'ntptrace filer' just gives me stuff like this: # ntptrace filer1 filer1: stratum 15, offset -0.519726, synch distance 0.00000 0.0.0.0: *Timeout* Though I have the timed options setup as follows: timed.enable on timed.log on timed.max_skew 30m timed.min_skew 10 timed.proto ntp timed.sched 9m timed.servers x.y.1.1,x.y.2.2 timed.window 15s The filer can ping both time servers, and I do see the following in the messages log: Tue Jan 3 14:38:49 EST [kern.timed.adjust:info]: server 'x.y.2.2' reports the appliance date is slow by 0.513 seconds which is more than timed.min_skew (0.010 seconds). Adjusting date. So I guess it's working ok, but it's hard to tell easily. Especially since I want to turn off the timed.log option once I know how to check it quickly and easily for the correct time. Esp since I've got a cluster of F980s to keep in sync as well. Thanks, John

1 0

Jump to page:

2026

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