toasters February 2001

toasters@lists.teaparty.net

88 participants
116 discussions

vol copy from 5.3.6R2 to 6.0.1R1
by Brian L. Brush 20 Feb '01

20 Feb '01

I want to vol copy from an F230 running ONTAP 5.3.6R2 to an F760 running 6.0.1R1, but I encounter the following error: Filesystem version mismatch for destination volume vol1, reverting the version and aborting transfer. A console message will be displayed when this revert is complete. I can't upgrade the 230 to 6.0, and it's impractical for me to revert to 5.x on the 760. Is there any way for me to vol copy directly from the 230 to the 760? --Brian L. Brush Senior Systems Administrator Paradyne Corporation

1 0

RE: F85 series
by Lentz, Tim 20 Feb '01

20 Feb '01

Great info, thanks. Can I ask what the rough price point for the F85 (~400GB usable) is? We have a 230 that we need to upgrade and it sounds like the F85 would be a good fit. Thank you, Tim A. Lentz Staff Software Systems Engineer/Unix System Administrator for MCAD Ext. 8-3859 Direct: 303-702-3859 MS: 2120-1 -----Original Message----- From: Luke Mewburn [mailto:lukem@wasabisystems.com] Sent: Tuesday, February 20, 2001 10:29 AM To: White, Lance Cc: 'toasters(a)mathworks.com' Subject: Re: F85 series On Tue, Feb 20, 2001 at 08:16:55AM -0800, White, Lance wrote: > No, it uses FW Ultra SCSI-3 disks, not FC. Yes, NDMP backup is supported. > Limitations? Well, as it's positioned to be the NEW entry level Netapp (at > 3300 NFS ops/sec, it actually about 30% faster than the old low end F720, > and about 30% less expensive), it IS limited to 648GB MAX storage (6 > internal plus 12 external in 18GB & 36GB flavors), as opposed to the F720's > limit of ~500GB. Still doin' hot swap, RAID4, snapshots, OnTap, WAFL, > everything that's cool about a Filer and more! :-D The box sounds cool. It's about time a box of this price point was available again :) I have a (long-time) gripe in the way it's advertised. It's a gripe I have with every vendor. I wish NetApp would advertise the *usable* diskspace of the machine (as seen by a client OS or df, for example), not the raw diskspace calculated by taking the disk vendor size and multiplying by the number of disks. I know this makes the boxes appear more expensive per usable megabyte, but it's being more honest to the client, and once you explain to the client to take into account all the overheads, and how to do the same math on competing options (e.g, h/w raid + vxfs on Solaris, EMC, etc), then you (NetApp) appear to be delivering accurate technical information. For example, there's no WAY an F720 has 500 GB of usable space. Out of the box, with default snap reserve, it barely has 300 GB, where GB == 2^30, which is what client based tools (such as df and the `Properties' box in Windows) use, not 10^9, which is what (overzealous) disk vendors use. The usuable capacity of an F720 is trivial to calculate: 14 x 36 GB disks, utilised as: 1 hot spare, 1 parity, 12 data disks Each data disk has 24840 MB usable, calculated as: 34500 megabytes (rightsized by OnTAP) - 10% wafl overhead (is this 8% in OnTAP 6.x?) - 20% snap reserve (default; but often reduced to 10%) = 24840 megabytes So, 12 x 24840 = 298080 MB = ~ 291 GB Tweaking the numbers to 8% wafl overhead (from OnTAP 6) and 10% snap reserve gives an F720 approximately 334 GB of space (from 500 GB `raw'). Based on the info Lance White gives above, an F85 with 36 GB drives, consisting of 15 data disks, 1 hot spare, 2 parity, 8% wafl overhead, 10% snap reserve would have a usuable capacity at the client of: 15 x (34500 - 8% - 10%) = 15 x 28556 = 428490 MB = 418 GB 418 GB is a bit less than the ``648 GB MAX storage'' that Lance quotes above. In general, take away approximately one third of the raw capacity that NetApp quote and that will give you an guestimate on the usuable capacity that will suit most client's needs. Luke. PS: I'm sure some people have seen or heard this rant before :) Disclaimer: I like NetApp. I worked at NetApp for a while as an SE. I just believe in being honest to the technical people you're selling to, especially those who have to justify to their management why the (not cheap) 500 GB box they bought ran out of space at 300 GB. -- Luke Mewburn <lukem(a)wasabisystems.com> http://www.wasabisystems.com Luke Mewburn <lukem(a)netbsd.org> http://www.netbsd.org Wasabi Systems - providing NetBSD sales, support and services.

1 0

F85 series
by Clawson, Simon 20 Feb '01

20 Feb '01

Has anyone had any experince with the F85? Does it use the same disks as the 700 & 800's? Is it possible to back it up via NDMP? What are its limitations? Simon Simon Clawson HDS Team Systems Administrator Mentor Graphics Uk Rivergate London Road Newbury Berkshire RG14 2QB <<Clawson, Simon.vcf>>

1 0

Budtool 4.6.1Cannot Create File History
by Kenny Henderson 19 Feb '01

19 Feb '01

I have two Netapp 760s for which I use Budtool 4.6.1 to backup the filer's data. We have been running into a problem in which Budtool does not create a file history associated with a backup of the filers volumes. The backup reports that it completed successfully with the exception of not having created a file history. Without the backup file history the backup is more or less useless. Budtool reports the following error message after a scheduled backup of the filer has completed: "Error writing to file history command: Error code = -1" I have attempted to correct this problem by increasing the file history timeout as suggested by Legato's TechDialog support web site but the problem still exists. While examining the goserver diag log I found the following error message which is repeated throughout the diag log until the backup finishes: "L01 (:logfilter.c:310) 01/17/01 02:22:48> Unknown type 4d2 in dump image " The following associated error message was found throughout the goserver filer log: ****************************************************************** filter~header 2fh 2540 ------ E R R O R ------- filter~header 2fh 2541 Unknown type 4d2 in dump image filter~header 2fh 2542 ****************************************************************** It looks as though budtool receives a data type that it does not recognize and goes south as far as creating a file history log. I attempted to pull the file history off of one of the backup tapes put received the same "unknown type 4d2" error message. Any assistance with this problem would be greatly appreciated. Kenny Henderson henderka(a)risc.sps.mot.com

1 0

Budtool 4.6.1 Cannot Create File History
by Kenny Henderson 19 Feb '01

19 Feb '01

1 0

What backup products to use?
by Schepers, Jan 19 Feb '01

19 Feb '01

Hello gang, what exact backup products do I need to use to backup a NetApp filer. I'm interested in either : - Veritas's netbackup - Workstation Solutions Quick Restore - Legato's Netbackup rgds, Yann

1 0

RE: F720 vs. F520?
by White, Lance 19 Feb '01

19 Feb '01

To add to this, the F520 has single-ended disks, while the current supported SCSI adapters (for disk) is differential. The F520's SE card is not officially supported in an F720. Might work, but not supported. Lance -----Original Message----- From: Bond, Andrew [mailto:abond@netapp.com] Sent: Sunday, February 18, 2001 4:10 AM To: Jim Davis Cc: toasters(a)mathworks.com Subject: RE: F720 vs. F520? Jim, The numbers are available on the SPEC website www.spec.org. However, there are no directly comparable figures since the F520 was tested using SFS93 and the F720 using SFS97. I did some analysis of the relationship for another customer, and concluded that the F720 should have about 50% faster response time, and slightly higher maximum throughput. It also supports more storage capacity, at 500GB versus 250GB (raw capacity). You should talk to your local NetApp Sales Engineer regarding carrying the shelves over; it is possible, but has some restrictions. Regards, Andrew > -----Original Message----- > From: Jim Davis [mailto:jdavis@cs.arizona.edu] > Sent: 12 February 2001 22:06 > To: toasters(a)mathworks.com > Subject: F720 vs. F520? > > > We're looking to replace a couple of F520s with something newer (ie, > something we can get a support contract with). Neither F520 > system seems > stressed for CPU or NVRAM or physical memory, and we'd like > to have the > option of carrying over the current disk shelves if at all > possible. The > F700 spec sheet lists a "Relative Performance" number ("NFS > Ops per sec. > under 10 msec.) for the F720; is there a figure for the F520 somewhere > too? >

1 0

RE: F720 vs. F520?
by Bond, Andrew 18 Feb '01

18 Feb '01

Jim, The numbers are available on the SPEC website www.spec.org. However, there are no directly comparable figures since the F520 was tested using SFS93 and the F720 using SFS97. I did some analysis of the relationship for another customer, and concluded that the F720 should have about 50% faster response time, and slightly higher maximum throughput. It also supports more storage capacity, at 500GB versus 250GB (raw capacity). You should talk to your local NetApp Sales Engineer regarding carrying the shelves over; it is possible, but has some restrictions. Regards, Andrew > -----Original Message----- > From: Jim Davis [mailto:jdavis@cs.arizona.edu] > Sent: 12 February 2001 22:06 > To: toasters(a)mathworks.com > Subject: F720 vs. F520? > > > We're looking to replace a couple of F520s with something newer (ie, > something we can get a support contract with). Neither F520 > system seems > stressed for CPU or NVRAM or physical memory, and we'd like > to have the > option of carrying over the current disk shelves if at all > possible. The > F700 spec sheet lists a "Relative Performance" number ("NFS > Ops per sec. > under 10 msec.) for the F720; is there a figure for the F520 somewhere > too? >

1 0

RE: Replicating to filer
by Witham, John 18 Feb '01

18 Feb '01

When consolidating about 80G of group directories to a couple 760s, I used the NT ResKit's ROBOCOPY command. It was free, quick, and painless. Of course, it worked only because Administrators had full access to all the data. If you have locked yourself out of the directories, you may want to look at different software or doing a backup/restore. If you want to use RoboCopy, here's a sample command-line command-line: robocopy F:\Groups\IT Y:\ /V /S /E /SEC /NP /R:2 /W:2 /LOG:U:\IT.txt Description: The commmand is being run at the console of the NT File Server. F:\Groups\IT is the sourcedir, and Y:\ is mapped to the appropriate share on the filer. /V is Verbose /S is Subdirectories /E is Copy Empty Subdirectories /SEC is Copy NTFS permissions /NP is Don't Show Progress (Messes up when used with logging) /R:2 and /W:2 is retry twice and wait 2 seconds between retries /LOG:U:\IT.txt is dump logging to this location I manually had to stop and recreate shares. Not a big deal for ~15 group drives, but for ~1500 user shares, I'll be doomed. I'm looking at using the options cifs.homedirs but have had no time lately to play. Best of luck! -john John Witham Senior Data Networking Engineer Takeda Pharmaceuticals North America, Inc. V://847.383.3304 F://847.383.3205 mailto://jwitham@takedapharm.com -----Original Message----- From: Saklikar, Raj [mailto:Raj.Saklikar@netapp.com] Sent: Thursday, February 15, 2001 1:05 PM To: 'toasters(a)mathworks.com' Cc: 'dmatarazzo(a)ftc.gov' Subject: Replicating to filer I'm attending a class and am sending this from the instructor's email--please reply to this account or dmatarazzo(a)ftc.gov We are going to consolidate 4 NT servers to the filer and are looking for something that will replicate and then synchronize the shares, user directories and permissions. We have tested Fastlane's DM/Consolidator and I'm wondering if anyone has successfully used this or knows of another product that will enable us to accomplish this. Thanks.

1 0

RE: Virus scans on NetApps and backups
by Tom "Mad Dog" Yergeau 17 Feb '01

17 Feb '01

<< So, by turning ctime checking off you will "only" lose the changed permissions, uid/gid of a file. It's up to the user to decide how comfortable they are with that setup. >> Does this apply to CIFS permissions as well as unix permissions? Or does changing CIFS permissions change the mtime? (btw, for us windoze folks, could someone explain what mtime and ctime are?) Thanks, MD -----Original Message----- From: Stephen Manley [mailto:stephen@netapp.com] Sent: Wednesday, January 31, 2001 11:44 AM To: scl(a)sasha.acc.virginia.edu Cc: toasters(a)mathworks.com Subject: Re: Virus scans on NetApps and backups > 8) Netapp's NDMP dump has an option to ignore ctime. I don't think this > is a good idea because this causes dump to skip files that really > should be dumped. If you rename a file, change its owner/group, > or change its permissions, you probably want that change > reflected in a dump. But these operations only trip ctime, not > mtime. Also, if you read files from a tar or zip archive, the > old mtimes are preserved, so dump may skip these files. Steve -- One quick note. Starting in the 6.0 version of Ontap, incremental dumps will detect when new files are added to a tree and back those up as well -- even if the mtime is set back to an old date. Furthermore, renaming a file actually changes the directory. You have to remove an entry and add an entry. This changes the mtime on the directory (or directories if you move from one dir to another). Thus, dump has always captured the changed names. So, by turning ctime checking off you will "only" lose the changed permissions, uid/gid of a file. It's up to the user to decide how comfortable they are with that setup. Stephen Manley DAM and NDMP Groundhog P.S. As an example of what I mean by the renames, check out the examples below cherryhill:/u/stephen/foobar(22) ls -lm total 8 drwxrwxr-x 2 stephen 4096 Jan 31 08:35 testdir drwxrwxr-x 2 stephen 4096 Jan 31 08:35 testdir2 cherryhill:/u/stephen/foobar(23) ls -lm testdir total 0 -rw-rw-r-- 1 stephen 0 Jan 31 08:35 old_name cherryhill:/u/stephen/foobar(24) mv testdir/old_name testdir2/new_name cherryhill:/u/stephen/foobar(25) ls -lm total 8 drwxrwxr-x 2 stephen 4096 Jan 31 08:37 testdir drwxrwxr-x 2 stephen 4096 Jan 31 08:37 testdir2 cherryhill:/u/stephen/foobar(26) ls -lm testdir2/ total 0 -rw-rw-r-- 1 stephen 0 Jan 31 08:35 new_name As you can see - the file mtime hasn't changed, but the DIRECTORIES' mtimes HAVE changed. Thus, dump will capture the remove from testdir and the add to testdir2 cherryhill:/u/stephen/foobar(27) mv testdir2/new_name testdir2/really_new_name cherryhill:/u/stephen/foobar(28) ls -lm total 8 drwxrwxr-x 2 stephen 4096 Jan 31 08:37 testdir drwxrwxr-x 2 stephen 4096 Jan 31 08:39 testdir2 cherryhill:/u/stephen/foobar(29) ls -lm testdir2/ total 0 -rw-rw-r-- 1 stephen 0 Jan 31 08:35 really_new_name Once again, by renaming the file within the directory, the file's mtime stays unchanged, but the DIRECTORY'S mtime is updated.

1 0

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

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 February 2001