toasters

toasters@lists.teaparty.net

13531 discussions

RE: Optimal volume size
by Kelly Wyatt 20 Sep '00

20 Sep '00

One drawback... someone has to remember to add the new qtree to the backup list each time. And why could you not restore specific qtrees from a volume backup in the same order? Kelly -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Senior Systems Programmer Strategic Recovery SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com <http://www.sas.com/> SAS... The Power to Know -----Original Message----- From: Eli Lopez [mailto:Eli.Lopez@netapp.com] Sent: Wednesday, September 20, 2000 3:28 AM To: Clarke, John L. (CIS); toasters(a)mathworks.com Subject: Re: Optimal volume size Hi guys, Backuping on a qtree level gives one very important advantage in case of disaster recovery: You can restore the qtrees on the failed volume in ORDER of importance to the organization. E.g. restore the mail qtree first and the library archives last. Regards, Eli ----- Original Message ----- From: Clarke, <mailto:John_Clarke@bose.com> John L. (CIS) To: 'toasters(a)mathworks.com' <mailto:'toasters(a)mathworks.com'> Sent: Tuesday, September 19, 2000 7:38 PM Subject: RE: Optimal volume size a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow. -----Original Message----- From: Louis Brune [ mailto:lbrune@sd.us.am.ericsson.se <mailto:lbrune@sd.us.am.ericsson.se> ] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters(a)mathworks.com Subject: Re: Optimal volume size Fortunately for me, someone else here takes care of backups, but... We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger. Can you not back up with qtree granularity instead of per volume? b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks. You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group. c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer. Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad. -- Louis

1 0

RE: upgrading from 5.2.3 to 5.3.6.R2
by Kelly Wyatt 20 Sep '00

20 Sep '00

If you use a third party backup solution, you should check to make sure that the backup software/ONTAP combination is supported. That has been the biggest headache for my group lately. Kelly -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Senior Systems Programmer Strategic Recovery SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com SAS... The Power to Know -----Original Message----- From: jmiddlebrooks(a)datalink.com [mailto:jmiddlebrooks@datalink.com] Sent: Tuesday, September 19, 2000 6:35 PM To: toasters(a)mathworks.com Subject: upgrading from 5.2.3 to 5.3.6.R2 Any tricks when upgrading from 5.2.3 to 5.3.6R2 aside from making sure the filer is at the correct firmware revision? Do you loose you qtree information or snapshots? Is there a doc on the NOW site on the steps to take to do this particular upgrade. Hopefully it is as simply as untaring the files to the filer and typing download and reboot. Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

1 0

Solaris 2.5.1, stat/read/fcntl random freezes on NFS
by Brian Tao 20 Sep '00

20 Sep '00

Has anyone experienced a Solaris 2.5.1 (103640-29, in this case) NFS client block on a stat(), read() or fcntl() call only to a particular file (or small number of files)? We've seen this happen on rare occasions in the past. For no apparent reason though, a plague has hit our web server farm in the past week or so. We've had five or six instances recently where the only solution was to reboot the server. What happens is that a seemingly random file sitting on the Netapp can no longer be read or stat'd or locked by the Solaris client. There is no suspicious lock activity. Even an innocent "cat" or "ls -l" on the file (triggering one of the above sycalls) will hang. A truss shows that the syscall never returns. Other Solaris clients mounting the same filesystems have no problems accessing those files. The reboot is necessary because there is always at least one Apache httpd process (the first one to see this problem?) that becomes unkillable, thus port 80 is never unbound, and a new parent cannot be started. After a reboot, everything returns to normal. One of our servers had to be rebooted this morning. Eight hours later, it was wedged trying to access that same file, plus another one on the same NFS filesystem. At this point, I'm blaming Solaris (easy target ;-)), but I have no hard evidence that would incriminate the OS, the application, the network, or the filer. Rebooting the server seems to fix the problem (at least temporarily), suggesting an OS bug. We've never seen this happen with anything besides Apache, suggesting an application bug. However, the three most recent "problem" files have all been on the same exported filesystem on the same Netapp. Filer bug? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

3 3

Fw: Optimal volume size
by Eli Lopez 20 Sep '00

20 Sep '00

1 0

Re: Optimal volume size
by Eli Lopez 20 Sep '00

20 Sep '00

RE: Optimal volume size Hi guys, Backuping on a qtree level gives one very important advantage in case of disaster recovery: You can restore the qtrees on the failed volume in ORDER of importance to the organization. E.g. restore the mail qtree first and the library archives last. Regards, Eli ----- Original Message ----- From: Clarke, John L. (CIS) To: 'toasters(a)mathworks.com' Sent: Tuesday, September 19, 2000 7:38 PM Subject: RE: Optimal volume size a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow.

