toasters

toasters@lists.teaparty.net

13513 discussions

Start a nNew thread

[Fwd: Quad Fast Ethernet vs. Single Fast Ethernets]
by Zack Rivette 18 Sep '98

18 Sep '98

Please remove me from this list...

1 0

Re: Bad HD
by Daniel Quinlan 18 Sep '98

18 Sep '98

hitz(a)netapp.com (Dave Hitz) writes: > Our motivation was really your second guess: > > To make sure the admin knows something is wrong. > > We couldn't come up with any way to absolutely, reliably *guarantee* > that the sysadmin would get notified except to have the box turn itself > off. We even joked about putting lights and sirens on the box, but the > problem is, at smaller sites, people sometimes stick these things in a > closet somewhere and forget about them. What does the system do when the raid.timeout is reached? Does the LCD display anything, is there an SNMP trap, autosupport email, autosupport note, etc. ? Also, does it completely power off? I'm wondering if we should disable the feature or possibly extend the timeout. Thanks. - Dan

3 2

Re: F740 and Exchange
by Bridget Allison 18 Sep '98

18 Sep '98

Jason wrote: >Is there anything special that has to be done for a 740 filer and >Microsoft Exchange to work together? *I'm presuming that you have CIFS configured on the filer and the filer is in an NT Domain. * The short answer is no. There's nothing you need to do to the filer. However, if you are wanting to use the filer to store the Information store and directory and transaction logs then you will need to make changes on your Exchange server. Exchange does not allow you to install on a network drive - so you can't specify a mapped drive for the location of your data. You can of course store your pst files on a filer - many people do this today and it works just fine since those files are not part of the central message store. So you would need to install Exchange on local disk and then copy the files over to the filer, update the Exchange keys in the registry to point to the new location and then restart Exchange. NetApp has done quite a bit of testing using filers to house the Exchange Information Stores and we've had excellent results. I am in the process of publishing the config details on that to the NOW web site so that customers can do their own testing. Be aware, however, that this is *completely unsupported* right now - by both NetApp and Microsoft. If you want to see how a filer can help your Exchange environment (performance, snapshots etc) and are willing to explore this unsupported for the moment then we'd be very interested in your results. I'll send a message to the list once the info is up on the NOW site (should be mid-next week). If you have an urgent desire for the config details before then please email me directly at bridget(a)netapp.com ------------------------------------------------------------------ Bridget Allison Marketing Manager, NetApp Windows Networking Network Appliance Inc.

1 0

Does your e0 on the F330 work? HELP
by Daniel Wong 18 Sep '98

18 Sep '98

To all you wonderful workers of magic: I've been using FDDI on f7 just fine, but management decided to go Fastethernet (dropping FDDI) and I can't get e0 to link with our Cisco Catalyst 5000 at either 10 or 100, half or full. Laptop links OK, e0 can't ping anything on the new subnet except itself. Brought down f7 and ifconfiged e0 with f7's IP and same problem. Thus, dgateway and route hasn't changed => must be e0, right? Does anybody know what I'm not doing? I've already tried my spare motherboard and have an RMA for another board here by my side. Config: F330, 256MB, 8MB NVRAM, NetApp Release 4.2a Dual Attached FDDI, no ethernet card. Thanks in advance, Dan -- Daniel E Wong GIS System/Network Administrator City of Spokane mailto:dewong@sprintmail.com 808 W Spokane Falls Blvd mailto:dwong@spokanecity.org Spokane WA 99201-3344 (o) 509/625-6499 (fax) 509/625-6550

1 0

F740 and Exchange
by Jason Middlebrooks 18 Sep '98

18 Sep '98

Is there anything special that has to be done for a 740 filer and Microsoft Exchange to work together? Jason Middlebrooks Systems Engineer Direct Connect Systems 2264 Northwest Parkway, Suite I Marietta, GA 30067 Phone: 770-933-9327 x260 Email: jason(a)directconnect.com <mailto:jason@directconnect.com> Pager: 888-502-1625 Web: www.directconnect.com <http://www.directconnect.com> Fax: 770-933-9272

2 1

Long filenames with Digital Unix and Network Appliance
by David B. Ritch 18 Sep '98

18 Sep '98

We are experiencing a repeatable problem when creating files with long filenames under Digital Unix 4.0 on a filesystem mounted from a NetApp filer. The files are not visible until the filesystem is remounted - that is, when you create the files, you cannot see them. If you mount the filesystem at another mount point, unmount it or remount it, or simply look at it on another nfs client, you can see the files. This apparently only happens when using nfs version 3. We have observed this bug only between a Digital Unix 4.0 (4.0A and 4.0D, at least) client an a NetApp server. We have tested Solaris 2.5 and 2.6 clients, Digital Unix, NetApp, Auspex, and Solaris servers. Anyone have an idea what could cause this? Naturally, the first response from Digital is that it is likely to be a NetApp problem, and the first response from NetApp is that it is likely to be a Digital Unix problem. Any suggestions on how to determine where the problem lies? Here is a script from a DEC support person that demonstrates the problem: -------------------- !#/bin/csh # create a log of datafiles and links to test nfs problem while ( $num < 100 ) @ num = $num + 1 cat /etc/printcap > reallyreallyverylongnamedatafile.$num ln -s reallyreallyverylongnamedatafile.$num 1.$num echo "$num is done" end echo done exit -------------------- When you run it, it should generate 100 files and 100 links. You should be able to run the script, and then "ls | wc" and see about 200 words. When the bug appears, you see only ~160 words. However, you can run the "ls | wc" on another nfs client mounting the same filesystem, and see the expected 200 words. Thanks, David Ritch

