toasters

toasters@lists.teaparty.net

13515 discussions

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

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

15 Sep '00

//depot/prod/filerview/Rvb is available for check-ins -Mujtaba > -----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. >

1 0

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

15 Sep '00

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. >

1 0

RE: Network boot capavility in NetApp firmware
by Bokkelkamp Ernst SBS IP 17 M 1 15 Sep '00

15 Sep '00

http://www.nts.com See Shadow IPserver, it's also (another type of) appliance in the OpenServer version. Bye Ernie > -----Original Message----- > From: Bruce Sterling Woodcock [SMTP:sirbruce@ix.netcom.com] > Sent: Friday, September 15, 2000 2:12 PM > To: chris_good(a)webtop.com; toasters(a)mathworks.com > Subject: Re: Network boot capavility in NetApp firmware > > > I understood and agree with the original RFE but doing it > > both ways round would be extremely neat and elegant. A cluster > > could even do resiliant dhcpd which is a pain to do conventionally[*]. > > I think if you want a DHCPD server you need another appliance. :) > Something to do all your naming services too... > > Bruce >

1 0

RE: Network boot capability in NetApp firmware
by Mohler, Anissa 15 Sep '00

15 Sep '00

Jeff, There is an existing RFE for this capability - the RFE # is 20166. The description is not yet available on the NOW site... you can track this RFE using BugWatcher. For those that are not familiar with BugWatcher: Go to the NOW site http://now.netapp.com/ Click on Knowledge Center Click on Access Software Bug Tools Click on Bug Finder and put in the id 20166 Then at the bottom of the next page you will be able to select BugWatcher You will be notified when the bug is fixed (or if the RFE is completed) by e-mail. I've added your description to the RFE as well... Thank you! :-----Original Message----- :From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] :Sent: Thursday, September 14, 2000 2:11 PM :To: toasters(a)mathworks.com :Subject: RFE: Network boot capavility in NetApp firmware : : :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

RE: Using Omniback for CIFS backups -Reply
by Benn, Paul 14 Sep '00

14 Sep '00

Could these directories have been created by Macintosh systems (real question: do they have multiple streams)? -----Original Message----- From: Clarke, John L. (CIS) [mailto:John_Clarke@bose.com] Sent: Thursday, September 14, 2000 2:55 PM To: 'toasters(a)mathworks.com' Subject: RE: Using Omniback for CIFS backups -Reply Mark, We are backing up a snapshot directory. We see random results. Depending on the run, between 6 and 15 subdirectories underneath a group directory are simply skipped. No errors reported. John -----Original Message----- From: Muhlestein, Mark [ mailto:mark.muhlestein@netapp.com <mailto:mark.muhlestein@netapp.com> ] Sent: Thursday, September 14, 2000 5:15 PM To: 'James R Grinter'; Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: RE: Using Omniback for CIFS backups -Reply You should probably back up from a snapshot, which avoids open file issues. See Paul Benn's NT backup paper for an example of this: http://www.netapp.com/tech_library/3052.html <http://www.netapp.com/tech_library/3052.html> Note particularly section 5. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: James R Grinter [ mailto:jrg@acm.org <mailto:jrg@acm.org> ] Sent: Thursday, September 14, 2000 2:04 PM To: Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: Re: Using Omniback for CIFS backups -Reply On Thu, Sep 14, 2000 at 08:40:56AM -0400, Clarke, John L. (CIS) wrote: > The only problem is that Omniback seems to skip about 25% of the data, with > no error messages or anything. Using the regular Backup software that comes > with NT works fine. People tell me (I have to take their word for it - I'm not familiar enough with the product) that Omniback doesn't like to back up files that are open, so anyone with their Outlook, Word, or Excel apps open with files being edited over night are probably being missed. That theory is pretty easy to test - see what files aren't being backed up. James.

1 0

RE: Using Omniback for CIFS backups -Reply
by Muhlestein, Mark 14 Sep '00

14 Sep '00

