toasters

toasters@lists.teaparty.net

3 participants
13513 discussions

Re: raid swap and dump problem
by sirbruce＠ix.netcom.com 08 Sep '97

08 Sep '97

On 09/08/97 19:44:13 you wrote: > > >Hi, > >When doing a `raid swap' I get this warning, > >> raid swap >** WARNING ** >You can NOT swap a disk into or out of the system: >a dump is currently running on a local tape device >and you must wait until the dump is completed, or abort the >dump before reissuing the "raid swap" command. This particular limitation shouldn't happen if your tape drive isn't on the same bus as your disks, which is just about every system Netapp has shipped in recent years. However, that "bug" wasn't fixed until 4.0 or 4.1, I think. >But there is no dump running, the last dump was aborted, > >DUMP: ran out of tape, and can't ask questions when run via "rsh". >DUMP: The ENTIRE dump is aborted. > >Is there a lockfile which should be removed? How do I abort the >dump I can't find? Yes, unfortunately, there is no "dump abort" command on the filer the clear up such things. There might be a way to abort NDMP sessions, but basically the best thing for you to do is reboot. (There's no lockfile; the state is in memory.) An easy way to reproduce this is have an rsh dump running from a remote client which then crashes. Bruce

1 0

NFS bursting is killing us
by Christoph Doerbeck 08 Sep '97

08 Sep '97

In recent tests to uncover performance issues with a newer F330 running 4.0.1c, our network snooper-dude has revieled that the toaster is not interleaving the NFS packets very well. Thus, client machine A gets a bunch of i/o, then B, then back to A, then C, etc... It feels like the NFS "daemon" is running in non-pre-emptive task-switching mode. (Did someone slip MS Windoz code in here ?) The older 330's (still running 3.x) do not exhibit this behaviour. Any comments/ideas would sure be appreciated... The toaster in question is running 4.0.1c as mentioned, with CIFS and HTTP disabled. - C. Doerbeck

1 0

raid swap and dump problem
by lasse＠sics.se 08 Sep '97

08 Sep '97

Hi, When doing a `raid swap' I get this warning, > raid swap ** WARNING ** You can NOT swap a disk into or out of the system: a dump is currently running on a local tape device and you must wait until the dump is completed, or abort the dump before reissuing the "raid swap" command. But there is no dump running, the last dump was aborted, DUMP: ran out of tape, and can't ask questions when run via "rsh". DUMP: The ENTIRE dump is aborted. Is there a lockfile which should be removed? How do I abort the dump I can't find? Thanks, Lasse

1 0

Re: alternate drives, RAM for NetApp 630
by sirbruce＠ix.netcom.com 06 Sep '97

06 Sep '97

On 09/06/97 01:07:45 you wrote: > Yeah, doubtful. ;-) Our third-party drives were bought to >Netapp's specs, down to the firmware revision. The canisters were >supplied by OSS, who stock Digital StorageWorks products. The only >difference there is the wiring leading to the two LED's on the front >cover. There are different types of StorageWorks cannisters. I doubt that is the "only" difference. Just FYI. But I don't think the specific specs for these are available anywhere. Bruce

2 1

Re: alternate drives, RAM for NetApp 630
by sirbruce＠ix.netcom.com 06 Sep '97

06 Sep '97

On 09/05/97 23:28:40 you wrote: > The ironic thing is, of the 16 Netapp-supplied drives and the 12 >third-party ones we are using, two drives have failed so far (since >April): both were Netapp drives. :-/ At least the replacement >drives were shipped promptly. I'm not saying this *did* happen, but it's worth noting that if you have "good parts" and "bad parts" together it is possible for the *bad* part to make the *good* part fail... the drive may have sent some illegal or incompatible sequence that locked the other one up. Consider also a network card who follows the rules, but winds up getting killed by some rogue system on the network sending malformed packets. I agree, both need to be fixed, but proper compatibility can often avoid such lingering bugs. Another possibility - higher performing components will fail faster, generally speaking. Perhaps the Netapp drives provide better performance for lower MTBF (doubtful, but worth mentioning). Bruce

2 1

Re: quotas to track disk usage
by sirbruce＠ix.netcom.com 06 Sep '97

06 Sep '97

