toasters August 2002

toasters@lists.teaparty.net

102 participants
113 discussions

RE: # of volumes
by Sam Schorr 07 Aug '02

07 Aug '02

Just to chime in - We run with 2 spares per filer. That is for all our filers, from F840's/12 shelves/36gb drives, F760's/6 shelves/36 gb drives and F760/8 shelves/18gb drives. Since spares are per filer, not volume, the main thing we wanted to avoid was volume failure, which would occur if 2 drives in RAID group failed at the same time. That has never happened, although we almost hit that after moving a filer and 2 disks had a hard time spinning up. We also have 2 because the filers are remote from our offices, so the "insurance" or piece-of-mind are worth it to us. --sam -----Original Message----- From: Tom Yergeau [mailto:yergeau@yergeau.net] Sent: Wednesday, August 07, 2002 1:20 PM To: toasters(a)mathworks.com Subject: RE: # of volumes I generally liked to keep one spare per 14 drives. Since spares are global and can be used by any volume having a "x spares per volume" didn't make sense to me, so I figured out how many drives I was comfortable with having one spare for, and arbitrarily decided on 14. Mad Dog

1 0

RE: # of volumes
by Tom Yergeau 07 Aug '02

07 Aug '02

I generally liked to keep one spare per 14 drives. Since spares are global and can be used by any volume having a "x spares per volume" didn't make sense to me, so I figured out how many drives I was comfortable with having one spare for, and arbitrarily decided on 14. Mad Dog

1 0

RE: # of Volumes.
by Heiland, David Joseph (Dave) 07 Aug '02

07 Aug '02

We usually run with one spare for our filers, regardless of the number of disks. When I recently asked for a quote from Netapp, the sales contact suggested 3 spares for a 10 shelf system and that it was risky to run with just 1, which we've never heard from them before. I'm not sure why its risky. We've been running this way for years, with no issues. With next day shipment of replacement disks it doesn't seem to be an issue So how many spares do people use/recommend? Dave -----Original Message----- From: Matt Musgrove [mailto:matt.musgrove@thales-is.com] Sent: 07 August 2002 17:11 To: devnull(a)adc.idt.com Cc: toasters(a)mathworks.com Subject: Re: # of Volumes. If it was me I would use 2 disks as vol0 and not keep any business critical data on it, and use the remaining disks in vol1 (with 9 disks per RAID group) with 1 disk as spare. You would be very unlucky to need 2 spares! I have 1 spare for my 28 disks. Reconstruction time shouldn't be much of an issue should it? Matt devnull(a)adc.idt.com wrote: > I am trying to decide on the number of volumes for our F810 which has a > DS14 shelf(FC-AL), with 14 36G drives. > > By default Ontap puts 8 disks in a RAID group. > > I guess i am trying to figure out if > > * I should have 2 volumes vol0 and vol1, one with 8 disks and one with 5 > disks and i have ONE spare for both the volumes > (Is this safe in terms of ratio of disks used to spares ? ) > > * Have 2 volumes(6 + 6) and 2 spares > > * Have 1 volume with 13 disks and 1 spare. (reconstruction time on > failed disk would be high, and i dont know if there will be performance > issues esp in calculating parity etc) > > Other suggestions are welcome too. > > Many Thanks, > > Regards, > > /dev/null

2 1

Re: Snapshot storage
by Alek O. Komarnitsky (N-CSC) 07 Aug '02

07 Aug '02

> From owner-toasters(a)mathworks.com Wed Aug 7 12:54 MDT 2002 > From: Dirk Schmiedt <Dirk.Schmiedt(a)munich.netsurf.de> > > > 2) The command "filestats" should help you to find those "bad" users? > It can also produce tables and HTML output. :-) > If you modify example 3 for your wanted limitations (limitation on > mod-ages) you should find the "bad" users. > > Best regards from Munich/Germany. > Dirk Schmiedt > ... can be found as NetApp-Trainer on www.qskills.de > > > > NAME > > filestats - collect file usage statistics > > SYNOPSIS > > filestats [ ages ages] [ timetype {a,m,c,cr}] [ sizes sizes] snapshot > snapshot_name [ style style] [ volume volume_name] > > DESCRIPTION > > The filestats utility provides a summary of file usage within a > volume. It must be used on a snapshot, and the only required argument is > the snapshot name. The > volume name defaults to "vol0" if not specified. If the volume you > are examining is named otherwise, specify the name explicitly. This looks cool ... and awful familier! ;-) I wrote a Perl program that parses a filesystem(s) and generates similar types of reports on pretty much everything reported by stat(). So if you want another "flavor" of this, check out yadu available at: http://www.komar.org/ -> Misc. Tech Stuff -> yadu Some sample output can also be seen there - almost eery how similar! ;-) alek

1 0

Unhang a tape drive?
by WILLIAMS VIGIL, NIS-3/DEC MS-D440, 505-667-3587 07 Aug '02

07 Aug '02

Hi: Anyone know if (and how) a hung tape drive hanging off of an F840 running V6.1.2 can be reset without rebooting the fileserver? I got impatient with a tape erase, power-cycled the DLT-7000 autoloader, and removed the tape. Now the fileserver responds with "mt: open of tape nrst0a failed" whenever a command is set to it. Reinserting a tape does nothing. Ws Williams E. VIGIL 505-667-3587 Pager: 104-4728 -------------------------------------------------------- "... description is not explanation and when it comes to primary causes science explains nothing." D. Grinspoon "Science without relgion is lame, religion without science is blind." Albert Einstein

