toasters

toasters@lists.teaparty.net

13531 discussions

Start a nNew thread

Subscribe
by rickleft＠worldnet.att.net 23 Apr '98

23 Apr '98

1 0

subscribe
by Lisa Malgeri 23 Apr '98

23 Apr '98

1 0

chs/mtx
by Kelly Setzer 23 Apr '98

23 Apr '98

This is not directly on-topic, but considering the discussion lately... I am trying to find a utility like chs or mtx that will work under solaris 2 with an ATL P1000. I've had partial success with chs - it will move the robotics and move tapes from slot to slot, but will move a tape from a slot to a drive. 'mtx' is a product of Automated Network Technologies (anthill.com), which has apparently been acquired by Qualix Group. I've not been successful in finding 'mtx', and Qualix does not seem to know anything...grrr. Any info or other options? thanks, Kelly -- Kelly Setzer <setzer(a)telalink.net> The Telalink Corporation (615) 321-9100 x237 Fax: (615) 321-9110

1 0

Re: Budtool to backup netapp
by Jason D. Kelleher 23 Apr '98

23 Apr '98

In message <17AD4E991EBDD111B6E000A0C99DD8350BA1(a)ntmail05.pc.sas.com>, Alan Phoenix writes: >Has anyone tried using Budtool to backup a netapp? Yup. We've been using BudTool to backup our F330 for about 5 months. We spent a month or two working the kinks out of it before we let it touch our filer. Here's what we found: 1) BudTool's reporting is horrible. End of story. Anyone who tells you otherwise is either deranged or hasn't actually used the product. Fortunately, if you know Perl, writing a script to parse the logfile and send out a readable report (and page on fatal errors) is fairly trivial. 2) BudTool's built in scheduling could only have been written by a fool who liked GUIs and never actually had to support a backup solution in a production environment. cron and a small shell script handled this problem. (AMANDA has the best backup scheduling in my opinion. Someday there'll be a vendor who picks up on it.) 3) User level restores aren't supported for NDMP and only work for UNIX clients if your willing to throw security out the window. When doing a restore via NDMP, the destination for the restore has to be on a filer. If your users need to be able to restore data from tape, pick another product. If you're willing to pull stuff off tape for them (the GUIs not bad, but not great either) occasionally, then you'll be ok. 4) Having one BudTool server control a directly connected 100 tape DLT400 jukebox, a 5 tape stacker connected to our F330, and a 5 tape stacker connected to our research departments number cruncher is pretty nifty. Having all the tape and file histories in one place is nice too. 5) BudTool has a utility called btcp which will copy all your most current backup requests (Lev 0s and all necessary incrementals) to a set of tapes for offsite storage. It doesn't just dd a bunch of tapes. Very nice. Unfortunately, btcp is a little brain-dead and tries to copy _all_ the requests to one set of tapes. If you have a couple hundred GB worth of backups, this can take a really long time. Again, a little shell script fixed this problem. All in all, I don't think I've ever been 100% satisfied with any software product. But BudTool gets the job done (with a little help). jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Investment Group All opinions expressed are my own, etc, etc...

1 0

reboot of TLU -> reboot of fileserver
by Menachem Kaiser 23 Apr '98

23 Apr '98

