toasters

toasters@lists.teaparty.net

13520 discussions

RE: Migration to NetApp 740 from AlphaServer 2100
by Smith, Gil 25 Mar '99

25 Mar '99

this paper, on our external WWW, describes what WAFL does regarding directory hashing, http://www.netapp.com/technology/level3/3006.html -----Original Message----- From: Strange, Steve [mailto:steve.strange@netapp.com] Sent: Thursday, March 25, 1999 4:31 PM To: 'Joanna Gaski'; toasters(a)mathworks.com Subject: RE: Migration to NetApp 740 from AlphaServer 2100 If you're used to AdvFS' performance with large directories, I think you'll be quite happy with WAFL in that regard. Last I knew, I don't think AdvFS did any directory hashing at all, so having 10K or more files in a single directory was not much fun. Steve -----Original Message----- From: Joanna Gaski [mailto:jgaski@WPI.EDU] Sent: Thursday, March 25, 1999 9:14 AM To: toasters(a)mathworks.com Subject: Migration to NetApp 740 from AlphaServer 2100 2) Large directory constraints Also, for the user areas, what are the practical constraints on the number of files in a directory? I am most used to AdvFS, under which large directories can be slow to open and read, if a user tries to do something like tab completion on a filename in a directory of 1000 entries. Will I see the same kind of behavior with WAFL, and if so, does anyone have a good suggestion on breaking up the user space? We were thinking of using directory structure organization (nothing at logical partition level) for this.

1 0

RE: Migration to NetApp 740 from AlphaServer 2100
by Strange, Steve 25 Mar '99

25 Mar '99

If you're used to AdvFS' performance with large directories, I think you'll be quite happy with WAFL in that regard. Last I knew, I don't think AdvFS did any directory hashing at all, so having 10K or more files in a single directory was not much fun. Steve -----Original Message----- From: Joanna Gaski [mailto:jgaski@WPI.EDU] Sent: Thursday, March 25, 1999 9:14 AM To: toasters(a)mathworks.com Subject: Migration to NetApp 740 from AlphaServer 2100 2) Large directory constraints Also, for the user areas, what are the practical constraints on the number of files in a directory? I am most used to AdvFS, under which large directories can be slow to open and read, if a user tries to do something like tab completion on a filename in a directory of 1000 entries. Will I see the same kind of behavior with WAFL, and if so, does anyone have a good suggestion on breaking up the user space? We were thinking of using directory structure organization (nothing at logical partition level) for this.

1 0

RE: NDMP backup speeds
by Smith, Gil 25 Mar '99

25 Mar '99

Hi, Not sure but... You may not have the 8MB DLT7000. An early revision only had 4MB I believe which didn't provide the throughput expected so the device was rev'd by Quantum and given 8MB. Check with your tape vendor. -----Original Message----- From: mgx(a)spruce.lsd.ornl.gov [mailto:mgx@spruce.lsd.ornl.gov] Sent: Thursday, March 25, 1999 2:18 PM To: Jason D. Kelleher Cc: mgx(a)spruce.lsd.ornl.gov; Will Harper; NetApp Toasters E-mail" Subject: Re: NDMP backup speeds i'd love to see 35-45GB/hour. the netapps are on a 100MB full-duplex lan. we're using budtool 4.5/ndmp and the tapedevice is nrst0a (70GB/compressed). this is what the netapp thinks about the tape drive/scsi adapter: slot 2: SCSI Host Adapter 2 (QLogic ISP 1040B) Firmware Version 2.26 Clock Rate 60MHz. 4: QUANTUM DLT7000 1E48 <------------------------ In-Band Enclosure Services 0 Swap Events, 0 Enclosure Events where is my problem i wonder? -- michael On Thu, Mar 25, Jason D. Kelleher wrote: > In message <19990325105303.A7088(a)avatar.lsd.ornl.gov>, mgx(a)spruce.lsd.ornl.g > ov writes: > >fwiw, i'm backing up my two F520's via ndmp to a DLT7000 and i'm averaging > >about 11.7GB/hour. > > > >-- michael > > That sounds slow. We're readying an F740 for production and our > tests show ~3MB/s (~11GB/hr) over a 110mb full-duplex connection to > a Sun "backup server" with a DLT4000 jukebox. That's theoretical > max on a DLT4000 and still plenty of room on the network. Haven't > tried multiple concurrent dumps yet, so I'm not sure how well that > would scale. You should see about triple the throughput to a > single DLT7000. > > jason > >