1 0

Snapshot storage
by stefan.holzwarth＠zentrale.adac.de 07 Aug '02

07 Aug '02

Hi, since about 1 year we have a F760 with now 3 TB of Raw Storage. During that time a snap reserve of 10% was sufficent. (4 a day, 7 per week, 4 per month) But now i found that on one volume the snapshot demand was suddenly growing. After looking around i found some users using their quota for doing backups to our filer. That backups were deleted after 2 weeks and replaced by new backups. This led to a large amount of data invisible to the quota system, but wasting a lot of snapstorage. How can i deal with that situation and especialy: how to find users/qtrees with a lot of changed data? Regards Stefan holzwarth ---------------------------------------------------------------------------- -- Stefan Holzwarth ADAC e.V. (Informationsverarbeitung - Systemtechnik - Basisdienste) Am Westpark 8, 81373 München, Tel.: (089) 7676-5212, Fax: (089) 76768924 mailto:stefan.holzwarth@zentrale.adac.de

2 1

Summary: Master and Slave NIS Servers
by devnull＠adc.idt.com 07 Aug '02

07 Aug '02

Many thanks to all who replied. Mike Horwath Fox, Adam Lance R. Mehle Leonard, Roger Geoff Hardin options nis.server nis_master,nis_slave,* This will check the master, the slave, then broadcast. Thanks very much, Regards /dev/null devnull(a)adc.idt.com

5 5

ONTap version 6.1.3R2 in dev environments
by Clawson, Simon 07 Aug '02

07 Aug '02

Hello, Is anyone using 6.1.3R2 in an RCS environment? I am planning to go up from the very old 5.3.6R2, and have had nasty experiences before, so wanted to test the water a bit.. Also, are there any other nasty/worrying issues with 6.1.3R2? Thanks Simon Simon Clawson TEL:- +44 (0)1635 811409 HDL Designer Series Team Systems Administrator FAX:- +44 (0)1635 810108 Mentor Graphics Ireland Ltd (UK Branch) MOB:- +44 (0)7788 716071 Rivergate London Road Newbury Berkshire RG14 2QB

1 0

RE: Snapshot storage
by Muhlestein, Mark 07 Aug '02

07 Aug '02

Starting with the 6.2 release, we added a feature to help with this problem, at least for CIFS clients. If you turn on the cifs.snapshot_file_folding.enable option, the filer will compare newly written files with the same file in the last snapshot, and any identical blocks will not result in new allocation of space. The effect of this is to only allocate storage for blocks that have changed. This is also useful when you are doing SnapMirror, since only the changed blocks have to be transmitted. Naturally, there is some performance impact to this, but it seems to be a good tradeoff for many customer environments. Mark Muhlestein -- Network Appliance Engineering > -----Original Message----- > From: stefan.holzwarth(a)zentrale.adac.de > [mailto:stefan.holzwarth@zentrale.adac.de] > Sent: Tuesday, August 06, 2002 1:08 AM > To: toasters(a)mathworks.com > Subject: Snapshot storage > > > Hi, > > since about 1 year we have a F760 with now 3 TB of Raw Storage. > During that time a snap reserve of 10% was sufficent. (4 a > day, 7 per week, > 4 per month) > But now i found that on one volume the snapshot demand was > suddenly growing. > > After looking around i found some users using their quota for > doing backups > to our filer. > That backups were deleted after 2 weeks and replaced by new backups. > This led to a large amount of data invisible to the quota system, but > wasting a lot of snapstorage. > > How can i deal with that situation and especialy: how to find > users/qtrees > with a lot of changed data? > > Regards > Stefan holzwarth > > > -------------------------------------------------------------- > -------------- > -- > Stefan Holzwarth > ADAC e.V. (Informationsverarbeitung - Systemtechnik - Basisdienste) > Am Westpark 8, 81373 München, Tel.: (089) 7676-5212, Fax: > (089) 76768924 > mailto:stefan.holzwarth@zentrale.adac.de >

5 4

excess ip fragments from client cause denial of service
by Marion Hakanson 06 Aug '02

06 Aug '02

Folks, Here's an FYI, in case anyone else runs into this issue. And perhaps you may feel moved to contact NetApp about it as well, if your filers might be similarly affected: Over the weekend we experienced several instances where clients (mostly NFS) were unable to transfer data to & from the filer. These outages were intermittent, but would last up to a half-hour. To make a long story short, we traced the problem to a single NFS client running RedHat-7.3. Disconnecting the errant client from the network caused the problems to cease immediately. RedHat has released a fix, discussed at: http://rhn.redhat.com/errata/RHBA-2002-110.html Once the immediate problem was solved (and similar client systems patched), we still were disturbed that a single buggy client (100Mbit) could take out our F820 with gigabit ethernet (there was almost no other filer activity at the time of the incidents). We entered a case with NetApp support, who directed me to their already-existing bug/RFE #72769, along with their recommendations ("fix the client"). The bug is not scheduled to be fixed. Since we are on a mostly-open network, and since we do not control the software installed on all our client machines, we are very concerned about the potential for future denial-of-service incidents, whether accidental or deliberate. As a result, we have asked NetApp to fix the bug. As I said, I'm mostly posting this item here so others can be on guard against the issue -- it was certainly unexpected by us. Regards, -- Marion Hakanson <hakanson(a)cse.ogi.edu> CSE Computing Facilities

1 0

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 August 2002