toasters

toasters@lists.teaparty.net

1 participants
13518 discussions

problems mounting netapps on sgi's.
by s.a.johansen＠kjemi.uio.no 25 Jul '97

25 Jul '97

I have a 220 with 4.0.3 and 37 quoted trees. These mount fine on all our machines (solaris, aix, linux, ultrix, digital unix), except on sgi's with IRIX 6.2 or higher, regardless of model. On 5.2 or 5.3, there is no problem at all. Upon doing 'mount -a' i get the following errors: mount: chatelier:/mn/chatelier/u37 already mounted mount: chatelier:/mn/chatelier/u36 already mounted mount: chatelier:/mn/chatelier/u35 already mounted mount: chatelier:/mn/chatelier/u20 already mounted chatelier:/mn/chatelier/u34 mounted on /mn/chatelier/u34 chatelier:/mn/chatelier/u33 mounted on /mn/chatelier/u33 chatelier:/mn/chatelier/u32 mounted on /mn/chatelier/u32 mount: chatelier:/mn/chatelier/u30 server not responding: Timed out mount: chatelier:/mn/chatelier/u31 server not responding: Timed out mount: giving up on: /mn/chatelier/u31 mount: giving up on: /mn/chatelier/u30 mount: chatelier:/mn/chatelier/u29 server not responding: Timed out mount: chatelier:/mn/chatelier/u28 server not responding: Timed out mount: giving up on: /mn/chatelier/u29 mount: giving up on: /mn/chatelier/u28 mount: chatelier:/mn/chatelier/u27 server not responding: Timed out mount: giving up on: /mn/chatelier/u27 mount: chatelier:/mn/chatelier/u26 server not responding: Timed out mount: giving up on: /mn/chatelier/u26 mount: chatelier:/mn/chatelier/u25 server not responding: Timed out mount: giving up on: /mn/chatelier/u25 mount: chatelier:/mn/chatelier/u24 server not responding: Timed out mount: giving up on: /mn/chatelier/u24 mount: chatelier:/mn/chatelier/u23 server not responding: Timed out mount: giving up on: /mn/chatelier/u23 mount: chatelier:/mn/chatelier/u22 server not responding: Timed out mount: giving up on: /mn/chatelier/u22 mount: chatelier:/mn/chatelier/u21 server not responding: Timed out mount: giving up on: /mn/chatelier/u21 mount: chatelier:/mn/chatelier/u19 server not responding: Timed out mount: giving up on: /mn/chatelier/u19 As you can see, the sgi will mount some trees and time out on the rest. Each time I mount -av some more trees will mount, and the rest will time out. Has anyone else seen this? -- Ståle Johansen, University of Oslo.

1 0

Snapshot bug?
by David Drum 22 Jul '97

22 Jul '97

