toasters

toasters@lists.teaparty.net

13515 discussions

seeing constant not responding messages
by Chris Caputo 21 Sep '97

21 Sep '97

I just the sent the following to support@netapp, but was also curious if anyone here had any insight. Is everyone on 4.1d happy? Chris ---------- Forwarded message ---------- Date: Thu, 18 Sep 1997 11:47:53 -0700 (PDT) From: Chris Caputo <ccaputo(a)alt.net> To: support(a)netapp.com Hi. We constantly (several times a minute) get the following and I have a feeling (because the drive lights go dark) it is affecting the performance of our NetApp box. At some point discussion on the toasters mailing list made me think that this was something that was going to be fixed after 4.0.1c, which is what we are running. Can you let us know if this is fixed in 4.1d? Should we upgrade regardless? Thanks, Chris Caputo President, Altopia Corporation PS: Here are the messages - they happen all of the time... Sep 18 11:43:51 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:52 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:43:55 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:56 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:43:57 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:57 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:43:59 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:43:59 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:03 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:04 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:07 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:07 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:08 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:08 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:09 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:09 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:11 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:12 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:14 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:14 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:21 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:21 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:25 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:25 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:26 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:26 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:30 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:30 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:32 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:33 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:36 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:36 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:36 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:37 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:39 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:39 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:40 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:40 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:42 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:42 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:43 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:44 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:44 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:45 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:49 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:49 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:51 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:51 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:44:56 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:44:56 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:01 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:01 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:01 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:02 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:03 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:03 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:04 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:05 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:06 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:06 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:11 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:11 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:15 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:16 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:19 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:19 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:24 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:24 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:30 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:35 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:35 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:41 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:42 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:47 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:48 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:48 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:49 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:49 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:45:50 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:50 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:45:50 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:04 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:05 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:13 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:13 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:15 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:15 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:33 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:33 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:39 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:40 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:42 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:42 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:43 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:43 tofu kernel: nfs server netapp1.alt.net:/home: is alive again Sep 18 11:46:44 tofu kernel: nfs server netapp1.alt.net:/home: not responding Sep 18 11:46:44 tofu kernel: nfs server netapp1.alt.net:/home: is alive again

3 5

NetApp for mail spool?
by Gregory Gulik 18 Sep '97

18 Sep '97

I have a feeling this topic has been discussed to death, but here goes anyway: Has anyone had luck with using a NetApp for a mail spool? We did some tests, and although the locking worked fine most of the time, we did find that it dropped some messages for no reason whatsoever. In our case, the client machines are SPARCs running Solaris 2.5.1 Is there a problem with the locking on the NetApp, or are the Solaris libraries lying about the locks being in place and the writes taking place properly?

5 4

Re: NetApp for mail spool?
by Gregory Gulik 17 Sep '97

17 Sep '97

Do you have recommendations on where to find examples of code that incorporates this stonger locking you mention? -----Original Message----- From: David Schairer <njal(a)concentric.net> To: matthew zeier <mrz(a)3com.com> Cc: madhatta(a)mathworks.com <madhatta(a)mathworks.com>; greg(a)wwa.com <greg(a)wwa.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Wednesday, September 17, 1997 5:57 PM Subject: Re: NetApp for mail spool?

1 0

"Interrupted system call" to F230 news spool
by Brian Tao 17 Sep '97

17 Sep '97

One of my inn 1.4unoff4 news reader servers started throttling itself just today with "Interrupted system call writing article file" (happened twice in the past 24 hours). The spool is on an F230 running 4.0.3, 256MB of read cache and 4MB of write cache. The news server is an Ultra 170, 512MB of RAM, ~250 to 300 readers around peak times. The two are on a FDDI ring. The F230 hovers around 65% CPU usage, so I don't think that's the problem, but the Ultra is reporting 900 to 1200 packets per second both in and out of its FDDI interface. Half of its time is spent in the kernel, according to top(1). The mounts are NFSv3 over UDP. Would dropping back down to NFSv2 help any? I'm trying to determine if this is a network congestion problem, or an OS limitation (on either the Netapp or the Sun). -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

3 3

Filer response time
by Dave Heiland 15 Sep '97

15 Sep '97

I'm looking for a way to monitor the performance of my F630 filer, in addition to checking cpu levels, network traffic or other information provided by sysstat. Specifically, since the LADDIS benchmarks plot nfs ops versus response time, I was wondering how I can check the response time of my filer from the client's perspective. Is it just a matter of running nfsstat -m on clients and checking the round-trip times, or is there another command or program that can be used? Dave -- David J. Heiland Lucent Technologies dheiland(a)lucent.com CIO Department Malmesbury, England

1 0

Pardon my ignorance
by Kevin L. Gross 11 Sep '97

11 Sep '97