1 0

RE: Optimal volume size
by Clarke, John L. (CIS) 20 Sep '00

20 Sep '00

a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow. -----Original Message----- From: Louis Brune [mailto:lbrune@sd.us.am.ericsson.se] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters(a)mathworks.com Subject: Re: Optimal volume size Fortunately for me, someone else here takes care of backups, but... We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger. Can you not back up with qtree granularity instead of per volume? b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks. You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group. c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer. Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad. -- Louis

2 1

upgrading from 5.2.3 to 5.3.6.R2
by jmiddlebrooks＠datalink.com 20 Sep '00

20 Sep '00

Any tricks when upgrading from 5.2.3 to 5.3.6R2 aside from making sure the filer is at the correct firmware revision? Do you loose you qtree information or snapshots? Is there a doc on the NOW site on the steps to take to do this particular upgrade. Hopefully it is as simply as untaring the files to the filer and typing download and reboot. Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

2 1

ssh without password
by Pravin Nair 20 Sep '00

20 Sep '00

Hi, I am trying to find a way to run commands remotely on the filer using ssh from a nfs administrative host. Since Oracle data is on the filer , My basic intention is to bring oracle in warm backup mode , create a snapshot and bring it back to normal mode .I want to automate this process and run it as cron job. The problem is I don't want to use rsh and netapp tells me there is no way to run ssh on the filer without specifying password. Can anyone suggest a way out! Thanks Pravin

2 1

RE: Optimal volume size
by Clarke, John L. (CIS) 19 Sep '00

19 Sep '00

Jeff, We did a local volcopy, moving data from one volume of 18GB FCAL drives to another volume of 36GB drives. It was all internal to the filer. We only have one FC-AL adapter on our F740. We got some volcopy specs from NetApp and the max write speed was something like 18MB/sec for sequential writes. If you did 180GB in 1hr and 20 min, that is around 33MB/sec. How did you manage that? Thanks John > > c) If you upgrade disks/shelves in the future, you will likely do it a > > volume at a time. We did this with a volume with 180GB and the volcopy took > > 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that > > should be 2-2.5x longer. > > How did you run the volcopy? Over the network or local > inside a single filer? What kind of head(s)? > > We've found volcopy to be extremely fast, especially for upgrading disks > and/or migrating data. In fact, we used volcopy to relocate and replicate > a huge chunk of data when Louis' company and ours split and it was a > life saver. We were using F760's, but it took about 1 hr. 20 minutes to > volcopy ~180GB. That was all in one head that had both a FC-AL adapter and > dual SCSI adapters. >

1 0

RE: Optimal volume size
by Mike Sphar 19 Sep '00

19 Sep '00

Our latest server has been configured such that the paths are *almost* identical for UNIX and Windows clients. Essentially, on Windows the UNC paths are \\servername\path\to\files and on UNIX (using automounter) the paths are /servername/path/to/files. Our build group loves it because they now have their build scripts dynamically adjusting the slashes depending on which client they run on, but the actual paths can be set in master config files without regard to which client will read it. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, September 19, 2000 10:36 AM To: Louis Brune Cc: toasters(a)mathworks.com Subject: Re: Optimal volume size Hi Louis!! =) Our biggest volumes are 500GB. That is NetApp's recommendation for largest volume size in DOT 6.0 which supports up to 1.5 TB volumes. The problem is that the smaller the volume, the more administrative overhead. Its nice to have one volume on smaller capacity machines because NFS exports and CIFS shares all point at "/some_data" rather than "/vol/vol0/some_data". This also causes difficulties with naming schemes since we like to see the qtree == cifs share (i.e. /some_project == \\filer\some_project). If you have multiple volumes than which of /vol/vol0/some_project and /vol/vol1/some_project is the one pointed at by CIFS share "\\filer\some_project". This statements are nit-picky on my part, but hey, we like to use the KISS principal and multi-volume is just another thing to think about. More on this stuff... On Tue, Sep 19, 2000 at 07:47:17AM -0700, Louis Brune wrote: > We have a similar situation on our F740. We want to keep the volume size > small because: > a) Restores can take forever as the data size gets bigger. > > Can you not back up with qtree granularity instead of per volume? I agree. Backup per qtree. Per volume will take forever on restores, especially for small sets of data. There are one or two drawbacks to per-qtree backups, but at least one of those is fixed in DOT 6.0. =) > b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 > disks go bad at one time is much rarer than 2 out of 51 disks. > > You can beat this by using several raid groups per volume. Of course, > you need a parity drive for each raid group. Again, Louis is on track here. With DOT 5.0 and above, they support multiple RAID groups per volume. Each RAID group can be n-1 on disks and still run fine which achieves the data protection you're looking for. > c) If you upgrade disks/shelves in the future, you will likely do it a > volume at a time. We did this with a volume with 180GB and the volcopy took > 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that > should be 2-2.5x longer. How did you run the volcopy? Over the network or local inside a single filer? What kind of head(s)? We've found volcopy to be extremely fast, especially for upgrading disks and/or migrating data. In fact, we used volcopy to relocate and replicate a huge chunk of data when Louis' company and ours split and it was a life saver. We were using F760's, but it took about 1 hr. 20 minutes to volcopy ~180GB. That was all in one head that had both a FC-AL adapter and dual SCSI adapters. > Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be > nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 > MB/second. If this is on 100 MB, it's not all that bad. Yes! They do have ndmpcopy which will do filer-to-filer data copying, however, there have been bugs posted to toasters regarding it. Something that performed filer-to-filer, per-qtree data moves would be fantastic! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: reconnect cifs-share at logon
by Hawley, Rob 19 Sep '00