The only thing that springs to mind is that you may be encountering an issue with snapshots of directories that are not in CIFS format, although I would think an error would be logged if that were it. See bug #15840. If that is the issue you can resolve it by setting an option to always create directories in CIFS format. If that is not the problem, we'll need to have you open a call with tech support and provide some packet traces and detailed information about your setup. Mark -----Original Message----- From: Clarke, John L. (CIS) [mailto:John_Clarke@bose.com] Sent: Thursday, September 14, 2000 2:55 PM To: 'toasters(a)mathworks.com' Subject: RE: Using Omniback for CIFS backups -Reply Mark, We are backing up a snapshot directory. We see random results. Depending on the run, between 6 and 15 subdirectories underneath a group directory are simply skipped. No errors reported. John -----Original Message----- From: Muhlestein, Mark [ mailto:mark.muhlestein@netapp.com <mailto:mark.muhlestein@netapp.com> ] Sent: Thursday, September 14, 2000 5:15 PM To: 'James R Grinter'; Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: RE: Using Omniback for CIFS backups -Reply You should probably back up from a snapshot, which avoids open file issues. See Paul Benn's NT backup paper for an example of this: http://www.netapp.com/tech_library/3052.html <http://www.netapp.com/tech_library/3052.html> Note particularly section 5. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: James R Grinter [ mailto:jrg@acm.org <mailto:jrg@acm.org> ] Sent: Thursday, September 14, 2000 2:04 PM To: Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: Re: Using Omniback for CIFS backups -Reply On Thu, Sep 14, 2000 at 08:40:56AM -0400, Clarke, John L. (CIS) wrote: > The only problem is that Omniback seems to skip about 25% of the data, with > no error messages or anything. Using the regular Backup software that comes > with NT works fine. People tell me (I have to take their word for it - I'm not familiar enough with the product) that Omniback doesn't like to back up files that are open, so anyone with their Outlook, Word, or Excel apps open with files being edited over night are probably being missed. That theory is pretty easy to test - see what files aren't being backed up. James.

1 0

RE: Using Omniback for CIFS backups -Reply
by Clarke, John L. (CIS) 14 Sep '00

14 Sep '00

Mark, We are backing up a snapshot directory. We see random results. Depending on the run, between 6 and 15 subdirectories underneath a group directory are simply skipped. No errors reported. John -----Original Message----- From: Muhlestein, Mark [mailto:mark.muhlestein@netapp.com] Sent: Thursday, September 14, 2000 5:15 PM To: 'James R Grinter'; Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: RE: Using Omniback for CIFS backups -Reply You should probably back up from a snapshot, which avoids open file issues. See Paul Benn's NT backup paper for an example of this: http://www.netapp.com/tech_library/3052.html Note particularly section 5. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: James R Grinter [mailto:jrg@acm.org] Sent: Thursday, September 14, 2000 2:04 PM To: Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: Re: Using Omniback for CIFS backups -Reply On Thu, Sep 14, 2000 at 08:40:56AM -0400, Clarke, John L. (CIS) wrote: > The only problem is that Omniback seems to skip about 25% of the data, with > no error messages or anything. Using the regular Backup software that comes > with NT works fine. People tell me (I have to take their word for it - I'm not familiar enough with the product) that Omniback doesn't like to back up files that are open, so anyone with their Outlook, Word, or Excel apps open with files being edited over night are probably being missed. That theory is pretty easy to test - see what files aren't being backed up. James.

1 0

Re: SNMP counter - integer overflow?
by Ketil Kirkerud Elgethun 14 Sep '00

14 Sep '00