Hi, I wanted to check out the following issue that was brought up in one of the responses to my poll (still waiting for more replies): When a TLU (tape Library Unit) is directly attached to a fileserver, does every reboot of the TLU necesarily mean you must reboot the fileserver? OR Is this only specific to the TLU vendor ( as suggested below). I see this as a serious issue!! I don't want the uptime of my fileserver to be affected by something like this. Manny Kaiser Email : mannyk(a)msil.sps.mot.com Unix System Administrator Phone : 972-9-9522-603 Motorola Semiconductor Israel LTD. Fax : 972-9-9562-990 1 Shenkar St. Industrial Zone Herzelia Herzelia 46120 Israel ============================================================================= ----- Begin Included Message ----- >From alexei(a)cancerman.cimedia.com Thu Apr 23 07:31:50 1998 >Received: from cancerman.cimedia.com (nat-a-29.cimedia.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA22939 for mannyk(a)msil.sps.mot.com; Wed, 22 Apr 98 21:26:58 MST To: Menachem Kaiser (Manny) <mannyk(a)msil.sps.mot.com> Subject: Re: backup and Restore questions Date: Thu, 23 Apr 1998 00:27:08 -0400 From: Alexei Rodriguez <alexei(a)cimedia.com> +--- In a previous state of mind, Menachem (Manny) Kaiser <mannyk(a)msil.sps.mo t.com> wrote: | | First many thanks for participating in this poll. No problem. My pleasure. | Why do you backup using only one stream of data. Actually, that may not be accurate. I think we break all the file systems into chunks and work on single chunks at a time. The main reason that we run a single stream (I need to verify) is that with one drive we did not gain too much. That may be incorrect. | Is this just a problem with your backup software? Don't know. I'll have to ask the backup person. Might be related to our installation. | You mentioned a very interesting note - attaching a jukebox | to the fileserver might mean that you will need to reboot the file | server from time to time. WHY? | When you reboot the tape library juke box - does this force | you to reboot the file server as well? If the stacker/jukebox hangs for whatever reason (robotic arm, etc), and you need to power-cycle the tape device, you cannot do so with the filer on. You run the risk of frying the scsi bus. Now, it could be that the problems I had were related to the specific DLT stacker (an ADIC vls library) we used. I don't know. I have not risked that sort of problem any more. Alexei ----- End Included Message -----

2 1

Re: backup times
by Mark D Simmons 23 Apr '98

23 Apr '98

> On 22 Apr 1998, Mark D Simmons wrote: > > -> > On Mon, 20 Apr 1998, Stephen Manley wrote: > -> > <Old thread stuff snipped> ... > expensive. Going the other route and putting, say, a DLT7000 on each > filer is also nuts. Cost for one of those around here (toronto, > ontario, canada) is something like $12500 plus the cost of a tape > monkey to run around and change tapes daily. We have all the above. It's not prohibitively expensive. The cost of the tape-monkey is amortised over the 100's of other systems he also tends. Don't forget the media costs 300quid/night for a 6dayx13 wk cycle... about 4 times the tape drive cost itself. > > BTW, my english parser keeps croaking over that CIFS statement.. Are > you referring to the lost of CIFS-specific file information by doing, > say, tar's over an NFS mount? If so, why? Doing a netapp-hosted dump > pointing at a remote box with rmt and a tape drive perserves all CIFS > specific information, afaik. Yeees, point, CIFS isn't an obstacle. > > > Why 1000mb ethernet? I'm not sure what filer and tape hardware > you have, but you think you need 128MByte/second throughput??!? In my dreams. As I've said before though, in utter seriousness I *do* want to be able to back up 400GB in about 6 hours. 400GB is 6 hours is 19MB/s sustained. Only atm and Gb-ether can provide that over the network. Locally two F/W SCSI channels will provide it happily. So... > <lots of good case material snipped> Seems like it's just a case of different strokes. > > ------------------------------------------------------------- > Dave Cole (DC1110) | dacole(a)netcom.ca > Systems Administrator | dacole(a)vex.net > | office/~dacole/ > Netcom Canada | www.vex.net/~dacole/ > 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 > Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725 >

1 0

Re: reboot of TLU -> reboot of fileserver
by sirbruce＠ix.netcom.com 23 Apr '98

23 Apr '98

On 04/23/98 08:31:55 you wrote: > >Hi, > >I wanted to check out the following issue that was brought up in >one of the responses to my poll (still waiting for more replies): > >When a TLU (tape Library Unit) is directly attached to a fileserver, >does every reboot of the TLU necesarily mean you must reboot the fileserver? No, it doesn't. At least with the TLUs I've used (Quantum DLT-4700, Breece Hill) a reboot of the filer was not necessary if the TLU was power-cycled. However, there was rarely any need the power cycle the TLU in the first place. Note that you can't properly "hot swap" a tape device on an off a filer, but I have seen it work before, although that's not properly supported and probably depends a lot of the specific filer, tape device, OS, and the phase of the moon. :) > >OR > >Is this only specific to the TLU vendor ( as suggested below). I think it's specific to that TLU vendor. >I see this as a serious issue!! >I don't want the uptime of my fileserver to be affected >by something like this. Understandable. I don't think it's different from any other backup server in this regard. >| You mentioned a very interesting note - attaching a jukebox >| to the fileserver might mean that you will need to reboot the file >| server from time to time. WHY? >| When you reboot the tape library juke box - does this force >| you to reboot the file server as well? > >If the stacker/jukebox hangs for whatever reason (robotic arm, etc), >and you need to power-cycle the tape device, you cannot do so with >the filer on. You run the risk of frying the scsi bus. I find this difficult to believe, considering the SCSI bus has to deal with, for example, the power supply on shelf suddenly failing, or the power supply of the stacker itself, etc. If one considers the case of a short power outage, you can't control wheter the filer or the stacker will get power first when it comes back on, so sometimes the filer will be on first. Surely equipment is robust enough to support this. >Now, it could be that the problems I had were related to the specific >DLT stacker (an ADIC vls library) we used. I don't know. I have not >risked that sort of problem any more. The risk, if there is one, would have to be very small. No more than the risk for any other incident relating to power, and the number of SCSI busses fried in those instances must be small. If you have a stacker that is hanging frequently, you're much better off worrying about fixing the stacker's hanging than the small chance of a SCSI bus being fried if you power-cycle. See also my earlier comments about the filer possibly having to be rebooted if you can't abort a dump/restore that was in progress when the stacker hung. But that is a software issue, not a hardware problem. Bruce

