toasters

toasters@lists.teaparty.net

1 participants
13515 discussions

New F700 Series
by sirbruce＠ix.netcom.com 19 Aug '98

19 Aug '98

Okay, so the F700 series has been announced. I am, however, left with many questions: 1. Are these models Alpha based? Pentium? Other? What are the relative speeds, so I can compared to the previous models? The F760 appears to be about 50% faster than the F630, but I'm sure that's spread out over several components, not solely due to the CPU. 2. When can we expect even preliminary SPEC SFS numbers? 3. When can we expect Netbench numbers? One would guess they would be in the range of 30MB/second. 4. What is the maximum network connectivity? The spec sheet mentions 8 PCI slots, but I don't know if that includes those for tape and/or FC-AL. Bruce

9 8

Re: New F700 Series
by Guy Lauterbach 18 Aug '98

18 Aug '98

At 11:44 AM 8/18/98 -0500, Sirbruce wrote: >>| 4. What is the maximum network connectivity? >They don't say whether all 8 slots are really "free" and it >doesn't mention 64bit slots, either. The F760 actually has 9 pci slots, of which one is dedicated to the nvram card (just like in other filer models). Of the remaining 8 slots, 3 are 32-bit pci and 5 are 64-bit pci. And, yes, the power switch is in the back! Hope that helps! rgl

1 0

Re: New F700 Series
by sirbruce＠ix.netcom.com 18 Aug '98

18 Aug '98

On 08/18/98 11:41:33 you wrote: >| 4. What is the maximum network connectivity? The spec sheet ^^^^^^^^^^^^^^ emphasis mine >| mentions 8 PCI slots, but I don't know if that includes >| those for tape and/or FC-AL. > >fcal is built in, as is 10/100 ethernet, dual power supplies, cable-less >motherboard. I don't know if the nvram is still a card or not (rather, >I cannot remember). I think the 760 had 4 64bit pci slots, so you >would be limited to 4 gigabit NIC's. > >http://www.netapp.com/products/level3/f700series_techspecs.html > >Has all the data. As I said, I *read* the spec sheets. They don't say whether all 8 slots are really "free" and it doesn't mention 64bit slots, either. Your answers were what I was looking for, but don't say that they're in the spec sheet, 'cause I looked there first and they weren't. Bruce

1 0

RE: /vol and client automounter paths.
by Kelly Wyatt 14 Aug '98

14 Aug '98

We seem to have no problem mounting stuff that is exported as /vol/volN. The automounter mounts it as /nfs/filer/vol/volN. That is OK. It works with /vol/vol0 anyway. And we have a few filers with /vol/<user defined name> that we know works. I realize this is probably not a filer problem and that this won't happen if you have a single volume filer. I just wanted to let people know what we have experienced using the "mixed style" exports. This might come in handy should they ever have a multi-volume filer. We have had no such problems with our single volume 5.01 machines. We are just fortunate (?) that this happened just before the regular monthly outage and we can change the filer exports and reboot all workstations this weekend. Kelly ----- Kelly Wyatt, saskww(a)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

1 0

RE: /vol and client automounter paths.
by Kelly Wyatt 14 Aug '98

14 Aug '98

I'm curious about this. We have had a situation where our automounter daemon (amd on hpux10.20) has been chewing up CPU trying to resolve a mount to a filer: Aug 13 21:30:00 build034 amd[4993]: No mount point for /remote/ronco/vol/vol1 - skipping Aug 13 21:30:00 build034 amd[552]: "/nfs/ronco.unx.sas.com" on /remote/ronco sti ll active Aug 13 21:34:27 build034 amd[5426]: No mount point for /remote/ronco/vol/vol1 - skipping Aug 13 21:34:27 build034 amd[552]: "/nfs/ronco.unx.sas.com" on /remote/ronco sti ll active This is showing up *hundreds of thousands of times* in the syslogs, and is causing out automounter daemon to take a 50-60% of the CPU across hundreds of workstations, if not thousands and filling disks with syslog entries. Our exports are: / -root=server2:server3 /home -root=server2:server3 /builddir -root=server2:server3 /vol/vol1 -root=server2:server3 Note that /vol/vol1 does exist. So, I read on the NOW site what I have pasted below. The second to the last paragraph is what seems to stand out to me - "If you use paths of the / form for export points in the root volume, the automounter might not be able to mount directories in other volumes, or it might create new directories in your root volume to serve as mount points." We are planning on changing the exports to: /vol/vol0 -root=server2:server3 /vol/vol1 -root=server2:server3 this weekend and rebooting all machines (and changing references from /nfs/filer/builddir to /nfs/filer/vol/vol0/builddir...). We are *really* hoping that this fixes the amd problem. Any thoughts about whether this is going to work or not... or if something else might be causing our automounter problem???? Note that we have this problem only with the filer ronco. The other filers at 5.01 do not have /vol/vol1 yet. Thanks, Kelly Data ONTAP 5.0R2 Export point notation Both / and /vol/vol0 identify the root volume. You can use either form to list exported directories in /etc/exports. For most purposes, the two forms are equivalent. However, when an NFS client requests a list of export points from the filer (for instance, as the result of a showmount -e command), the filer returns the paths exactly as they appear in /etc/exports. This affects the behavior of the automounter. For example, if toaster exports /, the automounter mounts the root volume for toaster on /net/toaster, but if it exports /vol/vol0, the root volume appears in /net/toaster/vol/vol0. If you have more than one volume, use paths of the /vol/vol0 form for all your export points in the root volume. If you use paths of the / form for export points in the root volume, the automounter might not be able to mount directories in other volumes, or it might create new directories in your root volume to serve as mount points. Note that /vol/ is not a valid syntax for filers

