toasters September 1998

toasters@lists.teaparty.net

55 participants
54 discussions

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

SUMMARY: "Calling all F630/FC-AL users"
by just me. 09 Sep '98

09 Sep '98

Well, its been a week, and as such I suppose time for a summary. Last week, I posted the following request for comments: If you are a NetApp F630/FC-AL user and have encountered any (especially recurring) glitches with interactions between the Fibre Channel host adapter and OnTAP, or recurring FC hardware failures I'd appreciate hearing from you. On the flip side, if you are a NetApp F630/FC-AL user and have seen perfect performance from your filer, I'd love to hear about it too. I was surprised to get only 5 responses, one from a fellow considering buying one. Out of the four owners that mailed me, two reported flawless performance, one mentioned problems caused by extreme environmental conditions, and one reported RAID bugs similar to the ones I had seen. Netapp replaced his shelf, as did they mine. I will post an update after we have the new shelf installed if there are any other notables. Their comment on the problem was "the low-level FC/SCSI system was unaware of a particular error sequence and was passing error codes to the RAID level where they caused a panic." They also recommended upgrading to 5.0.2D4. There were some other FC fixes rolled into 5.0.2, I'm not sure if there are additional ones in D4. Steve Clarke <Steven.Clarke(a)ThePLAnet.net> pointed out, "It has been my opinion for a while that there are people at NetApp who can make things happen and others who just make the right noises but do nothing." This has been my experience, too. However once I've been put in touch with the Clueful Folk, they have been dedicated above and beyond the call to resolving my issues. I've heard mumblings out-of-band about the usual low morale problems among their tech support staff and I sincerely hope that Netapp management recognise their amazing dedication. Thanks to Steven Clarke, Matt Stein, Fritz Feltner and Graham Knight for their time responding to my post. Alohas, matto --matt(a)snark.net----------------------------------------------------- Matt Ghali MG406/GM023JP - System Administrator, interQ, Inc AS7506 "Sub-optimal is a state of mind." -Dave Rand, <dlr(a)bungi.com>

1 0

Re: Bad HD
by Daniel Quinlan 08 Sep '98

08 Sep '98

leila.mutevelic(a)rss.rockwell.com writes: > 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? No, it's not true. > What happens in a case if you have 2 hotspare? If your system has run out of spares and a disk fails, it will be in degraded mode until you replace one or more spares. If an additional disk fails while in degraded mode, you are hosed. Having two spares helps protect you from a second disk failure, as long as that second failure happens after the first reconstruction has finished. However, even with two hot spares, I would recommend replacing replacing failed disks with new spares as soon as possible. - Dan

1 0

Re: Bad HD (fwd)
by beepy＠netapp.com 08 Sep '98

08 Sep '98

I think our system goes into 'degraded' mode when no spare is present. I'm the degenerate. (some mail misaddresses running around.) > Not quite. A failed disk will send the system into 'degenerated' mode if > there is no spare present. The system will shut down after 24 hours in > degenerated mode as a failsafe. However, if a spare disk *is* present, the > system goes into 'reconstruction' mode and rebuilds the failed disk. Once > reconstructed the system is back up and running as usual with no threat of > a failsafe shutdown. > If you have 2 hot spare disks, and one is used to rebuild a failed disk, > then you will have one spare disk remaining. > > leila.mutevelic(a)rss.rockwell.com 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? > > What happens in a case if you have 2 hotspare? > > > > Thanks, > > --Leila. > > > > -- > Shannon Madison <shannon(a)netapp.com> > Technical Education Manager > > Network Appliance, Inc. > 2770 San Tomas Expressway > Santa Clara, CA 95051 > USA > > Work: (408) 367-3574 > Fax: (408) 367-2151 > > The usual disclaimers apply. > > ----- End of forwarded message from Brian Pawlowski -----

1 0

Bad HD
by leila.mutevelic＠rss.rockwell.com 08 Sep '98

08 Sep '98

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? What happens in a case if you have 2 hotspare? Thanks, --Leila.

2 1

OnTap
by Wm Kevin Shaw 08 Sep '98

08 Sep '98

What is the latest and most stable version of OnTap for a F630 (Non F-CAL)? What configuration issues and bugs should I be aware of? Any Info on configuring CIFS for this version of OnTap would also be appreciated. Thanks in advance. Kevin

1 0

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 September 1998