Edward Henigin <ed(a)datafoundry.net> writes: > I'm surprised noone has pointed this out yet, but there is > no problem. All you are monitoring off of this are deltas. If at > time T the counter is -30000, and at time T' it's -29000, > > -29000 > - -30000 > ======== > 1000 > > So ops/sec are 1000 / (T' - T) > > The deltas work just fine, regardless of whether the counter > happens to be positive or negative. Except for rollovers. "interesting" things happen when the counter rolls from (approx) 2^31-1 to -2^31.. My mrtg-graphs have these wonderful spikes every few days bacause of this (yes, I can fix this, as well. I just don't have the time right now). -- ---Ketil Kirkerud Elgethun, Infostream ASP

1 0

SNMP counter - integer overflow?
by Henrique Pantarotto 14 Sep '00

14 Sep '00

Hello, I am monitoring nfs ops/sec in a F760 filer using MRTG, but the value that I am getting from the last few days are in "negative". I believe it happened an overflow in the integer type used to hold this data, right? Look: [root@foo /root]# snmpget filer-e0.terra.com.br public .1.3.6.1.4.1.789.1.2.2.1.0 enterprises.789.1.2.2.1.0 = -1281161705 I know I can fix this by rebooting the filer. But I don't want to do that. This is a F760 with Ontap 5.3.6.R2. It has a lot of traffic. ;-) Does anyone here knows of a solution to this problem? Thanks, _______________________________________________ Henrique Pantarotto SysOp Site São Paulo Terra Networks Brasil S/A A Internet mais sua do que nunca Tel: (11) 5505-5728 r.316/238 ICQ: 6934285 IT: henpa henrique(a)corp.terra.com.br

4 5

alternative to ApplianceWatch
by Bui, Marcus 14 Sep '00

14 Sep '00

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

2 1

RE: Using Omniback for CIFS backups -Reply
by Muhlestein, Mark 14 Sep '00

14 Sep '00

You should probably back up from a snapshot, which avoids open file issues. See Paul Benn's NT backup paper for an example of this: http://www.netapp.com/tech_library/3052.html Note particularly section 5. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: James R Grinter [mailto:jrg@acm.org] Sent: Thursday, September 14, 2000 2:04 PM To: Clarke, John L. (CIS) Cc: 'toasters(a)mathworks.com' Subject: Re: Using Omniback for CIFS backups -Reply On Thu, Sep 14, 2000 at 08:40:56AM -0400, Clarke, John L. (CIS) wrote: > The only problem is that Omniback seems to skip about 25% of the data, with > no error messages or anything. Using the regular Backup software that comes > with NT works fine. People tell me (I have to take their word for it - I'm not familiar enough with the product) that Omniback doesn't like to back up files that are open, so anyone with their Outlook, Word, or Excel apps open with files being edited over night are probably being missed. That theory is pretty easy to test - see what files aren't being backed up. James.

1 0

RE: Using Omniback for CIFS backups -Reply
by Clarke, John L. (CIS) 14 Sep '00

14 Sep '00

