toasters

toasters@lists.teaparty.net

13515 discussions

ufsdump/ufsrestore and Solaris 2.7
by Dave Atkin 12 Jul '99

12 Jul '99

Sun seem to have "improved" ufsdump/ufsrestore in Solaris 2.7 and they are now so good that they won't talk to a tape drive on a filer. The two utilities now seem to require a feature of the RMT protocol that NetApp don't bother to implement - the "S" (status) command. I've reported the problem to NetApp and they are going to add it to their wish list of enhancements. In the meantime a workaround seems to be to copy over the 2.6 binaries of ufsdump/ufsrestore which seem to work better. Dave Atkin ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin(a)york.ac.uk ------------------------------------------------------

1 0

32-bit vs. 64-bit FC-AL adapters
by Brian Tao 10 Jul '99

10 Jul '99

I just noticed this on our clustered pair of F740's. The on-board (slot 0) adapter is listed as a 64-bit device, while the secondary adapter (slot 1, connecting to its partner's disk shelf) is listed as a 32-bit device. Is this right? NetApp Release 5.2.2: Sat Apr 17 04:15:20 PDT 1999 System ID: 0016791871 (nfs3); partner ID: 0016791820 (nfs4) slot 0: System Board Memory Size: 512 MB slot 0: FC adapter: isp2100 (chip rev. 3, 64-bit) Firmware rev: 1.15.2 Host Loop Id: 119 FC Node Name: 2:000:00a098:035eff Cacheline size: 8 FC Packet size: 2048 7 Disks: 119.0GB 1 shelf with Eurologic EDM SCSI Host Adapter 0b In-Band Enclosure Services slot 0: Ethernet Controller e0 MAC Address: 00:a0:98:00:50:46 (auto-100tx-fd-up) slot 1: FC adapter: isp2100 (chip rev. 3, 32-bit) Firmware rev: 1.15.2 Host Loop Id: 119 FC Node Name: 2:000:00e08b:00c089 Cacheline size: 8 FC Packet size: 2048 7 Disks: 119.0GB 1 shelf with Eurologic EDM slot 3: Ethernet Controller e3 MAC Address: 00:c0:95:fa:cd:7b (auto-100tx-up) slot 8: Interconnect adapter slot 9: NVRAM Memory Size: 32 MB -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

(no subject)
by Mohler, Jeff 08 Jul '99

08 Jul '99

1 0

ForSale F330
by Wifehnter1＠aol.com 08 Jul '99

08 Jul '99

F 330 128megs Ram 2 SCSI controllers 4 meg Cache 4 drive rack consisting of 28 4.3 gig drives This unit is only 18 months old! Craig R. von Esch

2 1

Re: NIS Problems
by dnb＠ccs.neu.edu 07 Jul '99

07 Jul '99

"Sivo, Peter " <peter.sivo(a)netapp.com> writes: > Is this the reason that you all do this? I thought it was because > Corp IT never had reliable NIS services and you were binding to a > server that you knew was "blessed" and stable? On the whole, our NIS servers are rock solid. We bind to a specific IP address for the reasons Jay stated (namely we know not to trust NIS, and especially NIS broadcasts as far as we can throw it/them). > The questions, though, is that are people going to continue to hardcode in a > server, so even if I had 5 NIS servers/slaves per network, it wouldn't make a > difference? There are two separate issues here: 1) The current NetApp NIS client code (especially when run with a single server specified as we do) isn't particularly robust. If we could specify 5 IP addresses instead of one, and the failover went smoothly, this would help quite a bit. Plus you could specify hosts in a different broadcast domain (perhaps on a more protected subnet). 2) NIS will never be secure, but being able to tell a filer not to pay attention to any one who pretends to be your NIS server (via specifying addresses) is a good thing. Not the perfect thing, but better than the current status quo. Besides the scenario Jay proposed where the rogue server is available before the real one after a power blink, you could also probably throw enough of a denial-of-service against either the filer or the NIS server to cause the filer to attempt a rebind. If your filer rebinds to the rogue... To directly answer your question, it's the sixth NIS server on your net (that you didn't put there) that's the real bummer. Peace, dNb eagerly looking forward to the new NIS code

1 0

Re: NIS Problems
by Devi Nagaraj 06 Jul '99

06 Jul '99