19 Sep '00

Are you using UNIX type authentication (with clear text passwords)? If so, then you are running afoul of a security fix in Windows. The fix requires that the user manually enter a password to avoid you password being compromised. If you are using domain authentication then this should be working for you. Please contact NetApp customer support and let us help you with this problem. Rob Hawley -----Original Message----- From: Ulrich Neumann [mailto:ulrich.neumann@brose.de] Sent: Tuesday, September 19, 2000 9:53 AM To: toasters(a)mathworks.com Subject: reconnect cifs-share at logon does anybody know why reconnect cifs-share at logon will not work with a toaster? i shared a directory and the users manually connect this and set the "reconnect at logon". but after the next logon the mapping is not restored. home-dirs on the toaster will be mapped and also all the shares included in the logon-script. (theres no line in the script to cut the connection ;-) ) the client work all with nt4-clients. with shares on a normal nt4-box we've no probs. greetings from germany Ulrich Neumann

1 0

reconnect cifs-share at logon
by Ulrich Neumann 19 Sep '00

19 Sep '00

does anybody know why reconnect cifs-share at logon will not work with a toaster? i shared a directory and the users manually connect this and set the "reconnect at logon". but after the next logon the mapping is not restored. home-dirs on the toaster will be mapped and also all the shares included in the logon-script. (theres no line in the script to cut the connection ;-) ) the client work all with nt4-clients. with shares on a normal nt4-box we've no probs. greetings from germany Ulrich Neumann

1 0

RE: NetApp/Budtool - poor backup performance
by Rainchik, Aleksandr (MED, Non GE) 19 Sep '00

19 Sep '00

What is scary, is that both hosts - Netapp(slow) and E450(fast) are on the same subnet and have the same network settings 100/full-duplex. The other thing is E450 is pretty busy all the time, with lots of traffic and CPU load - and you can backup it fast, and NetApp is practically not loaded - and it's so slow to backup. -----Original Message----- From: Juan Torres [mailto:torres@susq.com] Sent: Monday, September 18, 2000 4:37 PM To: Rainchik, Aleksandr (MED, Non GE) Cc: toasters(a)mathworks.com Subject: Re: NetApp/Budtool - poor backup performance this is just one of our requests : SIZE TIME PERF HOST PARTITION L KB HH:MM:SS KB/sec STATUS ------------------------------------------------------------------------ ------ {filer} {volume} 0 100558438 08:45:50 3187.59 Success We have dual F720s with trunked 100mb interfaces on a switched network. Our backup host is an E450 with an L11000 locally attched to it with DLT7000s. Using BudTool we have ndmp requests streamed over the wire. Also, our backup host is multi-homed having one of it's interfaces on the same subnet as the filers. (your answer was already in your message) If the backup host you were using (the slow one) is not on the same subnet as the filers and same interface speed, that's where you're bottleneck is (routing and/or bandwidth). BTW: you're safer going over the wire. we've had some libraries hang the scsi bus of the filer when locally attached. -- ******************************************* ** Juan Torres ** Susquehanna Partners, GP. ******************************************* "Rainchik, Aleksandr (MED, Non GE)" wrote: > > Hello, > > We have F720 NetApp that holds about 100Gb of data and we are backing it > up > trough the network, not with directly connected tape. Why? F720 comes > with > differential port for tape connection and our nice tape library is all > single-ended. > > We are using Budtool to do that and it's all done via NDMP. > > And what we have is 1024 K/sec backup speed. So it takes about a 24 > hours > to finish Level 0 on filer. There is a Sun E450 on the same subnet, > plugged to > the same switch, both at 100 full-duplex, going to the same media > server. > And backups are 3 times faster there. > > Is there something I can tweak on filer? Like change priority of ndmpd > process, > something to speed up backups? > > Can you let me know what is your backup speed in NetApp/Budtool > configuration? > > Thank you. > > P.S. We are thinking about getting differential to single-ended SCSI > converters. > Any experience with such converters?

