toasters

toasters@lists.teaparty.net

13514 discussions

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

Subscribe
by Matthew J. Howarth 07 Jul '97

07 Jul '97

1 0

Re: Filers for a large mail environment
by Edward Henigin 04 Jul '97

04 Jul '97

I wanna talk this out. What do you mean about "100,000 files in a directory will cause you performance problems"? I was told by Network Appliance that their WAFFLE filesystem (or whatever) hashes the directory entries internally, so there are *no* scaling issues with regards to directories with many entries in them. Are you wrong? Or is Network Appliances wrong? Please help. Ed Henigin ed(a)texas.net ps just what the heck do you mean by 'setting up a directory hashing scheme' ? Are you talking about the MTA and/or POP3 servers having their own databases of filename->inode mappings? Your terminoligy seems vague, maybe that's where my confusion stems. -- ---------- Forwarded message ---------- Date: Wed, 02 Jul 1997 17:54:13 +0100 From: Dom Mitchell <hdm(a)demon.net> To: Alan Judge <Alan.Judge(a)indigo.ie> Cc: toasters(a)mathworks.com Subject: Re: Filers for a large mail environment [...deletia...] Shared maildrops are a different issue. If you use something like qmail[1], OTOH, there are simply no locking issues whatsoever (and easy POP3 support, but no IMAP). We do something similiar (although propietary) for about 100,000 users, and it works well. Don't ^^^^^ forget to set up a directory hashing scheme, though as 100,000 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ files in a directory will also cause you performance problems. :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Dom [1] <URL:http://www.qmail.org/> -----End of forwarded message-----

9 11

Re: [sm_recover] error messages
by Amy Chused 03 Jul '97

03 Jul '97

At 10:57 AM 7/3/97 -0400, Christoph Doerbeck wrote: >> The filers try to save state so they know what machines are clients of theirs. >> Go ahead and blow away the /etc/sm/recover and/or the /etc/sm/state files. >> It doesn't hurt the filer; the filer will regenerate those files when it >> needs them, but it'll get rid of the error messages from the filer trying >> to talk to machines that don't exist anymore. >What you say makes sense, but the only files in /etc/sm are : state,monitor, >and notify. I tried moving /etc/sm/state but the messages are still coming. My apologies. It was an off-the-cuff answer. I should have said notify when I said recover. (I'm working on setting up a backup system here, so I've got recover on the mind). It's definitely safe to blow away the notify file. >Is it safe to remove all files in the /etc/sm directory? I belive so. >The F330 is running version 3.1c mm-hmm. I've run just about all the versions since 2.something-early, up to 4.0.1c. 3.1c is pretty good. Amy

1 0

Re: [sm_recover] error messages
by Amy Chused 03 Jul '97

03 Jul '97

At 08:11 AM 7/3/97 -0400, Christoph Doerbeck wrote: >Could anyone shed some light on what is generating the following messages >on one of our netapp F330's: > >[sm_recover]: get RPC port for <host=machinea.foo.com,prog=100024,ver=1,prot=17 >> failed >[sm_recover]: no address for host <machineb.foo.com> > >The listed machines were recently taken out of service or moved to another >network. Any opions are welcome... The filers try to save state so they know what machines are clients of theirs. Go ahead and blow away the /etc/sm/recover and/or the /etc/sm/state files. It doesn't hurt the filer; the filer will regenerate those files when it needs them, but it'll get rid of the error messages from the filer trying to talk to machines that don't exist anymore. Amy

2 1

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