2 1

Re: /vol and client automounter paths.
by nevets＠eng.adaptec.com 13 Aug '98

13 Aug '98

Ummm, as far as the manual was concerned /vol/vol0/home should be accessible over the automounter as /home, likewise anything else on vol0. From what I read (which may be completely incorrect ;) only for volumes other than vol0 are you required to use the /vol/vol# syntax. I've set up a number of filer here and I'm referencing all homes and projects from /vol/vol0/dirname as filer:/dirname successfully. Soooo, looking at one of my filers... All directories in /vol/vol0 are "mirrored" in / under /net/filername, and also available over the automounter that way. --Steve > From jdavis(a)CS.Arizona.EDU Thu Aug 13 14:56:53 1998 > Date: Thu, 13 Aug 1998 14:19:13 -0700 (MST) > From: Jim Davis <jdavis(a)CS.Arizona.EDU> > To: toasters(a)mathworks.com > Subject: /vol and client automounter paths. > MIME-Version: 1.0 > > Due to some sloppy RTFMing, I apparently missed that as part of moving > from one F520 to another I need to change every fscking client's home > automounter map entries from > > user server:/home/user > > to > > user server:/vol/vol0/home/user > > (Or maybe try some symlink tricks but I'd really like to avoid that for > efficiency and general non-grossness.) > > <freak out>Aww, nutbunnies!<freak in> > > There appears to be some backward-compatibility mode iff (and the manual > isn't crystal-clear on this) you upgrade from 4.x to 5.x. Then apparently > server:/home/user will still work. > > But (he whines) what would've been so awful about making that a special > case for (unupgraded) 5.x too? Rejiggering n+1 automounter maps is not my > idea of a good time, and for various embarrassing reasons it's not just a > matter of updating the NIS master or anything that simple. > > Not to mention explaining to certain people here who have /net/server/home > hardwired into their heads that they'll have to use the oh-so-intuitive > /net/server/vol/vol0/home instead... > __________________________________________________________________ From the SUN of: Steve D'Aurora ESN - Engineering Systems and Network administrator phone: 408 957-2351 email: nevets(a)eng.adaptec.com Adaptec Milpitas, CA, USA __________________________________________________________________

2 1

New Netapp models soon?
by Brian Tao 12 Aug '98

12 Aug '98

What's this I hear about F7xx-series filers? Double the performance of the F630 at the high end (the F760), fiber channel, clusterable, etc.? Rumours or facts? Give up the gory details! :) -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

4 4

rsync and stale nfs file handles
by Alexei Rodriguez 12 Aug '98

12 Aug '98

Hey folks. I have run into a problem I had not seen before and need some other eyeballs to look at it. We have some staging servers out in our field offices with local disk. The folks at these offices are editing content throughout the day. At intervals throughout the day, the content from the staging servers gets pushed to our hosting facility via rsync. The problem we are seeing is that apache is getting quite a few " reason: stat: Stale NFS file handle (errno = 151)" errors. We are using Solaris 2.5.1 servers and mount the filer with v3 (udp). We invoke rsync with: -a -b --delete -e $SSH $local $remote Is there a way for us to get around the client side caching of file handles? Or is there a different problem? Has anyone done something like this before? Help? Thanks. Alex

1 1

Tape drives
by pradeep＠algorithmics.com 12 Aug '98

12 Aug '98

Hi there, I would like to know if it is at all possible to attach a DLT7000 tape drive using a single-ended SCSI interface to an F520 filer. Please let me know if this is doable. Thanks. Pradeep. -- Pradeep Subramaniam, Snr. Sys. Admin. | You can fool some of the people Algorithmics Inc., Toronto, On., Canada.| all the time, but not all the e-mail: pradeep(a)algorithmics.com | people all the time. phone: (416) 217 4203 | - Yet another brilliant philosopher fax: (416) 971 6263 | *******************************************************************************

2 3

NetApp network aliasing / gigabit redundancy
by Daniel Quinlan 12 Aug '98

12 Aug '98

We're considering replacing the fast ethernet (some single cards, mostly quad cards) on all of our multi-homed NetApps with a single gigabit ethernet interface. We think it's a good idea, except for the pain associated with ending use of old IP numbers for deprecated interfaces. Does anyone have experience with aliasing interfaces to allow use of ex-interfaces on NFS servers, especially on a NetApp? Also, since I'm nervous about exercising rarely-used code paths on these things, I'd like to hear about anyone's experiences with address aliasing on NetApps in general. Finally, can anyone tell me about network redundancy on NetApps hooked up with gigabit card(s)? We're using 3Com switches. Dan

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