toasters

toasters@lists.teaparty.net

13531 discussions

Re: Solaris and NetApps
by sthaug＠nethelp.no 10 Nov '97

10 Nov '97

> One of my clients is complaining that performance between Solaris 2.5.1 > systems (mainly Ultra 1s and 3000s) and an F210 is pretty damn awful. (The > 210 is to be used for syslog, so the amount of disk writes isn't *that* > high). > > I got him to switch to NFS v2 and UDP to get around timeout issues, but > performance still sucks. We use "hard,intr,bg" for an NFS v2 mount with a NetApp connected to a 2.5.1 Ultra box with a crossover cable. Works like a charm for us, as a News spool. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

4 5

Re: Solaris and NetApps
by mer＠world.evansville.net 10 Nov '97

10 Nov '97

On Nov 10, 12:30pm, Marc Nicholas wrote: > One of my clients is complaining that performance between Solaris 2.5.1 > systems (mainly Ultra 1s and 3000s) and an F210 is pretty damn awful. (The > 210 is to be used for syslog, so the amount of disk writes isn't *that* > high). > > I got him to switch to NFS v2 and UDP to get around timeout issues, but > performance still sucks. > > The entire LAN fabric is full duplex 100baseT switched through Cisco > Catalyst 5000s. Can I ask a dumb question? Is his 2.5.1 box running full duplex 100BT? We experienced the same symptom with an Ultra 2. We also noticed lots of late collisions on the Cisco EtherSwitch 1200 uplink port serving the Ultra. When we switched the port to half duplex, the problem went away. On a related topic, I spent a fruitless half hour trying to figure out how to configure our Ultra to do full duplex -- anyone know how to do it? -- Marc Rouleau VP and Chief Technology Officer Voice: (812) 479-1700 Fax: (812) 479-3439 Network WCS http://www.networkwcs.com

3 3

New IBM drives
by joe＠vpop.net 10 Nov '97

10 Nov '97

Does anyone know if the new Hi Capacity IBM drives will work with toasters? IBM to unveil disk technology: http://www.news.com/News/Item/0,4,16190,00.html?dtn.head Thanks, -joe ============================================================================= * NewsHub: Updated every 15 minutes/24 hours a day! * http://web.NewsHub.com/

1 0

Solaris and NetApps
by Marc Nicholas 10 Nov '97

10 Nov '97

One of my clients is complaining that performance between Solaris 2.5.1 systems (mainly Ultra 1s and 3000s) and an F210 is pretty damn awful. (The 210 is to be used for syslog, so the amount of disk writes isn't *that* high). I got him to switch to NFS v2 and UDP to get around timeout issues, but performance still sucks. The entire LAN fabric is full duplex 100baseT switched through Cisco Catalyst 5000s. Anyone got any ideas why things might be so sloooow? :-/ What mount options are the rest of you using with Solaris? Thanks, -marc --- Marc Nicholas - Hippocampus OSD Inc. 416 979 9000 - fax: 416 979 8223 - http://www.hippocampus.net 125 John St. - Suite #100 - Toronto - Ontario - M5V 2E2 - CANADA "Inter/Intra/Extra[net] consulting, services, hardware and software sales"

3 2

Re: Possible software cause for total data loss?
by sirbruce＠ix.netcom.com 08 Nov '97

08 Nov '97

On 11/08/97 01:39:24 you wrote: >> The fact that it continues to be the same machine leads me to think >> that swapping out the NVRAM card and/or the SCSI cards may be in >> order. > > I managed to capture the original kernel panic only once: "PANIC: >../common/wafl/nvlog.c: 1088: Assertion failure", although your guess >is as good as mine why all subsequent reboots panic in disk.c. The >suggestions I've received from Netapp support all involve getting a >core dump over to them for analysis. Unfortunately, the filer never >gets up to the point where it can do a savecore. :( Well, if the NVRAM error caused something bogus to be written to disk, creating bad metadata in the unclean shutdown, then this could trigger another bug in the disk code where it reads the disks and recomputes parity. Or the NVRAM itself may actually have caused the error. It could even be that the disk.c message is misleading and is really talking to the NVRAM at that point. Alternatively, the bad data on the disk could have been caused by bad SCSI, but I admit this is less likely. Frankly there's no way to know without seeing the code (even the best modular code can have subtle dependencies and side effects that make it appear the error is something other than where it is). I'm surprised support did not understand that your filer was actually DOWN, and thus you couldn't get the core. There are ways to boot from floppy to dump the NVRAM and fix the filesystem; I would press them for advice in that direction if they didn't understand your problem fully. In any case, like I said, if it consistently is happening to this machine you could replace the NVRAM card, re-install it all over again, and see if it happens again. Bruce

1 0

Re: Possible software cause for total data loss?
by sirbruce＠ix.netcom.com 08 Nov '97

08 Nov '97

On 11/07/97 18:43:45 you wrote: >On Tue, 4 Nov 1997 sirbruce(a)ix.netcom.com wrote: >> >> 1. Filer crashes while running - Reboot >> 2. Filer crashes replaying NVRAM - Reboot >> 3. Filer crahses again while replaying NVRAM - Reboot >> 4. Filer realizes it's failed replaying NVRAM twice in a row, so >> it flags it as bad, dumps the NVRAM, and - Reboot > > After replacing all the disks with new ones, the same crash popped >up again on that filer, after two more days of heavy reads and writes. >I rebooted it ten times in a row... kernel panic every time on >"../driver/disk/disk.c:2633: Assertion failure" right after the >"Recomputing parity in NVRAM" message (I assume that means it never >gets around to replaying the WAFL logs?). Did it ever mention dumping the NVRAM? Or is it always crashing before it ever replays NVRAM? I think I understand what you're saying above but you didn't mention any other error messages from the other reboots so I wanted to be sure. > Call Netapp tech support, was told an on-call engineer would call >back... haven't heard anything back yet. *sigh* It sounds like the disks themselves have become corrupted in such a way that it's dying on initialization... they will probably have you boot off floppy to wack the filesystem, and/or dump the NVRAM manually. The fact that it continues to be the same machine leads me to think that swapping out the NVRAM card and/or the SCSI cards may be in order. But, I'm no expert support person and I don't have access to the code, so Netapp may have already figured out what this bug is and the solution is totally different. :) Bruce

2 1

Alpha future
by Gregory M. Paris 08 Nov '97

08 Nov '97

Any thoughts on what the Intel/Digital settlement means to NetApp and its customers? It sure looks (to me anyway) as though the Alpha is dead. -- Gregory M. Paris Senior Systems Administrator Bose Corporation Email: paris(a)bose.com The Mountain, MS#258 Phone: +1 508 766-4072 Framingham, MA 01701-9168 FAX: +1 508 820-0173

9 10

Re: Possible software cause for total data loss?
by sirbruce＠ix.netcom.com 07 Nov '97

07 Nov '97

On 11/04/97 10:48:56 you wrote: >> During the pre-production testing of one of our F230 filers, we >discovered a problem with one of them that we wereonly able to fix by >rebuilding the RAID (and thus losing whatever OS and data was on the >filer). Be careful with precise words. "Rebuilding the RAID" is something that happens when a disk fails, and it doesn't cause you to lose your data. If you mean, say, re-initialize the filesystem, then that makes more sense. > Part of the tests consisted of filling up the filesystem via NFS >and NDMP copies from a host Ultrasparc. Three other F230's of >identical configuration survived the tests, but the remaining F230 >experienced the following panic four times: > >PANIC: ../common/wafl/nvlog.c: 1088: Assertion failure > > > I will be running the NVRAM diagnostics later today to see if they >turn up anything. However, more distressing is the behaviour of the >Netapp upon reboot: You are correct that it's probably a software bug, although running the NVRAM diagnostics (and perhaps re-seating the card) is certainly something you should try. >[... other boot messages deleted...] >Loading filesystem. >Recomputing parity in NVRAM > >PANIC: ../driver/disk/disk.c:2633: Assertion failure. > >version: NetApp Release 4.2a: Fri Sep 5 09:36:36 PDT 1997 >cc flags: 3 >dumping core: .......... Old core present on disk --- not dumped. >Program terminated >ok > > > At this point the filer is inaccessible, and I can't find a way to >get it up and running. Why was it "innaccessible"? Just reboot it again. >Is there a way to flush the NVRAM or ignore an >existing dump... some way to turn NFS back on so the data can be >retrieved. Yes... just keep rebooting and evetually it will throw away the NVRAM. As for "ignore an existing dump", no I don't think so, but that's okay... the fact that the filer can't dump core isn't preventing you from rebooting (although I think it does prevent the auto-reboot). >Booting the kernel off floppy doesn't help because it >tries to replay the WAFL logs too, and another panic occurs. When NVRAM is corrupt, you have to keep rebooting several times. The sequence is usually like this. 1. Filer crashes while running - Reboot 2. Filer crashes replaying NVRAM - Reboot 3. Filer crahses again while replaying NVRAM - Reboot 4. Filer realizes it's failed replaying NVRAM twice in a row, so it flags it as bad, dumps the NVRAM, and - Reboot 5. Filer comes back up, probably in degraded mode, and is thus reconstructing. If there has been filesystem damage it may crash here again, and reboot again. If you still can't get it up (it may say "Filesystem may be scrambled) or you can't get it up for any length of time, you should call Netapp support and have them help you with the procedure for fixing the filesystem (wack) from floppy. The real kickers in this are you have to "know" that it'll do 2 and 3, and won't just keep rebooting forever. I think I've seen cases where it takes more than that for it to jettison NVRAM, but I can't be positive. This made since from a design point of you, to only give up if you fail to replay the NVRAM twice in a row, but in reality it seems that with most bugs (not all) if it fails once, it'll fail again. Furthermore, once it decides NVRAM is corrupt, it tries to dumb core and reboot *AGAIN*. The design thought here was again a sound one - get a core dump so we can look at the corrupt NVRAM and figure out what's wrong. However, in reality, if you've gotten to this point you've probably already crashed, and dumped core once, so you'll never be able to see this faulty NVRAM core... at least not until Netapp starts supporting multiple cores. The other bad thing about this sequence is you have several crashes stemming from the original crash, and possibly even several different bugs, but you'll never be able to get the cores from anything but the first one. I think there is a way to bypass some of this by booting off floppy and jettisoning the NVRAM manually, but given the time involved you are probably better off just rebooting the filer again. >The only >way around I've found is to wipe out the filesystem and start over >again (obviously not the optimal solution). Ideas? The above should help. Bruce

2 2

netapp NFS server crash by FreeBSD client [w/patch] (fwd)
by Tom Yates 07 Nov '97

07 Nov '97

this just in from the bugtraq mailing list. i figure *some* of us probably aren't on that. i also don't expect thousands of people to be trying this exploit, but given that it's just gone out on bugtraq, if your toaster panics anytime soon, you might want to bear this in mind. needless to say, i haven't tried it. anyone want to have a go? Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C ---------- Forwarded message ---------- Date: Wed, 5 Nov 1997 21:34:00 -0800 From: "Dmitry Kohmanyuk [KOI8-R] �� " <dk(a)GENESYSLAB.COM> To: BUGTRAQ(a)NETSPACE.ORG Subject: netapp NFS server crash by FreeBSD client [w/patch] this is only relevant to those using NetApp NFS file servers. background: there are 2 versions of NFS in town, v2 and v3. In v3, one of things introduced was ability to read names of files in directory with stat(2)ing them at the same time; the procedure name is readdirplus. It can be used to speed up programs like ls(1). Apparently, NFS code in FreeBSD 2.2 (derived from 4.4BSD code, so perhaps this applies to all of modern BSD systems here) allow client to specify this in mount options without using NFS v3. This meaningless set of options panics NetApp file server. the following simple patch (attached) for /usr/src/sys/nfs/nfs_bio.c fixes this problem. --- nfs_bio.c.ok Wed Nov 5 20:11:17 1997 +++ nfs_bio.c Wed Nov 5 20:14:06 1997 @@ -1031,6 +1031,8 @@ case VDIR: nfsstats.readdir_bios++; uiop->uio_offset = ((u_quad_t)bp->b_lblkno) * NFS_DIRBLKSIZ; + if (!(nmp->nm_flag & NFSMNT_NFSV3)) + nmp->nm_flag &= ~NFSMNT_RDIRPLUS; /* dk(a)farm.org */ if (nmp->nm_flag & NFSMNT_RDIRPLUS) { error = nfs_readdirplusrpc(vp, uiop, cr); if (error == NFSERR_NOTSUPP)

3 2

archive
by Tom Yates 07 Nov '97

07 Nov '97

ok, i did some work. the list archive is better now, it automatically rebuilds every time someone sends a message to the list, so i'ts a lot more up-to-date than it had got any time recently. it moved a little, too... go to http://teaparty.mathworks.com:1999/toasters/ to find it. hope this is useful for people. Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

1 0

NetApp Release 4.2a bug?
by Steve Losen 07 Nov '97

07 Nov '97

We just got a F630 so I joined this list. I was wondering if anyone else has seen a problem with non-root users on NFS clients being unable to set the set-group bit. We are running Data ONTAP 4.2a on a F630. On a NFS client the following commands have no effect when run by a non-root user on files owned by the user and served by the F630. chmod g+s file chmod 2755 file Neither of these set the set-group bit. If superuser runs these commands on a NFS client with root access, they work. Once the set-group bit is set, a non-root user can unset it with chmod g-s file or chmod 755 file This has been reported to Netapp. Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

Experiences with CIFS
by Garrett Burke 05 Nov '97

05 Nov '97

Hi, I'm considering a F230 with CIFS support to replace several creaking NT file servers which are being used in a SW development environment. I would be interested in any experience that people have of using a filer with CIFS. I'm interested in primarily a CIFS only use, but may start using NFS in the future as well (as UNIX development grows) How do people handle backups of data , especially data that NT apps have locked. Anyone running Lotus Notes with the data on a filer? (I currently use ARCServe with their various agents to handle Notes & MS Exchange data) Being able to point ARCServe at the filer and get a consistent backup would be nice. I note from the netapp site that Windows Networking Software 2.0 is out, but I quote from the FAQ: " The next release of Windows Networking Software will also provide NTFS-style file and directory permissions for Windows users." This is what was said about version 1.0 Q to Netapp people on the list (yes, I have asked directly a week or 2 ago and am still awaiting a reply ) When can file level ACLs be expected? I know having file level ACLs is more complex to manage, but it does allow us to have multiple groups with different ranges of access (which stops the Analysts & Business people deleting/changing the developers work and project teams to have read access to other teams work) Even directory level ACLs would go a long way to meeting our requirements, but I think that if netapp is serious about the CIFS market then they need to duplicate the NT ACLs on the filers. Thanks, GB -- Garrett Burke, Network Admin,Managed Solutions Corp. 32 Upper Mount St., Dublin, Ireland. burkeg(a)msc.ie +353-1-661-4840 A jug of wine, a loaf of bread and thou.

1 0

Re: Redundant filer power supplies
by Robert Hamilton 04 Nov '97

04 Nov '97

At 06:52 AM 11/4/97 -0500, Brian Tao wrote: > How do these work? Do they replace the existing power supply with >two separate modules? Does one supply full power while the other is >on standby, or do both supply half power during normal operation? >-- The filer power supply is replaced by a RPS adapter module. This adapter module is connected via an "umbilical" cord to the separate rack-mount RPS unit. Inside this RPS unit are two power supplies, either of which is capable of powering the filer. In normal operations, these power supplies share the load. This load-sharing feature extends the life of the power supplies over a standby implementation. Robert

1 0

Redundant filer power supplies
by Brian Tao 04 Nov '97

04 Nov '97

How do these work? Do they replace the existing power supply with two separate modules? Does one supply full power while the other is on standby, or do both supply half power during normal operation? -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

2 1

Possible software cause for total data loss?
by Brian Tao 04 Nov '97

04 Nov '97

During the pre-production testing of one of our F230 filers, we discovered a problem with one of them that we wereonly able to fix by rebuilding the RAID (and thus losing whatever OS and data was on the filer). The hardware configuration is as follows: NetApp Release 4.2a: Fri Sep 5 09:36:36 PDT 1997 System ID: 0016783805 slot 0: System Board 90 MHz (NetApp System Board Ia rev-b) Firmware release: 1.6_i Memory Size: 192 MB slot 0: SCSI Host Adapter 0 (QLogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. slot 0: Ethernet Controller e0 MAC Address: 00:a0:98:00:0f:1b (100tx) slot 6: NVRAM (NetApp NVRAM I) Revision: D2 Serial Number: 6589 Memory Size: 4 MB Battery 1 Status: 100% (3.07v) Battery 2 Status: 100% (3.07v) slot 7: Ethernet Controller e7 (Znyx) MAC Address: 00:c0:95:f8:49:c9 (Twisted pair) 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 ST15150W 9107 Size=3.9GB (8388315 blocks) 1: SEAGATE ST15150W 9107 Size=3.9GB (8388315 blocks) 2: SEAGATE ST15150W 9107 Size=3.9GB (8388315 blocks) 3: SEAGATE ST15150W 9107 Size=3.9GB (8388315 blocks) 5: SEAGATE ST15150W 9107 Size=3.9GB (8388315 blocks) 4: SEAGATE ST15150W 9107 Size=3.9GB (8388315 blocks) SCSI Host Adapter 9b (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. Part of the tests consisted of filling up the filesystem via NFS and NDMP copies from a host Ultrasparc. Three other F230's of identical configuration survived the tests, but the remaining F230 experienced the following panic four times: PANIC: ../common/wafl/nvlog.c: 1088: Assertion failure I will be running the NVRAM diagnostics later today to see if they turn up anything. However, more distressing is the behaviour of the Netapp upon reboot: [... other boot messages deleted...] Loading filesystem. Recomputing parity in NVRAM PANIC: ../driver/disk/disk.c:2633: Assertion failure. version: NetApp Release 4.2a: Fri Sep 5 09:36:36 PDT 1997 cc flags: 3 dumping core: .......... Old core present on disk --- not dumped. Program terminated ok At this point the filer is inaccessible, and I can't find a way to get it up and running. Is there a way to flush the NVRAM or ignore an existing dump... some way to turn NFS back on so the data can be retrieved. Booting the kernel off floppy doesn't help because it tries to replay the WAFL logs too, and another panic occurs. The only way around I've found is to wipe out the filesystem and start over again (obviously not the optimal solution). Ideas? -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

1 0

Re: raid swap question
by sirbruce＠ix.netcom.com 04 Nov '97

04 Nov '97

On 10/08/97 09:10:10 you wrote: >We have "raid swap"ed almost three shelves worth of drives into >an F330 at one time. The AE recommended this method as >being faster than installing all the drives at config >time and building that large file system from scratch. >This worked fine, but still takes a significant amount >of time. I think by "at one time" you still mean one at a time (a raid swap for each drive). >We later added a fourth shelf and "raid swap"ed all those >drives in at once. The filer was only off the net for >the length of time it took to halt/connect the SCSI cable/ >reboot. A few hours later, after the raid swap completes, >all the additional disk space shows up - it does not show >up one drive at a time. I don't quite understand this... if you added them while the filer was down, you didn't "raid swap" anything. And they show up immediately, not a few hours later. I think perhaps you are talking about *raid add*, i.e. actually adding the drives to the filesystem. In that case you can add them individually one drive at a time (and the filer would get the space on drive at a time), or you can raid add them all at once, in which case they'll all finish at about the same time. >Some comments regarding DLT drives - I have heard that you >want to keep them "streaming" (feed with data) or the >drive has to stop, wait for data, backup, reseek to the >stop point, and start again. This applies to both 4000/7000 >series. You pay a significant speed penalty for dropping >the drive out of streaming mode. Our word from Netapp is >that for an F230, they sell the FW/DIff card and it works, but >it is not officially QA'd in the system, but soon should be. Yes, streaming is important, but my point was I don't think a 7000 non-streaming is going to be much slower than a 4000 streaming. But, I could be wrong on this. In any case, there are *plenty* are start-stop behavior in a Netapp dump even locally, so I don't think you can avoid it. Bruce

2 1

Re: Dumping Clearcase Storage Pools (fwd)i
by Dave Compton 31 Oct '97

31 Oct '97

Gil Smith wrote: > Hey Dave, > > Did you know about the "toasters" mail list at mathworks? > One of our customers started this mailing list for owners > of netapp boxes to share information with each other. > > Anyway below is a question that was on the list just recently > related to clearcase. Thought you might be interrested in > the list and this question. > > --Gil > > ----- Forwarded message from Scott MacDonald ----- > > >From scott(a)msi-uk.com Fri Oct 31 06:51:22 1997 > Sender: scott(a)msi-uk.com > Message-ID: <3459EC09.38A8(a)msi-uk.com> > Date: Fri, 31 Oct 1997 14:32:41 +0000 > From: Scott MacDonald <scott(a)msi-uk.com> > Organization: Mobile Systems International Plc, UK > X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4m) > To: toasters(a)mathworks.com > Subject: Dumping Clearcase Storage Pools > > Does anyone have any experience using NetApp filers to hold > Clearcase storage pools, and if so, how did you manage the backups? > We're just about to move to them, and we think we should be able > to lock the VOBs, copy the db to the filer, then do a local dump > (from a snapshot) to DLT. > If anyone has any experience they wouldn't mind sharing, I'd > love to hear it. > TIA, > > Scott. > -- > _______________________________________________________________ > > Scott MacDonald Mobile Systems International Plc > Tel: 0171 971 8798 > System Administrator Fax: 0171 971 8712 > E-Mail: scott(a)msi-uk.com > _______________________________________________________________ > > ----- End of forwarded message from Scott MacDonald ----- Scott, We have been doing this for 7 or 8 months now. We have approximately 50 VOBs to backup on a daily basis. Our backups have dropped from around 7 hours to 1 hour and 1/2 hours. Basically this is what we do. Snapshots are set so that there is a snapshot at midnight. At 2357 we lock all the VOBs and wait for the snapshot. At around 0004 we copy the database files from every VOB to a backup directory on the NetApps, create links between this backup area and the source pools in the snapshot. Unlock the VOB and start copying the VOB data to tape. The tape process takes about 7-8 hours. But the most important thing is that our VOB are only locked for around 1 hour. The process has worked very well for us. Hope this helps. Dave

1 0

Dumping Clearcase Storage Pools
by Scott MacDonald 31 Oct '97

31 Oct '97

Does anyone have any experience using NetApp filers to hold Clearcase storage pools, and if so, how did you manage the backups? We're just about to move to them, and we think we should be able to lock the VOBs, copy the db to the filer, then do a local dump (from a snapshot) to DLT. If anyone has any experience they wouldn't mind sharing, I'd love to hear it. TIA, Scott. -- _______________________________________________________________ Scott MacDonald Mobile Systems International Plc Tel: 0171 971 8798 System Administrator Fax: 0171 971 8712 E-Mail: scott(a)msi-uk.com _______________________________________________________________

1 0

Solaris 2.6, multiple IP's and the Netapp?
by rasmus＠lerdorf.on.ca 31 Oct '97

31 Oct '97

Sun apparently changed something in the way multiple IP's assigned to a single interface behaves in Solaris 2.6. As soon as I turn on hme0:1 my Netapp mounted read/write file system starts behaving oddly. And, if I reboot the machine, then I get a permission denied message when I try to mount. I noticed that the Netapp's arp cache picked up the second ip as soon as I turned it on on the Solaris 2.6 box. On my Solaris 2.5.1 box that sits right next to it, its second IP never shows up in the Netapp arp table. And, the Solaris 2.5.1 box happily mounts things. I tried putting both of the Solaris 2.6 box's ip's in the Netapp /etc/exports file, but I still get a "permission denied" message when I try to mount. Turning off the interface and rebooting the Solaris 2.6 machine fixes things. I can mount the file system again. I really do need multiple IP addresses on these Solaris 2.6 machines though. Is there some sort of workaround that is a little less drastic than reverting to Solaris 2.5.1? (The Filer is a 630 running 4.1c if it makes a difference) -Rasmus

2 4

Re: Solaris 2.6, multiple IP's and the Netapp?
by sirbruce＠ix.netcom.com 31 Oct '97

31 Oct '97

On 10/30/97 22:32:23 you wrote: >I tried putting both of the Solaris 2.6 box's ip's in the Netapp >/etc/exports file, but I still get a "permission denied" message when I >try to mount. Turning off the interface and rebooting the Solaris 2.6 >machine fixes things. I can mount the file system again. I haven't had any experience with this explicitly, but if 2.6 is doing some-sort of "load-balancing" among IPs on the interface, there should be a way to turn this feature off. If not, you were on the right track with /etc/exports, but remember that you have to re-run exportfs (I prefer exportfs -av) on the filer for the changes to take effect. Then reboot the Solaris 2.6 client and see what happens. Bruce

2 1

Re: Source NDMP server hangs after successful dump?
by mds46523＠ggr.co.uk 30 Oct '97

30 Oct '97

Well I recognise it! It happened 9 times out of 10 when I was using NDMPCopy a month or so back. The source filer will eventually give up, but only after an hour or two... Because there are 5 sessions for NDMP on a given filer, and I was copying qtrees between filers, I had to spend lots'o time manually setting up and tearing down NDMPCopies - because I couldn't rely on a script keeping the copies going as fast as possible, and I was constrained by time. I also had anomalously low throughput on one pair of filers which remained constant no matter how many concurrent NDMPCopies I set running, and another pair would crash if I tried to set up concurrent NDMPCopies, though the throughput was sufficiently high (ten times the speed of the stable-but-slow pair) that that didn't impact the overall operation. In case you're wondering the first pair was pretty much identical to the second pair, give or take a shelf of disks or two. We've not yet figured out why the difference in stability or performance. The source filers were F540s, the targets were F630s, all on one FDDI ring with two E4000's running 2.5.1 fully and equivalently patched to the gills running the NDMPCopies. Nevertheless, I used to hate setting up back-to-back dump restores and NDMPCopy is gonna be a permanent fixture in our toolbox (until something even better happens 8) On Oct 30, 6:43, Brian Tao wrote: > Subject: Source NDMP server hangs after successful dump? > I downloaded ndmpcopy 1.1 from ftp.ndmp.org and used it to > duplicate the data across filers. In every case using four different > F230's, the dump/restore was successful, but the ndmpcopy never > exits, suggesting the source filer may be hung. All the data was > transferred, and the source filer is still alive and serving NFS, > except it doesn't know that the dump is finished. All the filers are > running 4.2a, as shipped. Is this a known problem? > > # ./ndmpcopy -v adm1-na1:/home/home1 adm1-na3:/home/home3 -sa root:******** -da root:******** > Connecting to adm1-na1. > Connecting to adm1-na3. > adm1-na1: CONNECT: Connection established. > adm1-na3: CONNECT: Connection established. > adm1-na1: LOG: DUMP: creating "snapshot_for_dump.1" snapshot. > adm1-na1: LOG: DUMP: Date of this level 0 dump: Wed Oct 29 12:11:30 1997 > adm1-na1: LOG: DUMP: Date of last level 0 dump: the epoch > adm1-na1: LOG: DUMP: Dumping /home/home1/ to NDMP connection > adm1-na1: LOG: DUMP: mapping (Pass I) [regular files] > adm1-na1: LOG: DUMP: mapping (Pass II) [directories] > adm1-na1: LOG: DUMP: estimated 3373500 tape blocks. > adm1-na1: LOG: DUMP: dumping (Pass III) [directories] > adm1-na1: LOG: DUMP: dumping (Pass IV) [regular files] > adm1-na1: LOG: DUMP: 15% done, finished in 0:27 > adm1-na1: LOG: DUMP: 32% done, finished in 0:20 > adm1-na1: LOG: DUMP: 49% done, finished in 0:15 > adm1-na1: LOG: DUMP: 66% done, finished in 0:10 > adm1-na1: LOG: DUMP: 82% done, finished in 0:05 > adm1-na1: LOG: DUMP: 99% done, finished in 0:00 > adm1-na3: HALT: The operation was successful! > Waiting for adm1-na1 to halt too. > (If it sits here forever, the transfer was successful, > but the source filer has hung. Press ^C.) > Elapsed time: 0 hours, 32 minutes, 10 seconds. > > ^C > 0.04u 0.00s 37:02.48 0.0% > > -- > Brian Tao (BT300, taob(a)netcom.ca) > "Though this be madness, yet there is method in't" >-- End of excerpt from Brian Tao -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Source NDMP server hangs after successful dump?
by Brian Tao 30 Oct '97

30 Oct '97

I downloaded ndmpcopy 1.1 from ftp.ndmp.org and used it to duplicate the data across filers. In every case using four different F230's, the dump/restore was successful, but the ndmpcopy never exits, suggesting the source filer may be hung. All the data was transferred, and the source filer is still alive and serving NFS, except it doesn't know that the dump is finished. All the filers are running 4.2a, as shipped. Is this a known problem? # ./ndmpcopy -v adm1-na1:/home/home1 adm1-na3:/home/home3 -sa root:******** -da root:******** Connecting to adm1-na1. Connecting to adm1-na3. adm1-na1: CONNECT: Connection established. adm1-na3: CONNECT: Connection established. adm1-na1: LOG: DUMP: creating "snapshot_for_dump.1" snapshot. adm1-na1: LOG: DUMP: Date of this level 0 dump: Wed Oct 29 12:11:30 1997 adm1-na1: LOG: DUMP: Date of last level 0 dump: the epoch adm1-na1: LOG: DUMP: Dumping /home/home1/ to NDMP connection adm1-na1: LOG: DUMP: mapping (Pass I) [regular files] adm1-na1: LOG: DUMP: mapping (Pass II) [directories] adm1-na1: LOG: DUMP: estimated 3373500 tape blocks. adm1-na1: LOG: DUMP: dumping (Pass III) [directories] adm1-na1: LOG: DUMP: dumping (Pass IV) [regular files] adm1-na1: LOG: DUMP: 15% done, finished in 0:27 adm1-na1: LOG: DUMP: 32% done, finished in 0:20 adm1-na1: LOG: DUMP: 49% done, finished in 0:15 adm1-na1: LOG: DUMP: 66% done, finished in 0:10 adm1-na1: LOG: DUMP: 82% done, finished in 0:05 adm1-na1: LOG: DUMP: 99% done, finished in 0:00 adm1-na3: HALT: The operation was successful! Waiting for adm1-na1 to halt too. (If it sits here forever, the transfer was successful, but the source filer has hung. Press ^C.) Elapsed time: 0 hours, 32 minutes, 10 seconds. ^C 0.04u 0.00s 37:02.48 0.0% -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

1 0

Re: Alpha future
by mds46523＠ggr.co.uk 29 Oct '97

29 Oct '97

On Oct 29, 16:01, Alexei Rodriguez wrote: > Subject: Re: Alpha future > +--- In our lifetime, "Gregory M. Paris" <paris(a)bose.com> wrote: > | > | Any thoughts on what the Intel/Digital settlement means to NetApp and > | its customers? It sure looks (to me anyway) as though the Alpha is dead. > I don't think Intel will discontinue the Alpha line, as it would not be in > it's best interests. Especially given the current microprocessor market. > Who is out there that has a good chip? Intel *have* to service Digital's needs for Alpha production. At least that's what I gathered from the announcements about the deals. I'm pretty sure there will be more technology exchange from Digital to Intel over time - Digital's really virtualising its business now, returning in many ways to being a service oriented company. Intel can almost certainly produce Alphas profitably - having the exclusive license to make them may mean Intel's attitude changes. Intel, like Motorola, seem to have few objections to maintaining multiple processor lines as long as they remain profitable and so far as anyone can tell the Alpha 21264 and 21364 at the ridiculous clock speed they're aiming at will stay ahead of the IA64 line. As for the rest, the MIPS line covers the full gamut of v.small to v.powerful CPU's and, as a result, has more sold units per annum than HP-PA, PowerPC and SPARC put together, last time I looked. Check out the Microprocessor report (I think it's at www.chipanalyst.com) for more detailed CPU/DSP industry watching. > > Alexei >-- End of excerpt from Alexei Rodriguez -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Re: Alpha future
by mds46523＠ggr.co.uk 29 Oct '97

29 Oct '97

I'm not sure I can agree with that. I'm just thinking of the MIPS R1{0,2}K and ULTRASPARC II - those are fabless designs and they are both extant and, as far as I can tell, thriving. Digital were making out that having their own fabs was an advantage...now they're making out that they weren't actually generating revenue in the way Digital likes. *shrug* Besides I suspect that NetApp development could shift to another platform with (to the outside at least) consummate ease if other hot chips seem more viable. I'd be thinking of the TI DSPs myself. On Oct 29, 15:21, Gregory M. Paris wrote: > Subject: Alpha future > Any thoughts on what the Intel/Digital settlement means to NetApp and > its customers? It sure looks (to me anyway) as though the Alpha is dead. > > -- > Gregory M. Paris > Senior Systems Administrator > Bose Corporation Email: paris(a)bose.com > The Mountain, MS#258 Phone: +1 508 766-4072 > Framingham, MA 01701-9168 FAX: +1 508 820-0173 > >-- End of excerpt from Gregory M. Paris -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Re: File names... on netapp from Mac over CIFS
by sirbruce＠ix.netcom.com 22 Oct '97

22 Oct '97

On 10/22/97 11:45:32 you wrote: >I would suspect that this has to do with extended attributes. I agree with that. Also be aware that there are filenames that are legal under Mac's FS that aren't under NTFS (I think a filename ending with a space is one), so if the NT box is actually using a Mac-compatible filesystem as the share, going from it to an NTFS-compatible filesystem could cause problems. But the poster didn't seem to indicate that this was the case. Bruce

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