1 0

Budtool to backup netapp
by Alan Phoenix 22 Apr '98

22 Apr '98

Has anyone tried using Budtool to backup a netapp? Al

2 1

subscribe
by David West 22 Apr '98

22 Apr '98

1 0

Re: Restoring A LOT from snapshot
by sirbruce＠ix.netcom.com 22 Apr '98

22 Apr '98

On 04/22/98 09:37:47 you wrote: > >In message <199804221400.KAA21557(a)prospero.dma.isg.mot.com>, Christoph Doerbeck > writes: >> Solution 1: use 'find' and 'cpio' and transfer all the data back. this >> would appear to require 2x current capacity of the filer to replicate >> all data out of snapshot. if you're using >50%, this method would >> fail. > >If the files in question have been removed, rather than modified, this >will only copy the files that have been removed. On other files, it >will either refuse to copy because it thinks its copying a file onto >itself. It will complain the whole while (slowing things down), but it >will only add the space consumed by the deleted files. At least that's >what happened when I tried it in my home directory. An interesting observation. One example where having the snapshot FSID the same as the filesystem FSID is actually an advantage. :) Bruce

1 0

Restoring A LOT from snapshot
by Christoph Doerbeck 22 Apr '98

22 Apr '98

Question: When restoring from snapshot, is there a method which will not recreate data in the real data area. Example: Random files are removed throughout the filer. We decide to backtrack to Mondays snapshot. We plan to copy everything out of snapshot back to the real data area. Solution 1: use 'find' and 'cpio' and transfer all the data back. this would appear to require 2x current capacity of the filer to replicate all data out of snapshot. if you're using >50%, this method would fail. Solution 2: use 'find' and 'diff' and 'cpio' to enhance solution 1 with a check. Now only files which differ from the snapshot will be replaced. Solution 3: dump the snapshot to tape, and then restore from tape after removing existing snapshots. Solution 4: boot from floppy, use prev_cp and wack? Has anyone had any experience with 'prev_cp' and 'wack'? We're leaning at #4. Any comments would greatly be appreciated! ######################################## # Christoph Doerbeck # Motorola ISG # email: doerbeck(a)dma.isg.mot.com

2 2

Re: backup times
by sirbruce＠ix.netcom.com 22 Apr '98

22 Apr '98