Tim, No, we are not doing NFS backups. We have an NT box as a trusted host and the NetApp disks appear as shares on that NT box (which is also the NT server with the tape drives attached. This is the same model as for Unix. Now, when I do the backups, I am essentially backing up an NT box, so all ACL's are preserved. The only problem is that Omniback seems to skip about 25% of the data, with no error messages or anything. Using the regular Backup software that comes with NT works fine. Seen anything like this? Thanks John -----Original Message----- From: Timothy Cook [mailto:TCOOK@JOY.COM] Sent: Thursday, September 14, 2000 7:39 AM To: John_Clarke(a)bose.com Subject: Using Omniback for CIFS backups -Reply I assume you are doing NFS backups, as at present OBII doesn't support NDMP. NFS backups WILL NOT preserve ACL's. We have the same problem and the only solution my research has come up with is to switch to an NDMP capable backup software and connect the tape library straight to the filer. >>> "Clarke, John L. (CIS)" <John_Clarke(a)bose.com> 09/12/00 01:57pm >>> > Hello, > > I am looking for anyone who is using Omniback II to back up a Network > Appliance via CIFS. We have an F740 mounted on the tape backup server as > shared disks and we are finding that Omniback does not want to back up all > the directories on the filer. > > Has anyone done this successfully? > > Thanks > John

2 1

RE: Backup software comparison
by Francett, Robert D (SAIC) 14 Sep '00

14 Sep '00

No (sorry), but would be interested in why Veritas NetBackup isn't on your list. Thanks, Bob Francett/BP Exploration -----Original Message----- From: Leigh David Heyman [mailto:leigh@ai.mit.edu] Sent: Thursday, September 14, 2000 8:05 AM To: toasters(a)mathworks.com Subject: Backup software comparison Hello, We are currently testing automated backup software products, for backup up our servers and NetApp filers via NDMP. We've narrowed our seach down to two products: Quick Restore from Workstation Solutions, and Backup Express from Syncsort. I'm wondering if anyone on this list has experience with either or both of these products and if so, would you care to share your opinions or experiences with them? Any input would be greatly appreciated. Thanks, -Leigh ===================================================================== Leigh Heyman, GCIA Artificial Intelligence Lab Systems Administrator Massachusetts Institute of Technology leigh(a)ai.mit.edu 617-253-1729

1 0

Re: Crappy message on Veritas Netbackup
by Steve Kappel 14 Sep '00

14 Sep '00

>I am in a processes of configuring veritas Netbackup on NetApps Filers >(840's) and unable to do that. The problem is that Netbackup doesn't allow >me to start two jobs at a time. If it schedules on job, the other job stays >queued and waits for the earlier job to finish. Can anybody suggest a >solution. > >Veritas Netbackup ver 3.2 with patch and NDMP pack. Are these jobs for the same filer? If so, I'd suggest reading the manual - configuration setting "Maximum Jobs per Client". __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

RE: NOW enhancement
by La Londe, Renee 14 Sep '00

14 Sep '00

Hi There, Thanks for the suggestion. We can definately display the action information (though this can be quite alot of info for some cases). Question: Would you be interested in just seeing the *last* action that was completed before the case was closed or the whole case action history? Best Regards, Renee E-Service Web Manager Get Answers on NOW (Netapp on the Web)! http://now.netapp.com -----Original Message----- From: Nail, Larry [mailto:lnail@ti.com] Sent: Wednesday, September 13, 2000 10:13 AM To: Subject: RE: NOW enhancement I second this suggestion.. -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Wednesday, September 13, 2000 10:44 AM To: toasters(a)mathworks.com Subject: NOW enhancement When I get email notification of a change in status of a support call, it looks something like: CASE #: xxxxxx.00000 SERIAL #: yyyyy Site: "mathworks" City: Natick Status: Closed Symptom: "CPU ECC ERROR; SYS ECC ERROR; DIMM=J27" Internal action associated with the case has been completed Actions due to be performed: --------------------------------------- Action: RMA Status: OPEN Due Date: Jul 6 2000 For further information, please view your case at "http://now.netapp.com/Self-Service/Forms/frmCaseView.asp?CaseId=xxxxxx.0000 0" If you reply to this mail please do not change the Subject line. Is it possible to include in this email the *changes* to the case? It is an annoyance to go to a web browser, login to the NOW site, and check. Seems like just enclosing the changed actions would be straightforward, and I can decide if I need to login to NOW to add comments or not. Thanks for listening. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

3 2

Crappy message on Veritas Netbackup
by Premanshu Jain 14 Sep '00

14 Sep '00

Toasterians, I am in a processes of configuring veritas Netbackup on NetApps Filers (840's) and unable to do that. The problem is that Netbackup doesn't allow me to start two jobs at a time. If it schedules on job, the other job stays queued and waits for the earlier job to finish. Can anybody suggest a solution. Veritas Netbackup ver 3.2 with patch and NDMP pack. Premanshu Jain IS Engineering Support Lead Nortel Networks, Carrier Packet Solutions IP Services Division 2305, Mission College Blvd, Santa Clara, CA 95054 Direct: (408) 565-3573 ESN: 655-3573 eMail: prjain(a)shastanets.com Web: http://www.nortelnetworks.com/ipservices

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