Sorry to send to the entire list, but I can't find the original message from this list telling me how to get off of it, if there was one. Could some kind soul overlook my ignorance and tell me the address to send to in order to remove myself from this list? Thanks, -Kevin

2 1

Re: snapshot scheduling
by mds46523＠ggr.co.uk 11 Sep '97

11 Sep '97

This sounds like another task that would be easier if we could load servlets onto the filers. On Sep 11, 6:05, Daniel Quinlan wrote: > Subject: snapshot scheduling > One of our filers has high data turn-around so I have limited the > snapshot lifetime to 2 days (the default) to keep usage at about 10%. > We use 4 days on our other filer because it experiences a lower rate of > data turn-around. > > > snap list > working........................ > %/used %/total date name > ---------- ---------- ------------ -------- > 1% ( 1%) 0% ( 0%) Sep 10 20:01 hourly.0 > 3% ( 3%) 2% ( 2%) Sep 10 16:01 hourly.1 > 5% ( 3%) 4% ( 2%) Sep 10 12:01 hourly.2 > 6% ( 3%) 5% ( 2%) Sep 10 08:01 hourly.3 > 8% ( 4%) 6% ( 3%) Sep 10 00:01 nightly.0 > 8% ( 4%) 6% ( 3%) Sep 09 20:01 hourly.4 > 10% ( 4%) 7% ( 3%) Sep 09 16:02 hourly.5 > 12% ( 5%) 10% ( 3%) Sep 09 00:01 nightly.1 > > Unfortunately, 2 days means that if someone deletes a file on Friday, it > will be gone by the next work day, Monday. There is also a lower rate > of data turn-around on the weekend. 3 days would be ideal, except on > weekdays where it can sometimes push the snapshot usage higher than I > want. > > Is there some way (other than a remote cron job twice a week) to acheive > what I want -- variable snapshot lifetimes according to the day of the > week? > > If not, it would be a nice feature. Either that, or options to force > deletion of n number of nightly snapshots (over m days old) when > snapshot usage goes over some percentage. > > 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.) >-- End of excerpt from Daniel Quinlan -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. PTP: What sheeplike qualities should you be developing?

1 0

snapshot scheduling
by Daniel Quinlan 11 Sep '97

11 Sep '97

One of our filers has high data turn-around so I have limited the snapshot lifetime to 2 days (the default) to keep usage at about 10%. We use 4 days on our other filer because it experiences a lower rate of data turn-around. > snap list working........................ %/used %/total date name ---------- ---------- ------------ -------- 1% ( 1%) 0% ( 0%) Sep 10 20:01 hourly.0 3% ( 3%) 2% ( 2%) Sep 10 16:01 hourly.1 5% ( 3%) 4% ( 2%) Sep 10 12:01 hourly.2 6% ( 3%) 5% ( 2%) Sep 10 08:01 hourly.3 8% ( 4%) 6% ( 3%) Sep 10 00:01 nightly.0 8% ( 4%) 6% ( 3%) Sep 09 20:01 hourly.4 10% ( 4%) 7% ( 3%) Sep 09 16:02 hourly.5 12% ( 5%) 10% ( 3%) Sep 09 00:01 nightly.1 Unfortunately, 2 days means that if someone deletes a file on Friday, it will be gone by the next work day, Monday. There is also a lower rate of data turn-around on the weekend. 3 days would be ideal, except on weekdays where it can sometimes push the snapshot usage higher than I want. Is there some way (other than a remote cron job twice a week) to acheive what I want -- variable snapshot lifetimes according to the day of the week? If not, it would be a nice feature. Either that, or options to force deletion of n number of nightly snapshots (over m days old) when snapshot usage goes over some percentage. 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.)

1 0

Re: SCSI shelf faults?
by sirbruce＠ix.netcom.com 10 Sep '97

10 Sep '97

On 09/10/97 16:47:03 you wrote: >Sorry, I guess I should have said that I have 1 chain. Physically there >are two shelves. NetApp engineer installed the shelves. I suppose he >could have gotten it wrong. This is especially likely with new products with a limitation that is new but not widely advertised. But it's easy to check... just run in there and see if they are connected to the card or to the secondary connector on the back of the chasis. (sysconfig -v may or may not report the right stuff if it's miscabled. Bruce

1 0

Re: SCSI shelf faults?
by sirbruce＠ix.netcom.com 10 Sep '97

10 Sep '97