On 04/22/98 11:15:20 you wrote: >Because if you have 8 filers, most, potentially all with > 20GB of >compressed data, putting an autochanger on each filer is prohibitively >expensive. Going the other route and putting, say, a DLT7000 on each >filer is also nuts. Cost for one of those around here (toronto, >ontario, canada) is something like $12500 plus the cost of a tape >monkey to run around and change tapes daily. While I agree that ultimately network backup is a cheaper and easier to manage alternative solution, I think you overstate the case against local backup. There are several key points that you need to be aware of in a network backup solution: 1. If you have a good (read - frequent) backup scheme, and your filers are large, you won't save on the number of DLTs you buy. Consider the case where those 8 filers all have to be backed up once/day, and it takes about a day to run the backup. You'll have to have just as many DLTs streaming away on that backup host as you would if each one was attached to it's own filer. Now, a more realistic example would probably allow you to cut the number of DLTs in half, but you will have to make sure your schedule everything properly. And can recover quickly if you have a failure. 2. You probably can't afford to saturate whatever network you already have, so you'll need a dedicated backup network. So gigabit is overkill, but once you factor in your 100mbit hubs, the possible need to buy additional network interfaces on your filer and the backup hosts to support this, not to mention the backup host itself, the cost differential is less than it first appeared. 3. You SHOULD have a tape monkey running around to change tapes daily. You don't want those tapes sitting there; you want them labeled and catalogged and shipped off-site. This doesn't change if you have a central backup solution, and at the very least you'll still have to change tapes just as often. Unless you get a library with a bigger tape capacity for your central server than you would for an individial stacker for each filer, which again is a price consideration. 4. You will incur a performance penalty, although with the more recent releases that penalty may be less than 10%. So, IMHO, network backup is probably more expensive at 4 filers, cheaper but not worth the hassle at 6, and only becomes really preferable at, say, 8 filers. But these numbers all depend on how big your filers are and how frequently you want to do your backups. Bruce

1 0

backup and Restore questions
by Menachem Kaiser 22 Apr '98

22 Apr '98

Hi, We are currently evaluating a network appliance solution for our site. We still have deep concerns about our abilities to backup such vast quantities of data from one source and even greater concerns on our ability to restore such vast quantities of data in the event of a disaster within a feasable time frame. I would like to hear from people about how they backup their systems - i.e.: What backup software do you use? What size is your file server and what size are the partitions? Is the tape directly connected to the file server or do you backup via the network? If you backup via the network, how is your file server interfaced to the network (dedicated backup network(s)? - 10/100 Mb/s?) Do you use ndmp? How many streams of backup do you use in parallel? What speed/rate do you backup (GB/Hr) per drive? Do you utilize more than one tape drive for backups? Have you needed to restore a file system? If so, how long did it take you (GB/Hr) ? Were you able to retore in parallel streams? Since the list of questions came out long, I will be more than happy to call you and poll you verbally on the above (send me your number). I will even be more than happy to post the statistical results of those willing to participate.

5 4

Re: backup and Restore questions
by Mark D Simmons 22 Apr '98

22 Apr '98

> Hi, > > We are currently evaluating a network appliance solution > for our site. > > We still have deep concerns about our abilities to backup > such vast quantities of data from one source and even greater > concerns on our ability to restore such vast quantities > of data in the event of a disaster within a feasable time frame. > > I would like to hear from people about how they > backup their systems - i.e.: > > What backup software do you use? A cron job on an admin host kicks off a full-filer dump on each of our erm 9-going-on-10 filers using rsh and loggid the output to backups-logs. > > What size is your file server and what size are the partitions? Ranging from piddly 50GB ones to reasonably meaty 200MB. > > Is the tape directly connected to the file server > or do you backup via the network? We have 4 Exabyte stackers, 3 DLT4700's and a single DLT4000 all directly attached to filers. When there's a tape drive problem (infrequent but hey they involve lots of moving parts) we get a little downtime during lunch or beginning/end of business and perform a quick halt-detach-reboot cycle, work on the drive while providing service, then do a halt-attach-reboot to bring it back together. Sometimes this stalls a lot of machines and it'd be ideal if we didn't have to do it but pretty much everything recovers, though we have to get brutal with locks the filer wishes to honour after reboot when in actual fact the client has just gone awol and won't talk to the filer about the lock... > > If you backup via the network, how is your file server > interfaced to the network (dedicated backup network(s)? - 10/100 Mb/s?) We've considered the option but we'd need a dedicated LAN to get the performance and avoid loading the production network on the basis that we do serve sites around the world. > > Do you use ndmp? Still waiting for it to mature and appear in products we feel happy to use and rely upon. > > How many streams of backup do you use in parallel? One per filer, cos we've only *currently* got one device on each filer. > > What speed/rate do you backup (GB/Hr) per drive? About 2.3MB/sec. (I reduced the numbers to that dimension and can't recall what they were in GB/hr - I'm sure you can work them out). > > Do you utilize more than one tape drive for backups? One drive per box though we're looking at two or more per box in future. > > Have you needed to restore a file system? Sadly yes, way back a year or so ago on an older box on an older release of the software we suffered a catastrophic loss of a box. It took me a long time to restore the bits we needed because I was, at the time, reduced to using ufs_restore from a Sun over the network. Still managed 1MB/sec though. Otherwise I just smugly cp things out of snapshots. > > If so, how long did it take you (GB/Hr) ? Days. > > Were you able to retore in parallel streams? Nope. > > > Since the list of questions came out long, > I will be more than happy to call you > and poll you verbally on the above (send me your number). > I will even be more than happy to post the > statistical results of those willing to participate. I hope people chip in - it'll be interesting to see if backups on filers has become customer-target no 1, now that there're so many good things in DOT5 to play with.