Hi, We are revamping our NIS client implementation, one of the changes being an option to specify multiple preferred NIS servers. Please get in touch with NetApp for more information on the availability of these changes. Thanks, -Devi At 09:49 AM 7/6/99 -0600, Graham C. Knight wrote: >Sean Hinchey wrote: > >> >> Does anyone have any recommendations or are we stuck with less stable NIS >> client? >> >> -Sean > >After battling this same problem for months i finally >put some hooks into my makefile.nis that copies >the files locally to all our filers and turned >off NIS. You are correct, Netapp's are not good >NIS clients. > >Graham > >

1 0

RE: NIS Problems
by sirbruce＠ix.netcom.com 06 Jul '99

06 Jul '99

On 07/06/99 11:15:39 you wrote: >Is this the reason that you all do this? I thought it was because Corp IT never >had reliable NIS services and you were binding to a server that you knew was >"blessed" and stable? Hey, NIS services were stable when *I* left Netapp. If you've had problems since then drop me a line and I'll be happy to help out. >Anyways, I'm the Corp IT Manager watching over the LAN, and a boatload of >services, including NIS at this time. I know that Duane is installing new NIS >servers/slaves per network over in San Tomas to improve the quality of our NIS >services. This isn't going to help NIS stability unless it is done correctly. In any case the files should be copied locally to the filers anyway, as was the case when I left Netapp and as others have suggested. If you really want to improve QoS you'll need to realize that some things that the filer does (such as NIS client functionaltiy) are not reliable enough for some networks, and one such network may be yours. >The questions, though, is that are people going to continue to hardcode in a >server, so even if I had 5 NIS servers/slaves per network, it wouldn't make a >difference? Unless you control *every* device on those networks (and I suspect you don't), not hardcoding for a server (although it should be *multiple* servers) is just asking for trouble. It all depends on what your environment is. You can also run into problems with loading... balancing by hand has many advantages. And you always have the local files to fall back on. Jay has it exactly right, and sounds like he speaks from experience. These are practical things you learn that are difficult to teacher younger incoming admins who think things should just work. :) Perhaps someday LDAP can eliminate all of this mess. Bruce

1 0

RE: NIS Problems
by Sivo, Peter 06 Jul '99

06 Jul '99

Is this the reason that you all do this? I thought it was because Corp IT never had reliable NIS services and you were binding to a server that you knew was "blessed" and stable? Anyways, I'm the Corp IT Manager watching over the LAN, and a boatload of services, including NIS at this time. I know that Duane is installing new NIS servers/slaves per network over in San Tomas to improve the quality of our NIS services. The questions, though, is that are people going to continue to hardcode in a server, so even if I had 5 NIS servers/slaves per network, it wouldn't make a difference? (no, we aren't doing 5, ;) but I just threw that out to make a point) Thanks. -----Original Message----- From: Jay Sekora [mailto:jay@ccs.neu.edu] Sent: Tuesday, July 06, 1999 9:43 AM To: toasters(a)mathworks.com Subject: Re: NIS Problems "Graham C. Knight" <grahamk(a)ast.lmco.com> wrote: > After battling this same problem for months i finally > put some hooks into my makefile.nis that copies > the files locally to all our filers and turned > off NIS. You are correct, Netapp's are not good > NIS clients. Another thing to bear in mind is the risk of somebody dropping a laptop on the net with an NIS server claiming to serve your NIS domain. (Think laptop on battery power after a power outage - the legit NIS server is likely to come up after the NetApp, so the intruder's laptop is the only thing there to reply to NIS requests.) If somebody can do that, then they own all the files on the filer. For this reason, we don't broadcast for an NIS server, but explicitly bind to a particular server out of /etc/rc . The problem is that if that machine ever goes down, even for a short time, the NetApp loses its binding to it and we have to re-bind to it by hand. Copying the files to the NetApp would definitely be more robust. (IP spoofing is another potential problem, of course.) -j. Jay Sekora <jay(a)ccs.neu.edu> Unix Systems Administrator Northeastern University College of Computer Science

1 0

Re: NIS Problems
by Jay Sekora 06 Jul '99

06 Jul '99

"Graham C. Knight" <grahamk(a)ast.lmco.com> wrote: > After battling this same problem for months i finally > put some hooks into my makefile.nis that copies > the files locally to all our filers and turned > off NIS. You are correct, Netapp's are not good > NIS clients. Another thing to bear in mind is the risk of somebody dropping a laptop on the net with an NIS server claiming to serve your NIS domain. (Think laptop on battery power after a power outage - the legit NIS server is likely to come up after the NetApp, so the intruder's laptop is the only thing there to reply to NIS requests.) If somebody can do that, then they own all the files on the filer. For this reason, we don't broadcast for an NIS server, but explicitly bind to a particular server out of /etc/rc . The problem is that if that machine ever goes down, even for a short time, the NetApp loses its binding to it and we have to re-bind to it by hand. Copying the files to the NetApp would definitely be more robust. (IP spoofing is another potential problem, of course.) -j. Jay Sekora <jay(a)ccs.neu.edu> Unix Systems Administrator Northeastern University College of Computer Science

1 0

NIS Problems
by Sean Hinchey 06 Jul '99

06 Jul '99

Over the past few months, for various reasons, our F630 has lost it's connection to our NIS slave. Pretty well every time this happens the filer decides not to serve either NFS or CIFS clients(usually CIFS). The only way to get the machine to serve data again is to run ypset and have it bind to a new NIS slave or(as a last resort) reboot the filer and have it automatically discover another slave. Shouldn't the filer bind itself to a new NIS slave after some timeout period without any intervention? We're currently running DOT 5.3.1 but have seen the problem on several 5.2 versions. Does anyone have any recommendations or are we stuck with less stable NIS client? -Sean

2 1

(no subject)
by Krzysztof Miller 05 Jul '99

05 Jul '99

subscribe toasters

1 0

Recommended formula to use to determine "maxfiles" size.
by Mike Ball 01 Jul '99

01 Jul '99

Can anyone recommend a formula to use to determine "maxfiles" size? We are using mostly 64k file size html text docs. Thank you, Mike Ball > -----Original Message----- > From: owner-toasters(a)mathworks.com > [mailto:owner-toasters@mathworks.com]On Behalf Of sirbruce(a)ix.netcom.com > Sent: Saturday, June 26, 1999 9:53 AM > To: toasters(a)mathworks.com > Subject: Re: Increasing "maxfiles" and its effect on performance > > > On 06/25/99 16:40:20 you wrote: > > > >What affect will increasing the "maxfiles" have on the read/write > >performance on a volume? We are currently running Data Ontap ver > 5.2.2P1 on > >a F740. > > Very little, unless you set it to an extremely high value that is far, > far more than you need. (Like, I dunno, 1 billion?) Even then I doubt > it would be very noticeable unless the filer were heavily loaded. If > you are running out of files on the filer (which is not unusual if the > default setting was conservative and you've added a lot of space), you > shouldn't think twice about upping the maxfiles value. > > I would guess (one of the Netapp WAFL experts could correct me on > this) that since maxfiles reserves some space in the filesystem > for metdata, that slowly increasing maxfiles over time (rather than > in large increases at once) might "fragment" the metadata file across > the filesystem, thus hurting performance somewhat. But then I seem > to recall that even when you increase maxfiles, this space is not > necessarily allocated right away, so maybe it doesn't matter and > they'll only grow in a fragmentary fashion anyway. (Fragmentation > is not really much of a problem on Netapp's anyway and is only > really noticeable on very large files.) > > Bruce > >

1 0

Re: HELP URGENTLY !!!
by John Tatar 01 Jul '99

01 Jul '99

Four Simple Steps Are Required Here> 1. Read the tape library manual 2. Read the netapp manuals. 3. If you still have questions - check the SCSI FAQ at http://www.cis.ohio-state.edu/hypertext/faq/usenet/scsi-faq/top.html 4. Finally, if you still have questions pay a qualified engineer to install it for you. JT

1 0

HELP URGENTLY !!!
by Alexandre Gomes (r7043c) 30 Jun '99

30 Jun '99

Tom Wike wrote: > > Alexandre, > Stupid question: what SCSI connector is the jukebox on the NetApp > attached to?? It cannot be the ones labled 9a or 9b, it needs to be > connected to the one labled SCSI 0, on the bottom of the box, next > to the console and diag serial ports. > > Alexandre Gomes (r7043c) writes: > > > > It is what he gives me when I running probe-scsi command : > > > > > > root@araras[38]<bin>: probe-scsi -h paje > > Copyright (c) 1990-1999 by PDC probe-scsi BudTool 4.5 > > SCSI Bus 0 > > SCSI Bus 1 > > SCSI Bus 2 > > Target 1 > > Unit 0 Removable Jukebox Device BHTi Q2 1.50 > > Target 3 > > Unit 0 Removable Tape Quantum DLT4000 CD5A > > Target 4 > > Unit 0 Removable Tape Quantum DLT4000 CD5A > > root@araras[39]<bin>: > > > > -- > Tom Wike > UNIX System Administration > FDAO Productivity Infrastructure > Texas Instruments, Inc. > > E-Mail: t-wike(a)ti.com Regular Mail: 7839 Churchill Way > Phone: (972) 917-1252 M/S 3984 > Fax: (972) 917-3891 Dallas, TX 75251 > Pager: (888) 512-8040 > > E-Mail my Pager: 5128040(a)skytel.com > Or: http://www.skytel.com/Paging/pageme.cgi?pin=5128040,2 > ---------------------------------------------------------------------- Good morning everybody, Good Morning Tom and Paul, I was looking on my Network Appliance Server and I need to connect my jukebox robotics on the SCSI 0 of my network like Tom told me. The problem is that the cable has 68 pins and the SCSI 0 of my Network Appliance has 50 pins. I must use a cable that convert of 68 to 50 pins or what I have to do ???? Before it was connect on SCSI 9b and it has 68 pins..... Thanks !!!

3 4

LDAP and Unix
by Lex Beijk 30 Jun '99

30 Jun '99

Hi everybody I am working at TNO-FEL, a physics-lab in the Netherlands. We are setting up a multi-platfom environment with a LDAP-directory server for integrated user and resources management. Working with the Netscape directory-server we can replicate between NT and LDAP for the Netscape environment. I have done some testing with the Luke Howard LDAP-client for Unix (Luke also has written rfc2307, by which you can map NIS attributes on LDAP attributes) to run NIS requests over LDAP. It is running very well. My questions to you are: - how can I integrate te Netapp-filers in this (They don't have a LDAP client YET) - Is there anayone else, who has done something with LDAP and Unix ( and maybe Netapp filers) - Who will migrate to LDAP-based directory service' when it is available. Pls, give some reply to this group. Thanks ...

1 0

RE: HELP URGENTLY !!!
by Aiello, Tony 30 Jun '99

30 Jun '99

What model filer is this? If it has a 50 pin connector then it's supporting a narrow bus only. If you use a 68 to 50 pin converter then physically it'll make the connection, but data speed will suffer. A 50 pin connector supports only an 8 bit SCSI bus while a 68 pin supports a 16 bit SCSI bus. Tony -------------------------- mailto:taiello@netapp.com Ph:(408)822-6515 > -----Original Message----- > From: Tom Wike [mailto:t-wike@ti.com] > Sent: Wednesday, June 30, 1999 5:38 AM > To: Alexandre Gomes (r7043c) > Cc: Paul Lupa (ra5507); lista de discussao > Subject: HELP URGENTLY !!! > > > Alexnadre, > Yes you will have to get a new SCSI cable, that would be my > suggestion. > > Alexandre Gomes (r7043c) writes: > > > > Good morning everybody, > > Good Morning Tom and Paul, > > > > > > I was looking on my Network Appliance Server and I need > to connect my > > jukebox robotics on the SCSI 0 of my network like Tom told me. The > > problem is that the cable has 68 pins and the SCSI 0 of my Network > > Appliance has 50 pins. I must use a cable that convert of > 68 to 50 pins > > or what I have to do ???? > > Before it was connect on SCSI 9b and it has 68 pins..... > > > > Thanks !!! > > > > -- > Tom Wike > UNIX System Administration > FDAO Productivity Infrastructure > Texas Instruments, Inc. > > E-Mail: t-wike(a)ti.com Regular Mail: 7839 Churchill Way > Phone: (972) 917-1252 M/S 3984 > Fax: (972) 917-3891 Dallas, TX 75251 > Pager: (888) 512-8040 > > E-Mail my Pager: 5128040(a)skytel.com > Or: http://www.skytel.com/Paging/pageme.cgi?pin=5128040,2 > ---------------------------------------------------------------------- >

1 0

ufsrestore
by chris＠cecil.muscat.com 30 Jun '99

30 Jun '99

Yesterday I dumped a load of data from our filer to a DLT7000 using: dump 0lfbn nrst0a 63 spong / then typing the directories to backup. Tape started rolling and after dumping the right amount of data stopped. Took the tape down to a 3rd party to do some benchmarking on our data and tried to restore it on a solaris 2.6 box but whatever we tried we couldn't get the data off. At one point we managed to get a directory structure but no files off. As far as I can remember we decided that the correct options were: ufsrestore -xfb /dev/rmt/1u 126 does that seem plausible? I'm now a little concerned that I wouldn't be able to restore my data via a sun box should the worst happen. -- Chris Good - Muscat Ltd. The Westbrook Centre, Milton Rd, Cambridge UK Phone: 01223 715006 Mobile: 07801 788997 http://www.muscat.com

1 0

Re: Disk Controller Failures
by Brian Tao 30 Jun '99

30 Jun '99

On Mon, 28 Jun 1999, Shaun T. Erickson wrote: > > My experience with NetApp has not been very good, yet I know that > many others have few if any troubles with them. While it didn't > leave me with a particularly good first impression, I'm hoping that > this F740 will meet our needs and improve our experience with > NetApp. We have a couple of clustered F740's in pre-production testing, and immediately after reading your original message about FC-AL controller failure, I found this on one of them: Sun Jun 20 01:00:02 EDT [nfs3: raid_scrub_admin]: Beginning disk scrubbing... Sun Jun 20 01:18:50 EDT [nfs3: isp2100_timeout]: 0a.2 (0xfffffc0000abf258,0x28:00155d88:0040,0/0,1189063/0/0,9156358/0): command timeout, aborting request Sun Jun 20 01:18:55 EDT [nfs3: isp2100_timeout]: 0a.4 (0xfffffc0000b8a118,0x28:00155dc8:0040,0/0,1186670/0/0,9156358/0): command timeout, aborting request Sun Jun 20 01:19:00 EDT [nfs3: isp2100_timeout]: 0a.5 (0xfffffc0000aea4f8,0x2a:0000a3f8:0008,0/0,2129956/0/0,9156358/0): command timeout, aborting request Sun Jun 20 01:19:06 EDT [nfs3: isp2100_timeout]: 0a.6 (0xfffffc0000adf3d8,0x28:0000a3f0:0008,0/0,2131151/0/0,9156358/0): command timeout, aborting request Sun Jun 20 01:19:14 EDT [nfs3: isp2100_timeout]: Resetting ISP2100 in slot 0a Sun Jun 20 05:34:04 GMT [nfs3: cf_main]: Cluster monitor: takeover of partner enabled Sun Jun 20 05:34:08 GMT [nfs3: rc]: de_main: e0 : Link up. Sun Jun 20 01:34:08 EDT [nfs3: rc]: saving 165M to /etc/crash/core.0.nz ("WAFL hung.") Sun Jun 20 01:34:34 EDT [nfs3: rc]: relog syslog Sun Jun 20 01:19:14 EDT [nfs3: isp2100_timeout]: Resetting ISP2100 in slot 0a Sun Jun 20 01:34:34 EDT [nfs3: rc]: NetApp Release 5.2.2 boot complete. Last disk update written at Sun Jun 20 01:00:07 EDT 1999 I then tried forcing a disk failure to see if my disk reconstruction would produce the same results yours did. It did, except mine never went beyond 4%. It didn't crash either... it just sort of stayed "stuck". I was able to force a cluster takeover from the other filer, and it continued the reconstruction, but something else messed up which caused the takeover filer not to assume the IP address of it's twin: Tue Jun 29 22:16:49 EDT [nfs3: raid_disk_admin]: Unload of disk 0a.5 (S/N LK95551800002941HH3U) has completed successfully. Tue Jun 29 22:17:10 EDT [nfs3: rshd_0]: Option raid.reconstruct_speed changed on one cluster node Tue Jun 29 22:21:46 EDT [nfs3: isp2100_timeout]: 0a.3 (0xfffffc0000b514b8,0x28:00155cc0:0040,0/0,52562/0/0,521771/0): command timeout, aborting request Tue Jun 29 22:21:51 EDT [nfs3: isp2100_timeout]: 0a.4 (0xfffffc0000b49ad8,0x28:00155c40:0040,1/0,28029/0/0,521771/0): command timeout, aborting request Tue Jun 29 22:21:56 EDT [nfs3: isp2100_timeout]: 0a.6 (0xfffffc0000b50618,0x28:00155cc0:0040,0/0,193448/0/0,521771/0): command timeout, aborting request Tue Jun 29 22:22:04 EDT [nfs3: isp2100_timeout]: Resetting ISP2100 in slot 0a And then on the partner filer: Tue Jun 29 22:27:49 EDT [nfs4: rc]: Cluster monitor: takeover initiated by operator Tue Jun 29 22:27:49 EDT [nfs4: cf_main]: Cluster monitor: UP --> TAKEOVER Tue Jun 29 22:27:49 EDT [nfs4: cf_takeover]: Cluster monitor: takeover started Tue Jun 29 22:27:50 EDT [nfs4: de0]: de_main: e3 : Link down. Check cable. Tue Jun 29 22:28:02 EDT [nfs4: disk_admin]: Resetting all devices on ISP2100 in slot 1 Tue Jun 29 22:28:09 EDT [nfs4: raid_disk_admin]: Label write on 1.5 (S/N LK95551800002941HH3U) failed. Tue Jun 29 22:28:09 EDT [nfs4: raid_disk_admin]: One disk is missing from volume partner:vol0, RAID group 0. A "hot spare" disk is available and the missing disk will be reconstructed on the spare disk. Tue Jun 29 22:28:10 EDT [nfs3/nfs4: cf_takeover]: ifconfig: 'e0' cannot be configured: no partner. Tue Jun 29 22:28:10 EDT [nfs3/nfs4: cf_takeover]: relog syslog Tue Jun 29 22:21:56 EDT [nfs3: isp2100_timeout]: 0a.6 (0xfffffc0000b50618,0x28:00155cc0:0040,0/0,193448/0/0,521771/0): Tue Jun 29 22:28:10 EDT [nfs3/nfs4: cf_takeover]: relog syslog Tue Jun 29 22:22:04 EDT [nfs3: isp2100_timeout]: Resetting ISP2100 in slot 0a Tue Jun 29 22:28:10 EDT [nfs4: cf_takeover]: WARNING: 1 error detected during network takeover processing Tue Jun 29 22:28:10 EDT [nfs4: cf_takeover]: WARNING: Some network clients may not be able to access the cluster during takeover Tue Jun 29 22:28:10 EDT [nfs4: cf_takeover]: Cluster monitor: takeover during ifconfig_2 failed; takeover continuing... Tue Jun 29 22:28:10 EDT [nfs4: cf_takeover]: Cluster monitor: takeover completed Anyway, this sounds and tastes like a FibreChannel controller failure too. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Re: Disk Controller Failures
by Brian Tao 30 Jun '99

30 Jun '99

On Sun, 27 Jun 1999 sirbruce(a)ix.netcom.com wrote: > > When I think about all the pieces of hardware and software that have > to work correctly just for a system to boot, let alone transmit this > message over a modem out to the world, I am sometimes amazed any of > it works at all. Sadly, most customers do not share this sense of wonder, perhaps precisely because it is an "appliance" that is supposed to "just work" like your toaster or your telephone. Not that we haven't had our problems with filers, but for the most part, Netapp maintenance is effortless, amazing considering the amount of stuff that has to happen in behind the scenes. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

RE: Help with Network Appliance configuration ???
by Benn, Paul 29 Jun '99

29 Jun '99

Sr. Alexandre, You appear to have the tape library connected to the wrong SCSI bus (the card in slot 9). It should be connected to the onboard SCSI which is bus 0. Boa Sorte, Paul Benn Network Appliance -----Original Message----- From: Alexandre Gomes (r7043c) [mailto:r7043c@email.sps.mot.com] Sent: Tuesday, June 29, 1999 5:53 AM To: lista de discussao Subject: Help with Network Appliance configuration ??? Hi, I'm installing budtool( version 4.5) on a Solaris machine to operate a jukebox robotics connected to the Network Appliance ( F230) to do backups. On the installation he gaves the following message ( I will use NDMP protocol) : The spt and sjb drivers are capable of communicating with devices on any SCSI bus attached to this host. These drivers need to know on which bus the jukebox is attached. The first bus (e.g. esp0) is number 0, the second bus is number 1, and so on. Only a number between 0 and 7 will be accepted. Please enter the number of the SCSI bus for the jukebox: Could someone help me, How I discover the SCSI bus where my jukebox is connected on Net App.I execute the sysconfig on the NDMS and it says : paje> sysconfig -v NetApp Release 4.3.4: Wed Apr 22 16:25:06 PDT 1998 System ID: 0016785098 slot 0: System Board 90 MHz (NetApp System Board Ia rev-b) Firmware release: 1.9_i Memory Size: 192 MB slot 0: SCSI Host Adapter 0 (QLogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. In-Band Enclosure Services 0 Swap Events, 0 Enclosure Events slot 0: Ethernet Controller e0 MAC Address: 00:a0:98:00:0d:59 (100tx) slot 6: NVRAM (NetApp NVRAM I) Revision: D2 Serial Number: 7882 Memory Size: 8 MB Battery 1 Status: 100% (3.26v) Battery 2 Status: 100% (3.24v) slot 9: Dual SCSI Host Adapter (NetApp SCSI Adapter II) SCSI Host Adapter 9a (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. 0: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) 1: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) 2: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) 3: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) 4: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) 5: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) 6: SEAGATE ST39173WC 4218 Size=8.3GB (17783240 blocks) In-Band Enclosure Services 0 Swap Events, 0 Enclosure Events SCSI Host Adapter 9b (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. 3: Quantum DLT4000 CD5A 4: Quantum DLT4000 CD5A In-Band Enclosure Services 0 Swap Events, 0 Enclosure Events Please, help to answers this question !!! Thanks, Alexandre Gomes

1 0

Quite nice; Cure Autism Now Foundation
by Philip Thomas 29 Jun '99

29 Jun '99

http://biz.yahoo.com/bw/990628/ca_network_3.html It's quite commendable of NetApp's "good citizen" gesture. ---philip thomas

1 0

administrivia
by fubar＠mathworks.com 29 Jun '99

29 Jun '99

FYI, posts made to the list between Sunday evening and just now (10am EDT) will not be appearing in the toasters archive. I seem to recall there being a few posts, but not many. This past weekend was spent moving our servers to our new office building. In the move a few changes were made, and a few things broken. :-) K.

1 0

Re: Disk Controller Failures
by sirbruce＠ix.netcom.com 27 Jun '99

27 Jun '99

On 06/25/99 12:50:17 you wrote: > >Hi there, > > We recently encountered a disk controller failure on one of our >data servers (not on our Netapp). The problem was that this failure was >not a complete failure of the drive itself, but rather the controller >started to >die slowly. (i.e. handles some request sometimes and other times who >knows?) >As a result, this caused our entire filesystem to become corrupt and we lost >some >of our data as a result. Although this filesystem was mirrored, this did >not help us >at all, as it was considered a logical error in the filesystem and not a >hardware problem. > > My question is that should this occur on a Netapps (this may even >apply to >any other Enterprise server) would it cause the entire filesystem to go >corrupt and >cause partial or complete data loss as in this case? I would have to say yes, it's *possible*, but the controller would have to fail in a very odd way; not simply not responding the some requests (that would be caught), but executing some and not others (but claiming it did) or misordering commands or something like that. I would think this kind of error would be very rare. Perhaps the controller you had is particularly prone to those sorts of errors; one advantage of Netapp is you're using controllers they themselves have partially designed and tested. Bruce

2 1

Re: Increasing "maxfiles" and its effect on performance
by sirbruce＠ix.netcom.com 26 Jun '99

26 Jun '99

On 06/25/99 16:40:20 you wrote: > >What affect will increasing the "maxfiles" have on the read/write >performance on a volume? We are currently running Data Ontap ver 5.2.2P1 on >a F740. Very little, unless you set it to an extremely high value that is far, far more than you need. (Like, I dunno, 1 billion?) Even then I doubt it would be very noticeable unless the filer were heavily loaded. If you are running out of files on the filer (which is not unusual if the default setting was conservative and you've added a lot of space), you shouldn't think twice about upping the maxfiles value. I would guess (one of the Netapp WAFL experts could correct me on this) that since maxfiles reserves some space in the filesystem for metdata, that slowly increasing maxfiles over time (rather than in large increases at once) might "fragment" the metadata file across the filesystem, thus hurting performance somewhat. But then I seem to recall that even when you increase maxfiles, this space is not necessarily allocated right away, so maybe it doesn't matter and they'll only grow in a fragmentary fashion anyway. (Fragmentation is not really much of a problem on Netapp's anyway and is only really noticeable on very large files.) Bruce

1 0

Increasing "maxfiles" and its effect on performance
by Mike Ball 25 Jun '99

25 Jun '99

What affect will increasing the "maxfiles" have on the read/write performance on a volume? We are currently running Data Ontap ver 5.2.2P1 on a F740.

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