1 0

Logical Volumes or Partitions
by Will Harper 25 Mar '99

25 Mar '99

Can anybody tell me what the following max/mins are, with a default 740: Maximum number of logical volumes, or partitions Maximum size of a logical volume or partition Maximum PRACTICAL size of a logical volume or partition Minimum size of a logical volume or partition Minimum PRACTICAL size of a volume or partition A URL pointer would also be helpful if anybody has one. Thanks Will Harper, MCSE InfiNet, Norfolk, VA

2 1

New 'raid add' replacement
by Dane Jasper 25 Mar '99

25 Mar '99

We just had a minor panic as our filer filled - the 'raid add' command is gone. For your reference, if you've moved to the new OS, here's the replacement command: vol add vol0 1 This presumes you have one volume, which is the default. "vol status" will give you a list. This will add any spare disk to the volume - you can also specify which one to add if you'd like. A handy trick if you run out of space is to reduce your snap reserve space by a few percent while the spare disk is added to the volume. Adding the disk takes a bit of time, so this space stolen from snapshots will keep you running. -- Dane Jasper Sonic (707)522-1001 (33.6kbps) (707)522-1000 (Voice) mailto:support@sonic.net http://www.sonic.net Key fingerprint = A5 D6 6E 16 D8 81 BA E9 CB BD A9 77 B3 AF 45 53

2 1

IETF Version 4 Mail Alias
by beepy＠netapp.com 24 Mar '99

24 Mar '99

Hi. In a meeting a couple weeks ago of the NFS Version 4 Working Group of IETF, it was proposed that we need more "user" involvement in the discussions on the mail alias and within the work group. I mentioned this alias as a source of users, and promised to send out an invite. This is your invite. Please go to: http://www.ietf.org/html.charters/nfsv4-charter.html for information on the charter of the working group, draft requirements/design considerations, and draft specification, and instruction on how to join the mail discussion group. The web page also lists the location of the mail archives. If you have any questions after reading the material on the web feel free to throw out to the mail list or me. Brian Pawlowski

1 0

manual nightly snapshot rollover, or 'snap redo'
by Todd C. Merrill 24 Mar '99

24 Mar '99

Is there a way to *manually* rollover snapshots retaining the .number sequence? That is, without doing this in a script: rsh filer snap delete vol0 nightly.N rsh filer snap rename vol0 nightly.N-1 nightly.N ... rsh filer snap rename vol0 nightly.0 nightly.1 rsh filer snap create vol0 nightly.0 Reason is, I need to do a few things just before midnight and then a few things after midnight, but the things before midnight might not finish exactly before midnight when the filer makes the nightly snapshot, and I need them to be included in the read-only snapshot. So, I'd like to do something like: 1. do my pre-midnight commands 2. rsh filer snap nightly 3. do my post-midnight commands ("commands" are things done from an NFS mount to manipulate the data/files on the filer, not commands executed on the filer itself) and have step 2 do all the numbering bookkeeping for me, according to the snap schedule. Probably not, since that would mean some other switch to tell the filer *not* to the automagic snapshots. But, I'd thought I'd ask anyway, in case anyone has any better ideas. Orrrrr, how about a resnap? I could let the filer make its nightly.0 snapshot as usual, and then a few minutes after midnight, execute something like: rsh filer snap redo vol0 nightly.0 Oooo, I like that better. That helps with other snapshot manipulations we use, instead of: rsh filer snap create new rsh filer snap rename image old rsh filer snap rename new image rsh filer snap delete old Would this be useful enough to more than just me for an RFE? Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: NetApp/Auspex killer?
by Adams, Christian 24 Mar '99