On 09/10/97 14:22:11 you wrote: > >I just received the following: > >Wed Sep 10 14:00:00 EST [statd]: *** NOTICE *** > Fault previously reported on SCSI storage shelf attached > to slot 8a has been corrected. >Wed Sep 10 14:00:39 EST [statd]: *** NOTICE *** > Fault reported on SCSI storage shelf attached to slot 8a. > Please check fan and power on shelf. >Wed Sep 10 14:00:41 EST [asup_main]: System Notification mail sent > >What the heck is going on? The first message says that the fault previously >reported was corrected. There was no fault previously reported, and then a >fault gets reported. This is a 630 with a single shelf. Should I be >worried about this? Is the single shelf attached to 8b on the SCSI card? I believe the instructions say it has to be attached to 8a first. I might be wrong, but the message is very similar to those I've seen if you have the shelves cabled incorrectly. I've never seen a system with one shelf, but I recall than on a system with 4 shelves (2 chains) you couldn't, for example, put one on one SCSI card and one on the other SCSI card. The 630 with the new shelves is much more sensitive to this than previous filer models. It shouldn't be a problem in normal operation, but it could result in the filer getting confused if there is a disk failure or you try to do a hot swap of a drive, etc. Bruce

2 1

SCSI shelf faults?
by rasmus＠bellglobal.com 10 Sep '97

10 Sep '97

I just received the following: Wed Sep 10 14:00:00 EST [statd]: *** NOTICE *** Fault previously reported on SCSI storage shelf attached to slot 8a has been corrected. Wed Sep 10 14:00:39 EST [statd]: *** NOTICE *** Fault reported on SCSI storage shelf attached to slot 8a. Please check fan and power on shelf. Wed Sep 10 14:00:41 EST [asup_main]: System Notification mail sent What the heck is going on? The first message says that the fault previously reported was corrected. There was no fault previously reported, and then a fault gets reported. This is a 630 with a single shelf. Should I be worried about this? The only thing I did that might have affected it was to set the time on the box. It was off by 9 hours. At around 13:35 I set the time to 13:35 and then when the 14:00 check rolled around it generated the above. -Rasmus

1 0

upgrading Pentium 90 on F330
by Daniel Quinlan 10 Sep '97

10 Sep '97

Is it possible to upgrade the Pentium 90 chip on an F330? (Haven't opened mine in a while... Is it in a ZIF socket?) Has anyone tried or looked into this? slot 0: System Board 90 MHz (NetApp System Board I rev-b) Memory Size: 256 MB I know it is possible to upgrade the entire head or move the disks to another array with the same size disks. 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.)

3 4

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

alternate drives, RAM for NetApp 630
by Wayne D. Correia 06 Sep '97

06 Sep '97

Hi, What's the current supported 9GB drive revision that works in the NetApp 630? Also, can someone confirm if the DEC Storageworks shelf model SWXSS-22 shelf works in a NetApp 630? That's the Storageworks shelf that DEC recommends for their 9GB drives that are actually Seagate ST-19171-W's. I just can not justify paying NetApp $3000 for a $1200 hard disk or $10,000 for 256MB of DRAM when it should cost no more than $1500. As far as testing does, I really doubt that NetApp can possibly perform any level of pre-sale burn-in testing to justify more than 400% markup on RAM, more than 200% markup on hard disks, and more than 300% markup on an empty DEC Storageworks shelf.

2 1

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

05 Sep '97

On 09/05/97 01:40:58 you wrote: > >Given these parameters: > > - I would like to use quotas to track user disk space usage (but not > limit it) Easily done, but there are some caveats. > - 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). > - I only want to track usage in /home/* only, not the entire disk > (since there are other areas on the filesystem that users use, but > I do not want included in the quota report. This can be done with the new 4.1 software. >Is this possible or are the docs wrong about #2 ? Take a look at the na_quota(1) man page and they provide just such an example of restricting user quotas per export. However, there are some caveats: 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. 2. Some clients can't deal with quotas great thatn 8GB, and there is currently no option on the filer to limit this (this is filed as a bug), so you'd have to restrict your users to 8GB. If you have any over that, you don't want them in the quota system. So, you'd want something like: # Quota Target type disk files # ------------- ----- ---- ----- /newhome tree * user@newhome 8G The first line might not even be necessary, but it's worth including just for reference. Hmm, unless it breaks the clients the same way. Maybe the 8G can be omitted from the user entry as well? I don't know, I haven't tried it. The line might also be ncessary for the file to be parsed properly. 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. Bruce

3 2

Re: drive enclosure options
by sirbruce＠ix.netcom.com 05 Sep '97

05 Sep '97

On 09/05/97 09:07:08 you wrote: > >We have a F220 and our first drive enclosure is the standard Digital >Storage Works one provided by NetApp. We are considering making our >second enclosure be an Adjile Systems Lynx enclosure, since we have had >good experience with them in other systems. > >We are wondering if there are any incompatibilities between the Lynx and >the F220. I know when a drive is "raid fail"ed with the DSW enclosure >that the lights indicate the drive is spun down and ready for removal. The >Lynx does not provide that kind of lighting, but it is designed for hot >swapping. I don't think any other enclosures are allowed except on a PVR and unsupported basis. I'm surprised if Netapp is changing this, as even different Storage Works enclosures have demonstrated problems with each-other, let alone other enclosures. 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