1 0

RE: Legato/NetApp backup troubles?
by Mike Sphar 19 Sep '00

19 Sep '00

We've tried to use it with our filers, but found it so unreliable we were still doing backups over NFS just to be safe. And since our backups administrator has been unable to get any useful support out of Legato, we've pretty much abandoned the Networker Client in the hopes that we'll be dumping Networker altogether in the next year. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Scott Mikusko [mailto:guerilla@concentric.net] Sent: Monday, September 18, 2000 4:36 PM To: toasters(a)mathworks.com Subject: Legato/NetApp backup troubles? Hello, I know only a few people out there are probably using the Legato Client Pak for Netapp in order to backup their filers, but I figured I'd relate a couple observations I'm seeing with Legato. I have a number of filers with volumes ranging from 60-250Gb, and saving via a private network to my backup server. The client pak from Legato is a tempermental software pakcage to say the least. It's very dependent on which version of ONTAP you are running (like 5.3.5R2P2), and sometimes causes the connections initiated by the backup server to be refused... for no reason I can see. Anyone else notice this? Another rather annoying problem is that my save streams to tape seem to unexpectedly terminate for no apparent reason. I'll have a group of saveset running, and they either just exit out completely, or I get messages of inactivity timeouts. I upped my timeout threshhold to 180 minutes, although I would default of 30 would be fine. I'm suspecting that perhaps my larger volumes (200Gb) are somehow failing because of performance issue with the client software on the filer. I've looked over my network stats on the filers (using ifstat), and see a moderate number of dropped frames in receive. I would think there would be more transmit errors. Anyone else out there notice any weirdness with their client pak?? I don't know if I can wait another 3-5 months for Legato's NDMP solution. They seem to be really behind compared to Veritas. According to Legato, it's going to be at least after December before the NDMP is supported. trying to avoid going back to NFS-mounted backups.... -Scott

1 0

Legato/NetApp backup troubles?
by Scott Mikusko 18 Sep '00

18 Sep '00

Hello, I know only a few people out there are probably using the Legato Client Pak for Netapp in order to backup their filers, but I figured I'd relate a couple observations I'm seeing with Legato. I have a number of filers with volumes ranging from 60-250Gb, and saving via a private network to my backup server. The client pak from Legato is a tempermental software pakcage to say the least. It's very dependent on which version of ONTAP you are running (like 5.3.5R2P2), and sometimes causes the connections initiated by the backup server to be refused... for no reason I can see. Anyone else notice this? Another rather annoying problem is that my save streams to tape seem to unexpectedly terminate for no apparent reason. I'll have a group of saveset running, and they either just exit out completely, or I get messages of inactivity timeouts. I upped my timeout threshhold to 180 minutes, although I would default of 30 would be fine. I'm suspecting that perhaps my larger volumes (200Gb) are somehow failing because of performance issue with the client software on the filer. I've looked over my network stats on the filers (using ifstat), and see a moderate number of dropped frames in receive. I would think there would be more transmit errors. Anyone else out there notice any weirdness with their client pak?? I don't know if I can wait another 3-5 months for Legato's NDMP solution. They seem to be really behind compared to Veritas. According to Legato, it's going to be at least after December before the NDMP is supported. trying to avoid going back to NFS-mounted backups.... -Scott

2 1

NetApp/Budtool - poor backup performance
by Rainchik, Aleksandr (MED, Non GE) 18 Sep '00

18 Sep '00

Hello, We have F720 NetApp that holds about 100Gb of data and we are backing it up trough the network, not with directly connected tape. Why? F720 comes with differential port for tape connection and our nice tape library is all single-ended. We are using Budtool to do that and it's all done via NDMP. And what we have is 1024 K/sec backup speed. So it takes about a 24 hours to finish Level 0 on filer. There is a Sun E450 on the same subnet, plugged to the same switch, both at 100 full-duplex, going to the same media server. And backups are 3 times faster there. Is there something I can tweak on filer? Like change priority of ndmpd process, something to speed up backups? Can you let me know what is your backup speed in NetApp/Budtool configuration? Thank you. P.S. We are thinking about getting differential to single-ended SCSI converters. Any experience with such converters?

4 3

Optimal volume size
by Moshe Linzer 18 Sep '00

18 Sep '00