24 Mar '99

Hey Tom - If you propate over an IP network on the front end of the head, then yes there is a performance penalty. If you have the disk shelves handle the propagation, then you can do some interesting things which do not create a performance penalty. But then you're talking about putting intelligence down into the disk shelves themselves. /Christian Adams > -----Original Message----- > From: tkaczma(a)gryf.net [SMTP:tkaczma@gryf.net] > Sent: Monday, March 22, 1999 4:47 PM > To: toasters(a)mathworks.com > Subject: RE: NetApp/Auspex killer? > > > > On Mon, 22 Mar 1999, Mohler, Jeff wrote: > > > Your DR solution should PUSH data out constantly, not request it > > remotely every 60 seconds, then if a snapcopy fails for that period, it > gets > > thrown away on the remote side...two lost minutes of data. > > That's true for your application, but I don't want to mirror my disks > across the country even every 60 seconds. Once every couple of minutes > or hours is perfect for me. If you truly mirror your disks the latency > associated with data propagation will kill the performance. > > Tom

3 2

Re: One tape *drive* supported on 5.1.2???
by mds＠gbnet.net 24 Mar '99

24 Mar '99

On Tue 23 Mar, 1999, Kelly Wyatt <saskww(a)wnt.sas.com> wrote: > We have just been informed by Network Appliance that only *one* tape *drive* > per adapter is supported on 5.1.2. (We have been running with 1 adapter/2 > drives since August on 4.3 and then 5.0 and now on 5.1.2 since we upgraded.) Not true. Or, if it is then we've been breaking the rules for a while. Well actually we were breaking the rulees for a while, but now we've got a really weird, really unique buggette. But when we squich that, we'll be back to breaking the rules. 8) > > Was anyone else aware of this? This came about due to a call we placed when > removing a stuck tape rebooted the filer... > ------- > > Kelly Wyatt, saskww(a)wnt.sas.com <mailto:saskww@wnt.sas.com> > Integrated Solutions Consulting > SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 > (919) 677-8000 X4279 (Voice) / (919) 677-4444 (FAX) > http://www.sas.com <http://www.sas.com> >-- End of excerpt from Kelly Wyatt

1 0

RE: One tape *drive* supported on 5.1.2???
by Melvin, Grant 24 Mar '99

24 Mar '99

Hi Kelly, I'm sorry to say that you were given the wrong response from NetApp today, so let me clear this up and apologize for any inconvenience caused. When engineering looked at the config on your site a *wrong* assumption was made and it was thought that there were 2 tape devices each on separate cards, which is not a supported config. The good news is that your configuration *IS* supported since you have 2 tape devices on a single SCSI tape adapter. In our next Data ONTAP release 5.3 we will be supporting 2 SCSI tape adapters on the F760 & F630 platforms. And since we support 2 tape drives per SCSI adapter this will allow upto 4 tape drives to be supported on these filers or 2 tape devices each on separate cards. Cheers, Grant -----Original Message----- From: Kelly Wyatt [mailto:saskww@wnt.sas.com] Sent: Tuesday, March 23, 1999 1:08 PM To: toasters(a)mathworks.com Subject: One tape *drive* supported on 5.1.2??? We have just been informed by Network Appliance that only *one* tape *drive* per adapter is supported on 5.1.2. (We have been running with 1 adapter/2 drives since August on 4.3 and then 5.0 and now on 5.1.2 since we upgraded.) Was anyone else aware of this? This came about due to a call we placed when removing a stuck tape rebooted the filer... ------- Kelly Wyatt, saskww(a)wnt.sas.com <mailto:saskww@wnt.sas.com> Integrated Solutions Consulting SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 (919) 677-8000 X4279 (Voice) / (919) 677-4444 (FAX) http://www.sas.com <http://www.sas.com>

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