6 6

Re: Long filenames with Digital Unix and Network Appliance
by Ketil Kirkerud Elgethun 17 Sep '98

17 Sep '98

"David B. Ritch" <dbritch(a)Home.com> writes: > > We are experiencing a repeatable problem when creating files with long > filenames under Digital Unix 4.0 on a filesystem mounted from a NetApp > filer. The files are not visible until the filesystem is remounted - [...] > We have observed this bug only between a Digital Unix 4.0 (4.0A and > 4.0D, at least) client an a NetApp server. We have tested Solaris 2.5 > and 2.6 clients, Digital Unix, NetApp, Auspex, and Solaris servers. I tested this right now, on a Digital Unix 4.0D client, mounting a F330/5.1R1, and I can't reproduce your problem. (mountopts are v3, rw, nosuid, udp, hard, intr) > > Anyone have an idea what could cause this? Sounds a bit like a caching/cache synchronization problem on the client. > Naturally, the first response from Digital is that it is likely to be a > NetApp problem, and the first response from NetApp is that it is likely > to be a Digital Unix problem. Any suggestions on how to determine where > the problem lies? If, as you say, the files are actually visible on a different client, then I'd suggest you do a snoop/tcpdump to try to see what the DU client asks for during the 'ls'. -- ---Ketil Kirkerud Elgethun, SOL System

2 1

Re: Bad HD
by Jay Sekora 10 Sep '98

10 Sep '98

Leila wrote: > Is it true that when one HD goes bad, it will be reconstructed on the > hotspare, but if you don't pull out bad HD and replace it within the 24 > hours system will shutdown? Not quite; you're confusing two separate things. When a drive fails, the system goes into `degraded' mode. (A second drive failure in the same RAID group at this point will result in loss of data.) When the system is in degraded mode, it will immediately start copying data to a hot spare (*if* one is available!) to replace the failed drive. When that process is complete, the system is no longer in degraded mode, because the hot spare has been made a part of the RAID group, so the RAID group is no longer down a disk. (Of course, though, the whole system is now down one hot spare.) This can be a somewhat lengthy process, depending on the size of the RAID group. What you're thinking of is that by default, if the system has been running in degraded mode for 24 hours (i.e. if a drive failed 24 hours ago and hasn't been replaced either by a hot spare or a new disk), the system will shut down. I think the idea is to reduce the likelihoood of data loss caused by a second disk failure (and make sure the admin knows that something's wrong). At least under 5.1, you can adjust the time limit, so for instance you could make it long enough to cover a long weekend, or if a system were under 24x7 supervision, you could shorten it. Unless your RAID groups are too large and your machine is very heavily loaded, the only case where you're likely to stay in degraded mode for 24 hours (and risk the machine shutting down) is if you *don't* have a hot spare, so the rebuild can't happen. AFAIK, there's no problem leaving a bad drive sitting in the shelf arbitrarily long, as long as you don't need the drive bay for something else (unless the drive is bad in a way that might affect other drives, like if flames or sparks are coming out of it :-). > What happens in a case if you have 2 hotspare? In the normal case, it doesn't make any difference to this scenario, except that you end up (before you physically replace drives) with one hot spare instead of zero. It means if another drive fails *after the RAID group has been rebuilt*, there's a hot spare to replace it. Also, if a drive fails in a different RAID group, you should be OK. -j. -- Jay Sekora <jay(a)ccs.neu.edu> Northeastern University College of Computer Science

2 1

A netapp failover possibility...???
by ian.gardner＠vf.vodafone.co.uk 10 Sep '98

10 Sep '98

Hi, We have two netapp filers serving mainly static data (updated overnight) to several hp-ux clients. If one server fails we can swap the clients onto the other server by mounting and switching symbollic links. eg. on a client: /discs/data -> /netapp1/data If netapp1 fails we mount data from netapp2 and relink: /discs/data -> /netapp2/data Now this leaves processes hanging on the dead server which can be killed using fuser -k netapp1:/data. This is only necessary if memory/swap on the clients is tight, otherwise the "hung" processes will sleep until the server comes back. This is not ideal so I had a thought, since we have Quad 100BaseT cards, in the event of a failure, we could configure up a spare port to be the same name and IP address as the dead server and therefore take over the nfs requests for it. Since we are LIVE I am unable to test this, but subject to the routers and arp tables becoming updated I would have thought this would work. I'm not sure about file locking, but I didn't think this works very well on nfs anyway - does it ? NFS is stateless so it should be ok. Anyone out there tried this or able to on a couple of test boxes ? Cheers Ian Gardner Vodafone Ltd. Newbury UK. ian.gardner(a)vf.vodafone.co.uk

2 1

Re: Bad HD
by sirbruce＠ix.netcom.com 09 Sep '98

09 Sep '98

On 09/09/98 09:36:36 you wrote: >AFAIK, there's no problem leaving a bad drive sitting in the shelf >arbitrarily long, as long as you don't need the drive bay for something >else (unless the drive is bad in a way that might affect other drives, >like if flames or sparks are coming out of it :-). One gotcha is that if you leave a bad drive sitting in the shelf, and the system reboots, it could think the drive is a hot spare and allow it to be used again. I don't think this happens in all circumstances (I think there's a way to mark the drive bad such that it won't be used), but it certainly can (and has) happened in the past. So it's generally a good idea to remove the bad drive from the shelf as soon as possible. Bruce

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