We are moving from a 630 with a single 350GB volume (51x9GB SCSI) to a new 760 with 14 36GB disks. Our Netapp support recommends creating a 14-disk raid group, with a single raid group per volume (giving us a maximum volume size of around 400GB). I understand why 14 disks is a good number for a raid group (balance chances of disk failure vs efficient use of disks), but what is the reasoning behind keeping volume size down to around 400GB? Is it just dependant on restore time from tape? In which case, as faster tapes become available (LTO?), this number should increase. Does it also lessen chances of file system corruption on the volume, or is it just a warm fuzzy feeling that all your eggs (so to speak) are not sitting in one 1.2 terabyte volume? If my max volume size will remain the single raid group, I would like to divide my data into 2 smaller volumes from the start, so I don't start off with a maxed-out volume. This means using a time-consuming ndmpcopy or rsync process to move the data, instead of the faster volcopy or snapmirror. Thanks for your insights. Moshe

1 0

Re: Media Allocation problem
by Steve Kappel 18 Sep '00

18 Sep '00

Oye Akintan wrote: >Does anyone know a work around Error code 96: unable to allocate new >media for backup, storage unit has none available? The problem is that >we have a Quantum DLT4700 with 6 slots. I've used it to run successful >backups twice. The problem now is that I can't use the configured media >anymore because Media manager doesn't recognize the volumes as new >tapes. It still believes the tapes are the first tapes used. It only try >to access two of the tapes and when it does, it fails and freezes the >tapes. I've tried unfreezing the tapes using bpmedia command running the >backup again but it still fails. Also I've add the following to my >bp.conf file: >ALLOW_MULTIPLE_RETENTION_PER_MEDIA >ALLOW_MEDIA_OVERWRITE = CPIO >ALLOW_MEDIA_OVERWRITE = TAR >ALLOW_MEDIA_OVERWRITE = ANSI >ALLOW_MEDIA_OVERWRITE = AOS/VS >ALLOW_MEDIA_OVERWRITE = DBR > >Any help will be greatly appreciated. Please contact VERITAS support. http://support.veritas.com/ Numbers can be found at http://support.veritas.com/phonesup/phonesup_ddProduct_NETBACKUPDC.htm __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

RE: alternative to ApplianceWatch
by Geiss, Glen 18 Sep '00

18 Sep '00