Hello everyone, I am quite perplexed by the behavior I am seeing below: david@vortex ~ $ find * -type f -print | sed -e 's%.*%ls -ldtr "&" .snapshot/*/"&"; echo%' | bash > messed.up.files .snapshot/*/Mail/.dir.tiff: No such file or directory .snapshot/*/NeXT/Apps/.dir.tiff: No such file or directory .snapshot/*/NeXT/Apps/.opendir.tiff: No such file or directory .snapshot/*/NeXT/Apps/Icon.app/brushes/.places: No such file or directory .snapshot/*/NeXT/Apps/Icon.app/help/.places: No such file or directory .snapshot/*/NeXT/Apps/Icon.app/help/.list: No such file or directory ^C david@vortex ~ $ ls -l .snapshot/*/NeXT/Apps/Icon.app/help/.list -rw-r--r-- 1 david staff 1095 Nov 14 1992 .snapshot/hourly.0/NeXT/Apps/Icon.app/help/.list -rw-r--r-- 1 david staff 1095 Nov 14 1992 .snapshot/hourly.1/NeXT/Apps/Icon.app/help/.list -rw-r--r-- 1 david staff 1095 Nov 14 1992 .snapshot/hourly.2/NeXT/Apps/Icon.app/help/.list -rw-r--r-- 1 david staff 1095 Nov 14 1992 .snapshot/hourly.3/NeXT/Apps/Icon.app/help/.list -rw-r--r-- 1 david staff 1095 Nov 14 1992 .snapshot/weekly.0/NeXT/Apps/Icon.app/help/.list Would anyone care to comment? This is greatly disturbing. Regards, David K. Drum david(a)more.net -- "That man has a rare gift for obfuscation." -- ST:DS9 * "It's hard to be bored when you're as stupid as a line." -- Vernor Vinge * "Reality has a tendency to be so uncomfortably real." -- Neil Peart * "You can only measure the size of your head from the inside." -- Larry Wall

2 5

Macs and toasters
by Ketil Kirkerud 10 Jul '97

10 Jul '97

Among our netapps we have a F330 which will soon be put into use as a fileserver for our internal use. We have PCs, various UNIX workstations, and a few Macs. The Macs are giving me a headache - the netapp doesn't support Appletalk, so we are pondering the alternatives : We've tried 'DAVE' from Thursby systems, which gives the Mac CIFS-client capabilities. This works fine with NT servers, however it does not work with netapps. (This is noted in bug #4140 - with no indication of whose problem it is, or, for that matter, when it might be fixed). Other options include NFS client software on the Macs, or setting up a gateway, which will mount the netapp via nfs, and re-export the filesystems via Appletalk (using linux and the free appletalk package, for example). Has anyone tried any of these solutions ? What will work ? regards, -- ---Ketil Kirkerud, Scandinavia Online I synergistically leverage my paradigms

1 0

Re: upgrading from 3.1c to 4.0.1c
by Amy Chused 09 Jul '97

09 Jul '97

At 05:16 PM 7/7/97 -0400, Christoph Doerbeck wrote: >I'm looking for input regarding why I might (or might not) encourage >my users to allow me to upgrade the filer OS from 3.1c to 4.0.1c. >What features are we missing? What pitfalls can I expect? I just >want to cover my bases... > >What we have currently is very stable. As far as I am concerned, there is one major advantage to the 4.x series. It can serve files over CIFS. It can also serve files over http, but that's much less important to me. We have a large and growing number of PCs, and installing NFS software on them is a pain in the rear. Being able to serve files over CIFS is very convenient. If you don't need CIFS or HTTP file service, then it's a much closer call. 'course, 4.x is their current release, and any performance tweaks they make are gonna go into 4.x, which will probably make it a bit faster, and potentially a bit less stable. If you're performance hungry, go with 4.x. If you absolutely have to stay up, ask them for their current list of known bugs in 3.1c and 4.0.1c, read them carefully, and decide which set you're less likely to trigger. They're pretty good with their known bugs list. Amy

2 1

Marking failed drives across boots?
by Steve Gremban 08 Jul '97

08 Jul '97

Had something similar happen to us. One of our Netapps failed a drive and reconstructed its data onto a different drive (from the hot spare pool). The failed drive should have been replaced asap but it fell through the cracks and was forgotten. A week later we shut it down to replace an fddi card and afterwards it wouldn't boot up. The failed drive was apparently working well enough so that the Netapp thought it had a RAID drive that wasn't a valid member of the array (inconsistent disk labels). Once we removed the problem drive the Netapp booted just fine. I don't understand why your bad drive was added to the hot spare pool upon reboot. It should have had a label that was inconsistent with the other drives and the Netapp shouldn't have booted. >> Could the Netapp somehow mark a bad drive so that the information >> is kept across boots? If a failed drive is working after a reboot then its label should be inconsistent with the other drives in the array and the Netapp shouldn't boot. NOTE: For those wondering what label I am talking about here is an excerpt from the System Administrator's Guide chapter on Troubleshooting: The Netapp writes a label on each disk indicating its position in the RAID disk array. regards, Steve Gremban gremban(a)ti.com PS: I noticed that you are running without a hot spare configured. We normally configure a spare in order to minimize time spent at risk in degraded mode. Do you consider the risk is minimal that another drive will fail before the first one is replaced and rebuilt or do you have some plan in place to ensure that someone is notified immediately? What about early in the morning, on weekends, holidays? Anyone else out there running without hot spares? ------------- Begin Forwarded Message ------------- >From madhatta(a)turing.mathworks.com Mon Jul 7 15:40:34 1997 Date: Mon, 7 Jul 1997 16:34:26 -0400 (EDT) From: Brian Tao <taob(a)nbc.netcom.ca> To: toasters(a)mathworks.com Subject: Marking failed drives across boots? MIME-Version: 1.0 We had a problem with our Netapp this morning that could potentially be quite serious. One drive near the beginning of the chain (ID 2, I believe) was failed out by the Netapp. Very shortly thereafter, the filer crashed with a RAID panic and rebooted. Upon rebooting, it noticed that drive ID 2 was not actively being used, and proceeded to add it to the hot spare pool. Then it began reconstructing the data on to (you guessed it) drive ID 2. In this scenario, there was no time to pull out the bad drive, and the Netapp happily rebuilt the data on it. I guess the correct procedure now is to forcibly fail that drive and rebuild to our good spare drive, and remove drive ID 2. Could the Netapp somehow mark a bad drive so that the information is kept across boots? -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't" ------------- End Forwarded Message -------------

2 1

Re: Marking failed drives across boots?
by Amy Chused 08 Jul '97

08 Jul '97

> Anyone else out there running without hot spares? Now, no. In the past, yes. We were space hungry and we'd maxed on the number of disks in some of our earlier and smaller NetApps, so we threw the spares into the pool because we kept tipping over the 100% full mark and not being able to write anything and that was bad. As it turned out, we were okay. The odds of two disks going bad before you get a chance to replace one of them is fairly minimal, especially if you set the thing to send you e-mail notifying you of a bad drive. Especially if you set the thing to send e-mail to both your mailbox and your pager notifying you of a bad drive. Amy -- who now has enough co-workers to not have to carry a pager 24x7x365 anymore, but who does it anyway.

1 0

Re: upgrading from 3.1c to 4.0.1c
by fred.abounader＠vantis.com 07 Jul '97

07 Jul '97

I would like these answers also? Fred. ---} From madhatta(a)turing.mathworks.com Mon Jul 7 16:22:17 1997 ---} X-Mailer: exmh version 1.6.9 8/22/96 ---} To: toasters(a)mathworks.com ---} Subject: upgrading from 3.1c to 4.0.1c ---} Mime-Version: 1.0 ---} Date: Mon, 07 Jul 1997 17:16:37 -0400 ---} From: Christoph Doerbeck <doerbeck(a)dma.isg.mot.com> ---} ---} ---} I'm looking for input regarding why I might (or might not) encourage ---} my users to allow me to upgrade the filer OS from 3.1c to 4.0.1c. ---} What features are we missing? What pitfalls can I expect? I just ---} want to cover my bases... ---} ---} What we have currently is very stable. ---} ---} ++-------------------------------------------------------------------- ---} Christoph Doerbeck ---} Motorola ISG / DIS email: doerbeck(a)dma.isg.mot.com ---} Mansfield, MA. USA ---} ++-------------------------------------------------------------------- ---} ---}

1 0

upgrading from 3.1c to 4.0.1c
by Christoph Doerbeck 07 Jul '97

07 Jul '97

I'm looking for input regarding why I might (or might not) encourage my users to allow me to upgrade the filer OS from 3.1c to 4.0.1c. What features are we missing? What pitfalls can I expect? I just want to cover my bases... What we have currently is very stable. ++-------------------------------------------------------------------- Christoph Doerbeck Motorola ISG / DIS email: doerbeck(a)dma.isg.mot.com Mansfield, MA. USA ++--------------------------------------------------------------------

1 0

Marking failed drives across boots?
by Brian Tao 07 Jul '97

07 Jul '97

We had a problem with our Netapp this morning that could potentially be quite serious. One drive near the beginning of the chain (ID 2, I believe) was failed out by the Netapp. Very shortly thereafter, the filer crashed with a RAID panic and rebooted. Upon rebooting, it noticed that drive ID 2 was not actively being used, and proceeded to add it to the hot spare pool. Then it began reconstructing the data on to (you guessed it) drive ID 2. In this scenario, there was no time to pull out the bad drive, and the Netapp happily rebuilt the data on it. I guess the correct procedure now is to forcibly fail that drive and rebuild to our good spare drive, and remove drive ID 2. Could the Netapp somehow mark a bad drive so that the information is kept across boots? -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

1 0

Re: [sm_recover] error messages
by Michael Cerda 07 Jul '97

07 Jul '97

I found that the erros would recur and that the system would regenerate the files and the data inside. I remove the state and notify files and then create empty versions. -Michael Cerda

3 2

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