On 09/05/97 23:58:50 you wrote: >> A "quota convert qtree" command would be great, even if it took >> hours to accomplish for a large directory structure. > > Can't you create the quota tree, and then use something like tar >to copy/delete files into the quota tree while preserving the >directory structure? As discussed earlier, you'd want to use something like cpio, but yes. The point is that could take a long time for 10s or 100s of Gigabytes of data, wheras the filer itself could theoretically do the process faster (it doesn't have to copy files; just set the appropriate tree id). Bruce

1 0

Re: quotas to track disk usage
by sirbruce＠ix.netcom.com 06 Sep '97

06 Sep '97

On 09/05/97 02:55:47 you wrote: > >>> - Quotas trees are not usable because you can't mv files from one >>> quota tree to another (according to the docs). > >> The docs are slightly misleading here... sure, you can mv files from >> one to another, but they get copied, not moved. This should not >> generally be a problem (it's just like a separate mount point). > >Could someone from NetApp provide more detail here? I'm sure you can >move from one point to another over NFS, but if you are working from >/, you can't do an NFS rename call from one tree to another? What >happens when you try to use mv? Yeah, I'm not sure what would happen if you mount / and try to do the move from one tree to another. But if you mount them separately it won't make any difference (you probably do that anyway, since you want to confine the quota to just /home and not the whole filer). The mv command just does a copy instead. >What can't you do from a NFS/SMB client point of view? Again, I'm not sure what would happen with the root share, but between shares it will just copy (and then delete if you actually specified a move). >> 1. You have to create the quota tree first... if you already have a >> /home and directories in it, you can't "convert" them into a quota >> tree. You have to start with a new directory from scratch, crated >> via the "quota qtree newhome" or something similar. > >Ugh. If we get another filer, sure, but doesn't do much good for me >now. Yep. I complained bitterly about this years ago when a filer was set up the wrong way without a quota tree. You couldn't fix it after the fact. IMHO this is a big problem, as most admins won't understand quota trees when they first start using the filer, and once they do, it's too late to change. A "quota convert qtree" command would be great, even if it took hours to accomplish for a large directory structure. >> What Netapp really needs to do is a default quota report by uid/gid >> type of command on the filer, to avoid the need to set up quotas to >> track usage. > >Agreed. It looks like I'm stuck using "du" for now. Well, don't take me as definitive... maybe someone else has an idea. Bruce

2 1

Nice hidden command: mv
by Daniel Quinlan 06 Sep '97

06 Sep '97

(I'm assuming this mailing list is still active.) As an ice-breaker (teaser?), I thought I would share a useful hidden command that is present in NetApp Release 4.1d (and probably most others). It isn't listed in any online help (well, that's almost true) or documented anywhere, but you can use it anytime on the console. Note: I found this command on my own (i.e., it was not disclosed to me by NetApp). hostname> help mv rename files hostname> mv usage: mv file1 file2 hostname> mv /test1 /test2 I'd like to see more information and discussion on this mailing list: - problems you have experienced - any diagnostic utilities - undocumented commands - backup systems, experiences, etc. - Your experiences with other vendors (Auspex, Falcon, etc.) (positive or negative) - experiences with different NetApp models - using NetApps in growing or rapidly changing environments (for example, problems with having to move trees of data around often) - using more than a few NetApps - using one NetApp from multiple buildings (switching, routing, etc.) - performance tips, techniques, advice - and so on... I'll be making more postings in the not-too-distant future. Hopefully, things will pick-up a bit. Dan -- Daniel Quinlan (at work) Linux, our last best hope for Unix quinlan(a)transmeta.com http://www.pathname.com/~quinlan/ ... (Got BOFH? Looking for good ones.)

7 6

Re: Nice hidden command: mv
by guy＠netapp.com 06 Sep '97

06 Sep '97

> In many cases they aren't "safe" to use, and > you can be sure they certainly don't go through the usual QA cycle. Yup. If it's not documented, it's not supported, even though it might be useful. (I've filed a bug saying that our whole collection of undocumented commands needs cleaning up. Note that "cleaning up" in many cases may mean "removing from the system" - a whole *pile* of commands are there solely to provoke the system to do things for testing purposes inside development, for example. In some other cases, it may mean, making information available to support people, and maybe to end-users, but not necessarily committing to keeping the interface the same henceforth and forever more, world without end, amen. In other cases, it may mean leaving the command around for now, but not documenting it, because changes to the system in the future may obviate the need for it, at which point we'll remove it.) > Now, I'm not saying mv is dangerous (I don't know the code), but I > would not be surprised if it didn't fail to lock certain buffers > properly in multiuser operation, or not update the filesystem > correctly for CIFS attributes, or any number of other problems. Actually, "mv" happens to be Pretty Damn Simple - it does a pile of standard WAFL operations to look up the containing directories and then the standard WAFL rename operation (and uses an internal-to-Data-ONTAP(R)(TM)(LSMFT) routine to do it, so it's about 12 lines of code - counting blank linkes and curly braces), so it shouldn't, in theory, cause those problems (and won't do any better at moving stuff out of a snapshot than would a "mv" command on a UNIX box or a "ren" command on a DOS/Windows box; moving stuff out of a snapshot isn't exactly trivial), but... > I wouldn't want to risk the possibility of corruption and/or a crash > unless it was an "approved" Netapp command. ...that's definitely the case; undocumented means unsupported and, quite likely, untested, and also means "not guaranteed to stick around forever".

3 2

NetApp and FDDI
by Alexei Rodriguez 06 Sep '97

06 Sep '97

Anybody else out ther using FDDI for their NetApp and using Sun's as clients? We have been seeing some odd behavior at times. Looking through the logs on the clients, we have "NFS server not responding" errors (for 0 sec duration) across all the clients. Those that beat more heavily on the NetApp (like one box that constitutes 70% of the traffic) has these every few minutes. We have also had the NetApp stop serving NFS over the FDDI interface. Taking the interface down and bringing it back up has solved the problem. But what is the root of this problem? Bad NIC? Any suggestions? Thanks. Alex

6 7

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