ciao, you might be interested in looking at MRTG ( http://now.netapp.com/NOW/tools/ ). The description from NOW: This package uses the MRTG (Multi Router Traffic Grapher) to provide web-based monitoring for Filers. It provides a current and historical view (the last day, week, month, and year) of statistics for network traffic, CPU load, disk usage, and NFS and CIFS operations. This package includes some Pearl scripts and binaries for Solaris (sparc), Linux (x86), HP-UX, and FreeBSD (x86). thanks, glen -----Original Message----- From: Bui, Marcus [mailto:Marcus_Bui@aimfunds.com] Sent: Thursday, September 14, 2000 10:39 AM To: Toasters (E-mail) Subject: alternative to ApplianceWatch Importance: Low I am in search of a application to monitor two F760s. ApplianceWatch can monitor the filers but it runs on HP OpenView. However, I don't have a test environment with OpenView at the moment. Is there other alternative that is comparable to ApplicianceWatch? cheers, Marcus Bui Aim Management Group IT Services phone: 713-986-9061 fax: 713-986-9100 email: marcus_bui(a)aimfunds.com

1 0

Media Allocation problem
by Oye Akintan 18 Sep '00

18 Sep '00

Does anyone know a work around Error code 96: unable to allocate new media for backup, storage unit has none available? The problem is that we have a Quantum DLT4700 with 6 slots. I've used it to run successful backups twice. The problem now is that I can't use the configured media anymore because Media manager doesn't recognize the volumes as new tapes. It still believes the tapes are the first tapes used. It only try to access two of the tapes and when it does, it fails and freezes the tapes. I've tried unfreezing the tapes using bpmedia command running the backup again but it still fails. Also I've add the following to my bp.conf file: ALLOW_MULTIPLE_RETENTION_PER_MEDIA ALLOW_MEDIA_OVERWRITE = CPIO ALLOW_MEDIA_OVERWRITE = TAR ALLOW_MEDIA_OVERWRITE = ANSI ALLOW_MEDIA_OVERWRITE = AOS/VS ALLOW_MEDIA_OVERWRITE = DBR Any help will be greatly appreciated.

1 0

solved: creating a share with vba on a filer
by Ulrich Neumann 18 Sep '00

18 Sep '00

hi anybody, we solved the problem (tnx to jim! and his coworker!) the filesystem up to 6.0 is case-sensitive! we changed the prog to reflect the structure on the filer and - it works! ulrich -----Ursprüngliche Nachricht----- Von: Uren, Jim [mailto:jim.uren@netapp.com] Gesendet: Montag, 11. September 2000 19:47 An: 'Ulrich Neumann' Betreff: RE: creating a share with vba on a filer My co-worker suggests that case-sensitivity could also be something to check. In the NetApp release 6.0, CIFS path lookups are case-insensitive but except for that release they are sensitive to upper/lower case. This has caused frequent problems. Good luck--Jim Uren > -----Original Message----- > From: Uren, Jim > Sent: Monday, September 11, 2000 10:03 AM > To: 'Ulrich Neumann'; toasters(a)mathworks.com > Subject: RE: creating a share with vba on a filer > > > Hi Ulrich, > from a DOS prompt, typing > net helpmsg 2116 > reveals this-- > The device or directory does not exist. > EXPLANATION > You specified an unknown device or directory. > ACTION > Check the spelling of the device or directory name. > > so checking the pathname as suggested below seems > like a good idea. as I recall, if you wish to use > the "vol" form of the filename, you will want to > put C$ in the pathname, such as: > \\filer\c$\vol\vol0\sharename\directory > but the > \\filer\share\directory > format should work just fine. check to see if > c:\> dir \\cobfile01\users$ > succeeds or not for example. > Jim U > > > -----Original Message----- > > From: Hawley, Rob [mailto:rob.hawley@netapp.com] > > Sent: Monday, September 11, 2000 7:31 AM > > To: 'Ulrich Neumann'; toasters(a)mathworks.com > > Subject: RE: creating a share with vba on a filer > > > > > > Your program looks correct. We do support using level 502 to > > add a share. > > Please confirm a couple of points that could be the source of > > the problem: > > > > 1. The user running the script is a member of either the > > filer's Administrators > > group or is a member of Power Users. That is required for NT > > compatible > > security. > > 2. That the path vol\nt01\users is the correct physical path > > to where the user's > > directory should be created. That is there are no other > > directories in the path. > > > > If neither of these resolve your problem, then please contact > > NetApp customer > > support. They will need a packet trace of this exchange and a > > cifs sessions -s > > of the user attempting to execute the script. CS can help you > > if you are > > unfamiliar with how to get a packet trace. > > > > ~~~~~~~~~~~~~~~~~~~ > > mailto: hawleyr(a)netapp.com US Mail: Network > Appliance Inc. > > Windows Networking Engineering 495 E Java Dr > > Phone/pager: 408-822-6661 Sunnyvale, CA 94089 > > http://www.netapp.com > > > > > > -----Original Message----- > > From: Ulrich Neumann [mailto:ulrich.neumann@brose.de] > > Sent: Monday, September 11, 2000 2:01 AM > > To: toasters(a)mathworks.com > > Subject: creating a share with vba on a filer > > > > << File: ShareErr2116Filer.txt >> we just turned our > > user-home-shares from a > > nt-server to a filer. > > for creating new user-shares, we use a selfmade program in vb. > > unfortunately this program woun't work now with the filer. > > > > neither "c:\vol\nt01\users\username" nor > "\\cobfile01\users$\username" is > working. > there's always the error 2116.(see sub makeshare in attached code) > > is there anybody out there who has a good idea to solve this problem? > > > greetings from > > brose GmbH & Co KG > Client-Server-Technologien > > Ulrich Neumann >

1 0

RE: RFE: Network boot capavility in NetApp firmware
by Reidenbach, Edward 17 Sep '00

17 Sep '00

Thanks for the feedback on this functionality. We will review the functionality requested and the implementation efforts. Ed Ed Reidenbach Manager, Data ONTAP, Multiprotocol and High Availability Network Appliance Phone: 408-822-6167 Email: edr(a)netapp.com -----Original Message----- From: Manny Kaiser [mailto:mkaiser@mmcnet.com] Sent: Saturday, September 16, 2000 1:11 AM To: Jeffrey Krueger Cc: toasters(a)mathworks.com Subject: Re: RFE: Network boot capavility in NetApp firmware Hi, I have offically raised this request with Netapp about a year ago. Anyone from Netapp wish to comment? Jeffrey Krueger wrote: > I'd like to propose an RFE and see what everyone else things about it. If > everyone would just add their comments on, that would be great. I suppose > this is an RFC for an RFE. =) > > Once we all feel comfortable with the RFE, it would be great if we could > all forward it up our sales/support channels. Something tells me we aren't > the only customer who would like to see this feature. =) > > -- Jeff > > ***************************************************************************** > RFE: Network boot capability in NetApp firmware > > WHAT: > ===== > Add the ability to boot the OS from the network using a command such > as "boot net" from the filer firmware "ok>" prompt. > > WHY: > ==== > Current booting options are from floppy disk or from SCSI/FC-AL primary > storage. Adding the ability to do this over the network from a BOOTP/TFTP > server would allow: > > 1) Quicker/easier ONTAP upgrades and repairs > 2) Ease of use in a lab environment > > Quicker/easier ONTAP upgrades and repairs: > ------------------------------------------ > Currently, upgrading between some major OS releases requires booting at > least once from floppies. Considering that with ONTAP 6.0 three floppies > are necessary, it is extremely difficult for one person to simultaneously > upgrade many machines in one physical location and impossible to upgrade > machines in different physical locations. Additionally, when a NetApp has > a non-bootable root volume due to corruption or less than n-1 disks > visible, the only option is to boot with a floppy. This means downtime > until someone can build the correct boot disks to resolve the problem and > physically reach the machine with those floppies. Even in a single > building this process can take several minutes. On a large campus, a trip > to the filer could take up to an hour, and for remote sites it could be > days. > > With network booting, the new OS image could be put into place and several > machines in any location can be upgraded in lockstep simply by accessing > the serial console and executing "boot net" on each one. NetApp advertises > 5 minute downtime for upgrades which is true in the single-filer > environment. Any customer with 30+ filers in more than one location knows > that a full production upgrade can take much longer. Repairing a machine > would be much easier with Network boot since disks would not have to be > built, yet the filer could be booted from any image necessary without > anyone physically traveling to the machine. Network booting also removes > the risk of having built a bad floppy which occurs frequently. > > Ease of use in a lab environment: > --------------------------------- > Our lab environment is also difficult to manage with the current set of > boot options. We run several variants of ONTAP in the lab including one or > two versions that are currently in production for testing new hardware and > configuration changes and many new versions for testing new hardware and > new features. To manage this, we do a boot from floppy and menu choice #4, > initialize all disks, to two NetApp hard drives for each OS. This approach > has many disadvantages including a massive consumption of hard drives in > our lab, the tedious and time consuming process of initialize and setting > up a new filer, and the maintenance of configuration across several > different OS's on the same machine. > > With network booting we would not have to waste a pair of disks ONTAP for > each new ONTAP version we test - a single pair will do. The disk > initialization process would only have to be executed once instead of once > per ONTAP version. Finally, we could manage one set of configuration files > for all different versions. > > Granted, some major OS versions have incompatible WAFL formats and > configuration files; however, maintaining a different set of disks between > major releases is much easier than doing it between each release, no matter > how minor. > > HOW: > ==== > We'll leave the implementation up to Network Appliance; however, we suggest > that they use standards based ways of doing this. Filer IP resolution > could be done using RARP/BOOTP and/or DHCP. The former are probably easier > and are fairly standard for "in-firmware" address resolution. DHCP is > probably more code to write, but might be necessary for NT-only customers. > For boot-file transmition, TFTP would work just fine and servers are > available for both UNIX and NT.