1 0

Re: Restoring A LOT from snapshot
by sirbruce＠ix.netcom.com 22 Apr '98

22 Apr '98

On 04/22/98 10:00:56 you wrote: > Solution 4: boot from floppy, use prev_cp and wack? > Has anyone had any experience with 'prev_cp' and 'wack'? > >We're leaning at #4. Any comments would greatly be appreciated! If support says #4 will work, and they'll "support" it, then I would choose that method myself. Bruce

1 0

Re: backup times
by Mark D Simmons 22 Apr '98

22 Apr '98

> > On Mon, 20 Apr 1998, Stephen Manley wrote: > > > > > Depends. What version of ONTAP are you running right now that you see > > > this behavior? > > > > sorry, good question. 4.3.1D5, and possibly also with 4.3.3. > > > > The basic data I know, Data ONTAP 5.0 runs significantly faster (50%?) than 4.3. > Furthermore, it should not crank at 100% CPU for minutes/hours at a time. > We've gotten to the point here that people don't really notice an effect > when we run dumps, anymore. > > Also, if I could ask a survey question of people (if this is not an acceptable > forum for this, just flame me ;) How do people out there use dump? > > 1) rsh to local drive. Currently our only backup possibility, it's working fairly well for now but as I've mentioned previsouly we're looking to seriously load our filers (before getting some more 8) and the backup times are looking daft! Specially as we do full backups every night, and will continue to do so until such time as we have a sterling installation of something like Veritas such that incrementals become manageable and reliable. > 2) rsh to remote drive. Why? streaming across the main network is a bad idea (tm) and CIFS put paid to the utility of the technique anyhow. > 3) NDMP to local drive. This is what I want to move toward, using tape-drives attached to the filer (ie where the data lives) and control across the network to a Veritas/other control box, where the indexes get kept. > 4) NDMP to remote drive. Doh! Only when we've got our dedicated Gigabit Ethernet backup network in place, which current estimates place around the next ice-age. > 5) I don't. > > Inquiring engineering minds are curious to know. :) Forgive my sarcasm in the above - you wouldn't believe the angst the word 'backup' causes around here at times. Plus I think I got out the cynical side of my bed this morning. > > Sm

2 1

Re: backup and Restore questions
by sirbruce＠ix.netcom.com 22 Apr '98

22 Apr '98

Just some comments from my own experiences with backup at Network Appliance: On 04/22/98 08:57:07 you wrote: >| Do you use ndmp? > >No. Although things have gotten better, directly attaching any device >with a robotic arm to a filer is not going to end in a pleasant way. >If the stacker hangs (as some do), you need to power-cycle the filer and >the stacker. This means downtime. I would rather reboot a dedicated >unix box that does backups (and will not interfere with anything). I can say that having used several DLT-4700 stackers attached to several filers over the years, I NEVER had one of those stackers hang. So I would have to say that this is pretty rare for the DLT-4700. If you use another stacker, I suppose it could be more of a problem. I did have some DLT-4000s fail, but nothing like an intermittent hang to be cleared via power-cycle; they busted completely, requiring them to be returned. It IS true that if your dump device goes out to lunch during a dump, and you started that dump via, say, rsh, you will have to reboot the filer to kill that dump session (otherwise you could ctrl-C). There was some talk of a dump abort command being done, and/or the notion that one might be able to use ndmp to kill that old session, but I don't know if either are possible with the latest software. However, rebooting was sufficient (no power cycle needed for the filer) to clear the session, and that usually takes less than 5 minutes, so downtime wasn't much of an issue either in those cases. For us, it was cheaper to have that directly attached device than to spend money on increased network infrastructure for network like dedicated gigabit, the dedicated UNIX server, the software, etc. For someone with different requirements, network backup might be the better way to go; it certainly scales better in the long run if you can set it up properly to start with. >| How many streams of backup do you use in parallel? > >I can only do 1 (only 1 drive). My friend does 4... >He also does something called vaulting. After a level0 >is done, the software then duplicates the tapes and spits them out. >Thus he sends the copies off site and can restore more effectively >in case of an emergency (no delay in getting tapes back). This software duplication sounds very cool... actually, something that did it in hardware would be even cooler. Allowing you to keep on copy on-site is a very nice idea. I'll have to try that in my next backup plan. >| What speed/rate do you backup (GB/Hr) per drive? > >Slow. 3-4GB/hr. My goal is to increase than an order of magnitude. >I would like to be able to restore 50GB in less than 1 hour. >AIT looks like the quickest (and least expensive) way of accomplishing >this. A word of caution here... I doubt changing your tape drive is going to increase your backup or restore times if you continue to do it via rsh dump/restore over the network, given the limitations of the software. Things may have improved with the more recent release, but my advice would be to either use local tape or use NDMP over the network if you want to get better performance. amd stick with DLT. To the original poster - Network Appliance can provide you with numbers for all of these things, and I can tell you that last year the numbers they were using were pretty authentic, having been put together from customers, in-house testing, and "real world" in-house testing (myself running the backups as an internal customer). I wouldn't have any reason to doubt the numbers they might give out today. Bruce