1 0

RFE: Network boot capavility in NetApp firmware
by Jeffrey Krueger 16 Sep '00

16 Sep '00

I'd like to propose an RFE and see what everyone else things about it. If everyone would just add their comments on, that would be great. I suppose this is an RFC for an RFE. =) Once we all feel comfortable with the RFE, it would be great if we could all forward it up our sales/support channels. Something tells me we aren't the only customer who would like to see this feature. =) -- Jeff ***************************************************************************** RFE: Network boot capability in NetApp firmware WHAT: ===== Add the ability to boot the OS from the network using a command such as "boot net" from the filer firmware "ok>" prompt. WHY: ==== Current booting options are from floppy disk or from SCSI/FC-AL primary storage. Adding the ability to do this over the network from a BOOTP/TFTP server would allow: 1) Quicker/easier ONTAP upgrades and repairs 2) Ease of use in a lab environment Quicker/easier ONTAP upgrades and repairs: ------------------------------------------ Currently, upgrading between some major OS releases requires booting at least once from floppies. Considering that with ONTAP 6.0 three floppies are necessary, it is extremely difficult for one person to simultaneously upgrade many machines in one physical location and impossible to upgrade machines in different physical locations. Additionally, when a NetApp has a non-bootable root volume due to corruption or less than n-1 disks visible, the only option is to boot with a floppy. This means downtime until someone can build the correct boot disks to resolve the problem and physically reach the machine with those floppies. Even in a single building this process can take several minutes. On a large campus, a trip to the filer could take up to an hour, and for remote sites it could be days. With network booting, the new OS image could be put into place and several machines in any location can be upgraded in lockstep simply by accessing the serial console and executing "boot net" on each one. NetApp advertises 5 minute downtime for upgrades which is true in the single-filer environment. Any customer with 30+ filers in more than one location knows that a full production upgrade can take much longer. Repairing a machine would be much easier with Network boot since disks would not have to be built, yet the filer could be booted from any image necessary without anyone physically traveling to the machine. Network booting also removes the risk of having built a bad floppy which occurs frequently. Ease of use in a lab environment: --------------------------------- Our lab environment is also difficult to manage with the current set of boot options. We run several variants of ONTAP in the lab including one or two versions that are currently in production for testing new hardware and configuration changes and many new versions for testing new hardware and new features. To manage this, we do a boot from floppy and menu choice #4, initialize all disks, to two NetApp hard drives for each OS. This approach has many disadvantages including a massive consumption of hard drives in our lab, the tedious and time consuming process of initialize and setting up a new filer, and the maintenance of configuration across several different OS's on the same machine. With network booting we would not have to waste a pair of disks ONTAP for each new ONTAP version we test - a single pair will do. The disk initialization process would only have to be executed once instead of once per ONTAP version. Finally, we could manage one set of configuration files for all different versions. Granted, some major OS versions have incompatible WAFL formats and configuration files; however, maintaining a different set of disks between major releases is much easier than doing it between each release, no matter how minor. HOW: ==== We'll leave the implementation up to Network Appliance; however, we suggest that they use standards based ways of doing this. Filer IP resolution could be done using RARP/BOOTP and/or DHCP. The former are probably easier and are fairly standard for "in-firmware" address resolution. DHCP is probably more code to write, but might be necessary for NT-only customers. For boot-file transmition, TFTP would work just fine and servers are available for both UNIX and NT.

6 8

RE: RFE: Network boot capavility in NetApp firmware
by Mike Sphar 16 Sep '00

16 Sep '00

Not that I don't think having the option of booting from network is a good idea, but are people really booting from their floppies that often? Of the three filers I have in production, the only time I've ever had to boot them from floppies was during initial install and for firmware upgrades. I haven't booted off floppy for an OnTap upgrade in a long time, in fact I can't remember ever doing it, though I may have with much earlier versions. One of the things I love most about the filers is being able to do a live OS upgrade, with only a very few minutes of downtime for the reboot afterwards. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Hal Siegel [mailto:hal.siegel@amd.com] Sent: Friday, September 15, 2000 7:25 AM To: Jeffrey Krueger Cc: toasters(a)mathworks.com Subject: Re: RFE: Network boot capavility in NetApp firmware On Thu, 14 Sep 2000, Jeffrey Krueger wrote: > RFE: Network boot capability in NetApp firmware > > WHAT: > ===== > Add the ability to boot the OS from the network using a command such > as "boot net" from the filer firmware "ok>" prompt. I'll agree with you on that concept. I've also been trying to convince Netapp that they need to change "boot from floppy" to "boot from CD" ever since the boot disk became two disks. (heck, I still have some floppies floating around somewhere from the days that the entire OnTap OS fit on a 3.5" ...) Perhaps we should be requesting both network *and* CD boot capabilities. Hal Siegel _---_ / Senior Systems Engineer(ing) YY()))))\ /| Texas Microprocessor Division (@@) )))))/ Advanced Micro Devices /_/\__/__/ hal(a)beast.amd.com mm mm

4 3

RE: After branching ONTAP/VB can you ...
by Yee, Steven 15 Sep '00

15 Sep '00

Sorry about that folks, d*mn outlook address book. steve. > -----Original Message----- > From: Yee, Steven > Sent: Friday, September 15, 2000 12:12 PM > To: Ghouse, Mujtaba > Cc: Yee, Steven; Klinkner, Steve; Toasters (E-mail) > Subject: RE: After branching ONTAP/VB can you ... > > everything is correct (the same) EXCEPT ... > can you sync to the current change 78761 (that was our last checkin > on filerview/main) > > thanks, > > steve. > > -----Original Message----- > From: Ghouse, Mujtaba > Sent: Friday, September 15, 2000 12:05 PM > To: Yee, Steven > Cc: Klinkner, Steve; Thompson, Tim > Subject: RE: After branching ONTAP/VB can you ... > > Before I branch the new filerview, could you confirm (or deny): > > the name of the codeline: filerview:Rvb > the owner of the codeline: sdy > is this codeline frozen or open? [open] > the parent branch: [filerview:main] > change level or time at which you wish the branch to be sync'd: same as > Rvb ? > > thanks, > > -Mujtaba > > > -----Original Message----- > From: Yee, Steven > Sent: Friday, September 15, 2000 9:40 AM > To: Ghouse, Mujtaba > Cc: Yee, Steven; Klinkner, Steve; Thompson, Tim > Subject: After branching ONTAP/VB can you ... > > also branch the filerview tree for VB too ?? > > thanks, > > steve. >

2 1

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