1 0

backup times
by Tom Yates 21 Apr '98

21 Apr '98

people are familiar with the temporary performance hole in one's toaster when starting a backup via "rsh toaster dump 0fqwerty etc. etc.", right? am i imagining it, or is it getting worse with later versions of ONTAP? it's got to the point where users are substantially hampered in working over the weekend when the backups kick off becasue CPU goes to 100% used and stays there for tens of minutes (and, for that matter, at various times during the backups). am i doing something wrong? Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

2 1

RE: "secret" rc_toggle commands
by Weeks, Thomas 21 Apr '98

21 Apr '98

[Weeks, Thomas] Since this is not an official NetApp supported site.. I would think this a good place to start this FAQ... BE FOREWARNED! THIS INFORMATION CAN BE LETHAL IF YOU DON'T KNOW WHAT YOU ARE DOING OR JUST START RUNNING SOME OF THESE COMMANDS! > From: Kelly Setzer [SMTP:setzer@telalink.net] > Sent: Tuesday, April 21, 1998 2:02 PM > To: Weeks, Thomas > Subject: RE: "secret" rc_toggle commands > > > Does anyone here have an FAQ on the rc_toggle_basic command set? > > > > I've know about them for a while now but have never been able to > make > > full use of them. > > > > I have printed out all the commands but don't want to run any of the > > unknown ones without knowing exactly what they each do... > > > > Netapp is kind of sensitive to this - they don't like it known that > the filer > does a lot more than is apparent. I guess it cuts into the > "simplicity" aspect > of the product. > > HOWEVER :) > > I think a FAQ is a noble cause. I'd like to go ahead and take a crack > at one. > If you could send me the list of commands, I'll send you back the ones > that I > know off the top of my head. I'll try to keep it going and publish it > (obliquely) on toasters. > [Weeks, Thomas] Here is the complete list that *I* have on my FS230/4.2x barium> rc_toggle_basic barium*> ? ? arp cifs date df download dump exportfs halt help hostname httpstat ifconfig license maxfiles mt ndmpd netstat nfs nfsstat options passwd ping raid reboot quota rdate restore route routed savecore setup shelfchk snap snmp sysconfig sysstat timezone uptime version wack ypwhich dbg dereference_null dd diskfs dumpblock dumpstack flake gdb getport getXXbyYY hard_hang hang help_dump ifstat lock_dump log mbstat mdumpb mdumpl mdumpw memdump newfs panic parityck printflag prof ps export_tbl_dump setflag sm_mon stack statit raid_fake_swap fs_size_limit sync syslog time wafl wafl_susp wafl_blkmap zero_divide ypcat ypmatch ypset bbdump ttcp rsh outb outw outl out inb inw inl in incfg outcfg pci_list pci_error_probe pci_error set_nv_interleave scsi_format scsi_inquiry scsi_capacity scsi_modeselect scsi_modesense scsi_readdefect scsi_swap scsi_fail scsi_reset scsi_insert_fault led_test led_test_one led_on led_off blink_on blink_off led_on_all led_off_all led_on_off isp_ram_read isp_ram_write isp_ram_test isp_term scsi_start scsi_stop scsi_test disk_write disk_test disk_read disk_zero disk_mung disk_stat tape_stat tape_write tape_read nv nvtest nfs_hist com disk_list disk_check disk_erase_label test_lcd test_fpleds read_serno write_serno watchdog de_srom_read de_srom_write fa show_emu emu_disable netdiag cmos_read cmos_write call cache_control perfmon mfgbist barium*> rc_toggle_basic barium> > Don't run 'zero_divide' - DOT is apparently math-impaired and does not > do > anything intelligent with X/0. It does reveal a sense of humor on the > part of > the developers. Did you notice that the file-system checker is called > 'wack'? > Most of the others seemed (relatively) harmless, or at least a little > more > obvious, some don't work at all. > [Weeks, Thomas] Hmm... Well... I'm afraid to run any on our filer as it is our main production box... Although I have already runa few that seemed to be obvious... Anyone documented any of these commands? How about giving us some feedback? (or just send it to Kelly since he has volunteered to start the FAQ.. that is.. unless NetApp doesn't mind providing some of us power users with some simple form of FAQ/docs... ;v) I can be descrete... Tom D Tek > > Kelly

1 0

load tracking
by Daniel Quinlan 21 Apr '98

21 Apr '98

Does anyone track or log the load (CPU, NFS ops, network in/out, etc.) on their Network Appliance boxes (over time)? If so, I'd like to hear about your experiences. Dan

4 4

"secret" rc_toggle commands
by Weeks, Thomas 21 Apr '98

21 Apr '98

Does anyone here have an FAQ on the rc_toggle_basic command set? I've know about them for a while now but have never been able to make full use of them. I have printed out all the commands but don't want to run any of the unknown ones without knowing exactly what they each do... I have used a couple of them (like scsi_inquiry and the like)... Thanx all... Tom D Tek

1 0

Re: load tracking
by Ketil Kirkerud Elgethun 21 Apr '98

21 Apr '98

Daniel Quinlan <quinlan(a)transmeta.com> writes: > Does anyone track or log the load (CPU, NFS ops, network in/out, etc.) > on their Network Appliance boxes (over time)? If so, I'd like to hear > about your experiences. We use mrtg to plot things like nfsops/sec, network i/o, disk space status, etc. All these data are collected using snmp, qhich is what mrtg usually does, anyway. This gives us, without too much hassle, a graph of tha last 24 hrs, last week, month and year - these graphs can be very useful to track down various problems (and to monitor available diskspace). Mrtg is free software, i can't remember off the top of my head where to find it, but it should be quite easy to find. If there's any interest I'm sure I can dig up some example configs from our setup. -- ---Ketil Kirkerud Elgethun, SOL System

1 0

None
by Gity Barghi 20 Apr '98

20 Apr '98

2 1

Filer and IIS
by Jimy Liu 20 Apr '98

20 Apr '98

Hi sirs: I have one filer share directory to one NT server.(NT mount filer's /home/www as its f:\ directory) And I set up Internet Information Server(IIS) Web's root directory as f:\ . Then I use brower to open NT's web page from IIS. The browser show "Can not find the object". And in IIS web directory setting shows "this directory access denied. But I can using brower to open file in f: directory . Why can not access through IIS ? There is must something wrong on filer or IIS . Jimy

4 4

Re: backup times
by sirbruce＠ix.netcom.com 20 Apr '98

20 Apr '98

On 04/20/98 11:37:38 you wrote: > >people are familiar with the temporary performance hole in one's toaster >when starting a backup via "rsh toaster dump 0fqwerty etc. etc.", right? > >am i imagining it, or is it getting worse with later versions of ONTAP? >it's got to the point where users are substantially hampered in working >over the weekend when the backups kick off becasue CPU goes to 100% used >and stays there for tens of minutes (and, for that matter, at various >times during the backups). am i doing something wrong? I know in a previous version, we ran into a problem where the CPU pegged high when scanning a deep directory tree, hundreds or thousands of entries deep, that someone had created. I believe this impact was alleviated in later releases but I can't be certain of that having not tried it myself. So, unless your filer is just heavily loaded and/or short of memory when doing your backup, I'd suspect something like a deeply nested directory tree. Perhaps you can locate it an remove it. Then again, it could be something entirely different. :/ Bruce

1 0

Jump to page:

2026

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