toasters

toasters@lists.teaparty.net

13531 discussions

Ontap Performance, 5 vs 6
by David Schairer 08 Feb '01

08 Feb '01

Gentles, Does anyone have a strong feeling of performance improvement from Ontap 5 (latest) to Ontap 6? We're so conservative on upgrading Ontap that we make Orrin Hatch blush, so we've so far only put Ontap 6 on some newly built boxes (an 840 and a 760), and our in-production 760s and 840s remain running Ontap 5 for the time being. I've noticed considerably lower CPU loads for our Ontap 6 840s vs our Ontap 5 840s, running basically the same mix of traffic. Here's Ontap NetApp Release 6.0.1R1: Tue Dec 12 00:47:55 PST 2000 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 74% 3233 0 0 2027 11555 2757 0 0 0 10 26% 3000 0 0 1803 11035 2342 6799 0 0 10 17% 3101 0 0 1456 12189 2452 0 0 0 10 21% 2912 0 0 1356 10535 1639 4121 0 0 10 16% 3174 0 0 1394 12795 1321 0 0 0 10 22% 3585 0 0 1370 8783 1910 3497 0 0 10 20% 3715 0 0 2662 12548 1288 0 0 0 10 19% 3308 0 0 2527 10930 1270 0 0 0 10 21% 2810 0 0 1083 6527 1950 5810 0 0 10 15% 2572 0 0 2060 7238 1022 0 0 0 10 20% 2870 0 0 1298 6752 2038 4061 0 0 10 14% 2574 0 0 1467 7172 1145 0 0 0 11 25% 3090 0 0 2658 10669 3763 4245 0 0 11 21% 3578 0 0 2825 10741 2437 0 0 0 11 26% 2908 0 0 2678 7955 2462 6448 0 0 10 18% 3065 0 0 2453 9017 889 0 0 0 11 Avg 23.4%, 3093 ops/sec Here's similar traffic for NetApp Release 5.3.6H1: Wed Aug 9 00:23:38 PDT 2000 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 28% 2488 0 0 2472 2711 2172 1620 0 0 15 27% 2704 0 0 1337 5290 3895 0 0 0 15 35% 2581 0 0 1370 4852 5829 5544 0 0 15 31% 3071 0 0 1759 6377 4670 0 0 0 15 38% 3022 0 0 1522 4599 5330 4600 0 0 15 30% 3064 0 0 1875 4401 3005 0 0 0 15 24% 2598 0 0 1175 3102 2148 0 0 0 15 34% 2698 0 0 1508 2284 3664 5015 0 0 15 26% 2759 0 0 1883 2531 1324 0 0 0 15 33% 2554 0 0 1500 2798 4093 4958 0 0 15 24% 2618 0 0 1742 2557 1231 0 0 0 15 30% 2503 0 0 1043 2538 3376 2337 0 0 15 27% 2684 0 0 1559 2760 2228 2577 0 0 15 22% 2408 0 0 1180 2828 1830 0 0 0 15 31% 2523 0 0 1257 2663 3332 4098 0 0 15 25% 2724 0 0 1442 3015 1699 0 0 0 15 avg 29.1%, 3687 ops/sec (Those are 'sysstat 10's) Has anyone else observed similar performance improvements? I expect to have better data when we upgrade an existing heavily-trafficed box from 5 to 6 so there's a true apples-to-apples comparison... --DRS

1 0

remove
by Chris Shallcross 07 Feb '01

07 Feb '01

please remove me

1 0

filestats command
by neil lehrer 07 Feb '01

07 Feb '01

hi, i am running 5.36.r2 on an f760. i wanted to try out the filestats command. here is what i did and what i got: filer> filestats sizes 500K,2M,50M volume vol0 snapshot nightly.1 VOL=vol0 SNAPSHOT=nightly.1 INODES=7723392 COUNTED_INODES=1232941 TOTAL_BYTES=59730144144 TOTAL_KB=51473000 FILE SIZE CUMULATIVE COUNT CUMULATIVE TOTAL KB 500K 1226580 20385888 2M 1230705 24260056 50M 1232894 36493488 MAX 1232941 51473000 AGE(ATIME) CUMULATIVE COUNT CUMULATIVE TOTAL KB 0 3535 77304 30D 93619 8580784 60D 135397 10546160 90D 180611 13984140 120D 228856 19349796 MAX 1232941 51473000 UID COUNT TOTAL KB #0 1172 5319016 #1640 1788 5059896 #1058 248546 2835992 #1218 390 2245924 #354 2129 1755596 #256 3269 1596104 #670 2638 1165100 #470 967 820724 #691 4780 789172 #850 2149 753660 #1265 156 681036 #243 4340 669708 #246 3412 639188 #501 21937 573244 #987 3340 508704 #509 2290 455516 #372 12326 410172 #245 3421 410088 #305 1690 403728 #1597 16762 355136 #980 1348 353960 #1482 186 341536 ... GID data ... according to the SAG i should have got just: VOL=vol0 SNAPSHOT=nightly.1 INODES=7723392 COUNTED_INODES=1232941 TOTAL_BYTES=59730144144 TOTAL_KB=51473000 FILE SIZE CUMULATIVE COUNT CUMULATIVE TOTAL KB 500K 1226580 20385888 2M 1230705 24260056 50M 1232894 36493488 MAX 1232941 51473000 AGE(ATIME) CUMULATIVE COUNT CUMULATIVE TOTAL KB 0 3535 77304 30D 93619 8580784 60D 135397 10546160 90D 180611 13984140 120D 228856 19349796 MAX 1232941 51473000 no matter what i do i get the uid and gid data. also, when it does that it takes about 10 minutes and the cpu util goes to about 90%. is the command wrong or the sag? should it take that long? is the util excessive? and what do TOTAL_BYTES and TOTAL_KB mean? thanks

1 0

RE: CIFS problem....
by Knight, Graham 07 Feb '01

07 Feb '01

If you set the option: wafl.nt_admin_priv_map_to_root to "off" you will no longer be creating files as root. If you do this, but you still want all powers over the filer from NT you will have to put your username into the BUILTIN\Administrators group in the filers local user database. That is one way to solve the problem that I know of, there may be others. Graham -----Original Message----- From: Talvinder (Ricky) Chawla To: 'toasters(a)mathworks.com' Sent: 2/7/01 5:38 AM Subject: CIFS problem.... Does anyone know why if you are a domain admin and you write a file via cifs, the file gets saved as owner root. Is there a way to fix this ??? Ricky Chawla Laurel Networks, Inc. http://www.laurelnetworks.com

3 2

RE: CIFS problem....
by Muhlestein, Mark 07 Feb '01

07 Feb '01

This is described in the security FAQ on NOW: http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/faq. shtml#anchor1392387 "Why is the UNIX owner of files I create set to "root"? For CIFS clients that happens in two cases: 1. The mapped user actually is root. 2. The mapped user is mapped by the 'wafl.default_unix_user' option. Since all users mapped that way use the same UNIX identity, they should not be allowed to have owner privileges from UNIX on files created by other default-mapped users. The filer makes the UNIX owner 'root' to enforce this. If individual control is desired separate UNIX users should be created." As explained by others, in case "1" above your CIFS user may be mapped to root because of an entry in usermap.cfg, or it may be because of the wafl.nt_admin_priv_map_to_root option. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Talvinder (Ricky) Chawla [mailto:ricky@laurelnetworks.com] Sent: Wednesday, February 07, 2001 2:38 PM To: 'toasters(a)mathworks.com' Subject: CIFS problem.... Does anyone know why if you are a domain admin and you write a file via cifs, the file gets saved as owner root. Is there a way to fix this ??? Ricky Chawla Laurel Networks, Inc. http://www.laurelnetworks.com

1 0

RE: CIFS problem....
by Krause, Oliver 07 Feb '01

07 Feb '01

Try turn off options wafl.nt_admin_map_to_root Oliver > -----Original Message----- > From: Talvinder (Ricky) Chawla [mailto:ricky@laurelnetworks.com] > Sent: Mittwoch, 7. Februar 2001 14:38 > To: 'toasters(a)mathworks.com' > Subject: CIFS problem.... > > > Does anyone know why if you are a domain admin and you write > a file via > cifs, the file gets saved as owner root. Is there a way to > fix this ??? > > Ricky Chawla > Laurel Networks, Inc. > > http://www.laurelnetworks.com >

1 0

RE: CIFS problem....
by Traitel, Eyal 07 Feb '01

07 Feb '01

Check settings in your /etc/usermap.cfg on the filer. This file handles mapping between PC and Unix usernames. You probably find there a line like: Administrator == root Eyal. ---------------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! ---------------------------------------------------------------------- Eyal Traitel - Filer Escalation Engineer CNA, MCSE, CSA, NACA Network Appliance BV Holland Office Center Kruisweg 799b 2132 NG, Hoofddorp The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Email: eyal(a)netapp.com ---------------------------------------------------------------------- Get answers NOW! - NetApp On the Web - http://now.netapp.com ---------------------------------------------------------------------- -----Original Message----- From: Talvinder (Ricky) Chawla [mailto:ricky@laurelnetworks.com] Sent: Wednesday, February 07, 2001 2:38 PM To: 'toasters(a)mathworks.com' Subject: CIFS problem.... Does anyone know why if you are a domain admin and you write a file via cifs, the file gets saved as owner root. Is there a way to fix this ??? Ricky Chawla Laurel Networks, Inc. http://www.laurelnetworks.com

1 0

CIFS problem....
by Talvinder (Ricky) Chawla 07 Feb '01

07 Feb '01

Does anyone know why if you are a domain admin and you write a file via cifs, the file gets saved as owner root. Is there a way to fix this ??? Ricky Chawla Laurel Networks, Inc. http://www.laurelnetworks.com

1 0

MRTG tweaks
by Thomas.L.White＠chase.com 06 Feb '01

06 Feb '01

Has anyone written a tweak to MRTG that collects information re: Disk I/O ? One other thing I am looking to track is snapmirror success (actually failure). thanks in advance tw

1 0

RE: SnapMirror 5.3.6R2 -> 6.0.1R1
by Thomas.L.White＠chase.com 06 Feb '01

06 Feb '01

The only real trouble I have noticed since upgrading to 6.0.1R1 has been the disk_fw_update on replacement drives sent from NetApps. They still quiesce the bus when you introduce drives with older/newer firmware revision numbers. Other than that, I don't mind that my snapmirror updates take minutes instead of hours. It was very helpful to be able to create a new mirror without having to reboot the filer. Command line interrogation is much friendlier and the new http GUI rocks over the older versions. sory - I did not intend to get on my soapbox. tw "Peter Tran" <ptran(a)broadcom.com> on 02/05/2001 04:44:22 PM Please respond to ptran(a)broadcom.com To: Tuc <tuc(a)ttsg.com>, Thomas L. White/CHASE@CHASE cc: taob(a)risc.org, toasters(a)mathworks.com Subject: RE: SnapMirror 5.3.6R2 -> 6.0.1R1 If you don't mind sharing with the group the types of problems other than snapmirror that you're seeing after the upgrade from 5.3.x to 6.0.1R1. I'm planning to perform the migration from 5.3.x to 6.0.1R1 and would be interested to know the problems you're having with 6.0.1R1. Thanks. Peter -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Tuc Sent: Monday, February 05, 2001 1:01 PM To: Thomas.L.White(a)chase.com Cc: taob(a)risc.org; toasters(a)mathworks.com Subject: Re: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > in the upgrade to 6.0.1R1 > it mentions that all snapshots have to be blown away before > allowing snapmirror to run again. > But this (as far as I know) refers ro upgrade source as well as destination > Ihave not seen any comments re: Upgrading one side only. > ERRR?? Where did you see this? We just upgraded 2 5.3.4RWHATEVER to 6.0.1R1 on Feb 1, and we were told that you had to do both in a snapmirror because of the version issues Brian found. We are having alot of problems with the filers and the systems since the upgrade, but are trying to work it out. No one told us about deleting the previous snapshots.... Thanks, Tuc/TTSG Internet Services, Inc. > tw > > > > > Brian Tao <taob(a)risc.org>@mathworks.com on 02/05/2001 12:45:37 PM > > > > Sent by: owner-toasters(a)mathworks.com > > > To: toasters(a)mathworks.com > cc: > Subject: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > Couldn't find any reference to this error message on NOW: > > Sun Feb 4 23:47:00 EST [drp-na1: worker_thread:error]: snapmirror: > Filesystem version mismatch for destination volume nocna1_vol0, reverting > the version and aborting transfer. SnapMirror will retry until this revert > is complete. > > That appears on a destination F840 running 6.0.1R1. Volume > /vol/nocna1_vol0 on the F840 is large enough and is marked offline. > "snapmirror status" shows: > > Source Dest Status > 192.168.50.17:vol0 drp-na1:nocna1_vol0 Idle > > Filer 192.168.50.17 is an F740 running 5.3.6R2. It prints this to > syslog: > > Sun Feb 4 23:29:18 EST [worker_thread]: snapmirror: Destination drp-na1 > could not accept a complete transfer > Sun Feb 4 23:49:18 EST last message repeated 20 times > > What is this about filesystem versions? Is the F840 doing > something about it on /vol/nocna1_vol0? How can I check on the > progress of this revert operation? > > I guess I should be asking: are 5.3.x and 6.0.x snapmirrors > compatible? The 6.0 Data Protection Guide doesn't mention caveats or > incompatibilities. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" > > > > >

1 0

FW: SnapMirror 5.3.6R2 -> 6.0.1R1
by Joe Luchtenberg 06 Feb '01

06 Feb '01

Interesting substitution for "definitely." ;-) Joe Joe Luchtenberg Dataline, Inc. New number and email, please update: 757.858.0600 858.0606 fax joe.luchtenberg(a)data-line.com > -----Original Message----- > From: Heller, Jeffrey [SMTP:Jeffrey.Heller@netapp.com] > Sent: Monday, February 05, 2001 10:25 PM > To: 'Premanshu Jain'; 'ptran(a)broadcom.com'; Tuc; > Thomas.L.White(a)chase.com > Cc: taob(a)risc.org; toasters(a)mathworks.com > Subject: RE: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > ...but it most > > defiantly works. > > > > Jeff Heller

2 1

RE: SnapMirror 5.3.6R2 -> 6.0.1R1
by Heller, Jeffrey 06 Feb '01

06 Feb '01

> > Please note, once migrated to 6.0, you can't go back to 5.3.X, without > zeroeing the disks. This is a false statement. revert_to was better tested with 6.0 and 6.0.1 then at any time in the past. It is slower then we would like, but it most defiantly works. Jeff Heller

1 0

RE: SnapMirror 5.3.6R2 -> 6.0.1R1
by Premanshu Jain 06 Feb '01

06 Feb '01

Please note, once migrated to 6.0, you can't go back to 5.3.X, without zeroeing the disks. THere are some known bugs, which prevent the filer coming up with 6.0. I tried doing the upgrade to a 740 cluster, running 5.3.4R2 and it was OK with one, but failed with other one showing disk error. But when I booted the same filer with 5.3.7 floopies, it worked just fine...Here is the bug info.. ____________ Regarding this issue. A bug has has been filed Bug 35522 titled "upgrade to 6.0R2 from 5.3.7 caused complaints of disk 7.28 has rgdn 0 but disk type 0." _____________ Advice : Stay on 5.3.7R2, let 6.x ONTAP settle first.. You don't know how many more new errors you may encounter.. thanks, prem Premanshu Jain Nortel Networks, Content Networks(Shasta) 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 -----Original Message----- From: Peter Tran [mailto:ptran@broadcom.com] Sent: Monday, February 05, 2001 1:44 PM To: Tuc; Thomas.L.White(a)chase.com Cc: taob(a)risc.org; toasters(a)mathworks.com Subject: RE: SnapMirror 5.3.6R2 -> 6.0.1R1 If you don't mind sharing with the group the types of problems other than snapmirror that you're seeing after the upgrade from 5.3.x to 6.0.1R1. I'm planning to perform the migration from 5.3.x to 6.0.1R1 and would be interested to know the problems you're having with 6.0.1R1. Thanks. Peter -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Tuc Sent: Monday, February 05, 2001 1:01 PM To: Thomas.L.White(a)chase.com Cc: taob(a)risc.org; toasters(a)mathworks.com Subject: Re: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > in the upgrade to 6.0.1R1 > it mentions that all snapshots have to be blown away before > allowing snapmirror to run again. > But this (as far as I know) refers ro upgrade source as well as destination > Ihave not seen any comments re: Upgrading one side only. > ERRR?? Where did you see this? We just upgraded 2 5.3.4RWHATEVER to 6.0.1R1 on Feb 1, and we were told that you had to do both in a snapmirror because of the version issues Brian found. We are having alot of problems with the filers and the systems since the upgrade, but are trying to work it out. No one told us about deleting the previous snapshots.... Thanks, Tuc/TTSG Internet Services, Inc. > tw > > > > > Brian Tao <taob(a)risc.org>@mathworks.com on 02/05/2001 12:45:37 PM > > > > Sent by: owner-toasters(a)mathworks.com > > > To: toasters(a)mathworks.com > cc: > Subject: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > Couldn't find any reference to this error message on NOW: > > Sun Feb 4 23:47:00 EST [drp-na1: worker_thread:error]: snapmirror: > Filesystem version mismatch for destination volume nocna1_vol0, reverting > the version and aborting transfer. SnapMirror will retry until this revert > is complete. > > That appears on a destination F840 running 6.0.1R1. Volume > /vol/nocna1_vol0 on the F840 is large enough and is marked offline. > "snapmirror status" shows: > > Source Dest Status > 192.168.50.17:vol0 drp-na1:nocna1_vol0 Idle > > Filer 192.168.50.17 is an F740 running 5.3.6R2. It prints this to > syslog: > > Sun Feb 4 23:29:18 EST [worker_thread]: snapmirror: Destination drp-na1 > could not accept a complete transfer > Sun Feb 4 23:49:18 EST last message repeated 20 times > > What is this about filesystem versions? Is the F840 doing > something about it on /vol/nocna1_vol0? How can I check on the > progress of this revert operation? > > I guess I should be asking: are 5.3.x and 6.0.x snapmirrors > compatible? The 6.0 Data Protection Guide doesn't mention caveats or > incompatibilities. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" > > > > >

2 1

RE: atime/mtime/ctime and backups (was: re: Virus scans on NetApp s and backups)
by Mike Sphar 06 Feb '01

06 Feb '01

That could be a good solution. I know for me, my problem is not having a good way to identify old files that aren't being used by anyone. I'd love to use the atime, but our backup software, not to mention the virus scanners, updates that. Our filers are just filling up with so much junk I don't know what to do. All I can do right now is ask people to delete stuff, but we all know how ineffective that is. And if I ever point to a given file or directory and say "do we need that?" the answer is inevitably "I don't know what that is, so we better keep it." Feh. And management always questions me when I say that they should expect filer space usage to pretty much double every year. Statements like "There's no way we could possibly need 2 Terabytes by next year" are currently ringing in my ears. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services - Remedy Corporation BOFH, GWP, MCP, MCP+I, MCSE, BFD "We all agree that your theory is crazy, but is it crazy enough?" - Niels Bohr "Every normal man must be tempted at times to spit upon his hands and hoist the black flag." - H.L. Mencken (paraphrased) The only "right" way to do this is not to update atime in the first place. Some operating systems provide a method, possibly privileged, of allowing files to be read without atime being updated. As Steve says, NetApp filers currently only have an all-or-nothing switch for this. But maybe a more selective option (no-atime-update-if-host=virus.scan -and-user=detox?) is what people who want to do transparent content scans should be asking for. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

SnapMirror 5.3.6R2 -> 6.0.1R1
by Brian Tao 06 Feb '01

06 Feb '01

Couldn't find any reference to this error message on NOW: Sun Feb 4 23:47:00 EST [drp-na1: worker_thread:error]: snapmirror: Filesystem version mismatch for destination volume nocna1_vol0, reverting the version and aborting transfer. SnapMirror will retry until this revert is complete. That appears on a destination F840 running 6.0.1R1. Volume /vol/nocna1_vol0 on the F840 is large enough and is marked offline. "snapmirror status" shows: Source Dest Status 192.168.50.17:vol0 drp-na1:nocna1_vol0 Idle Filer 192.168.50.17 is an F740 running 5.3.6R2. It prints this to syslog: Sun Feb 4 23:29:18 EST [worker_thread]: snapmirror: Destination drp-na1 could not accept a complete transfer Sun Feb 4 23:49:18 EST last message repeated 20 times What is this about filesystem versions? Is the F840 doing something about it on /vol/nocna1_vol0? How can I check on the progress of this revert operation? I guess I should be asking: are 5.3.x and 6.0.x snapmirrors compatible? The 6.0 Data Protection Guide doesn't mention caveats or incompatibilities. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 1

atime/mtime/ctime and backups (was: re: Virus scans on NetApps and backups)
by Chris Thompson 05 Feb '01

05 Feb '01

There are some issues that weren't brought up in the original thread. Steve Losen <scl(a)sasha.acc.virginia.edu> wrote: > > 6) Under normal circumstances, an incremental dump copies all files > whose mtime or ctime has changed. and others used similar phrases. But, of course, this isn't actually right: there's no record of whether the mtime has *changed*! What incremental dumps do is to include a file if either the mtime or ctime is greater than the recorded time of the reference dump. Now ctime, being updated only by the server operating system, can be expected to only increase monotonically and never to be greater than the current time [assuming a well-behaved system clock, of course]. But mtime can be set arbitrarily by the file's owner, and there is no such guarantee for it. In fact, setting mtime far in the future guarantees that the file will be included in every incremental dump, and could constitute a sort of denial-of-service attack. The tradition of checking mtime as well as ctime goes back a long way in the history of the BSD dump program from which, for example, Solaris ufsdump and NetApp dump are derived (at least conceptually). I've always thought of it as a fudge, designed to cover up for early operating system bugs which failed to update ctime when they should have done. So, in respect of > > 8) Netapp's NDMP dump has an option to ignore ctime. [...] I would ask for an option to ignore mtime instead! (This was described in the context of NDMP, but the mtime+ctime rules described above are used by plain NetApp dump(1) as well.) -- Steve Losen <scl(a)sasha.acc.virginia.edu> accurately described the original problem as follows: > > 2) This trips the atime on the file. The filer does this whether > you like it or not. You can configure a filer to NEVER trip atimes > with: vol options volname no_atime_update=on But if atimes matter > to you, then why would you do this? > > 3) Some folks object to having the atimes of all files tripped > by a virus scanner. > > 4) To solve 3, some virus scanners save the atime before reading > a file and put it back when they are done. Indeed they do, and there are also applications that dump using normal front-door access to the files that (at least optionally) try the same foul trick. It's enough to make any systems programmer turn in their grave, and ask: but, how can you do that? you can't tell whether someone else has updated the atime between your reading it and your trying to put it back! The only "right" way to do this is not to update atime in the first place. Some operating systems provide a method, possibly privileged, of allowing files to be read without atime being updated. As Steve says, NetApp filers currently only have an all-or-nothing switch for this. But maybe a more selective option (no-atime-update-if-host=virus.scan -and-user=detox?) is what people who want to do transparent content scans should be asking for. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

Re: SnapMirror 5.3.6R2 -> 6.0.1R1
by Thomas.L.White＠chase.com 05 Feb '01

05 Feb '01

in the upgrade to 6.0.1R1 it mentions that all snapshots have to be blown away before allowing snapmirror to run again. But this (as far as I know) refers ro upgrade source as well as destination Ihave not seen any comments re: Upgrading one side only. tw Brian Tao <taob(a)risc.org>@mathworks.com on 02/05/2001 12:45:37 PM Sent by: owner-toasters(a)mathworks.com To: toasters(a)mathworks.com cc: Subject: SnapMirror 5.3.6R2 -> 6.0.1R1 Couldn't find any reference to this error message on NOW: Sun Feb 4 23:47:00 EST [drp-na1: worker_thread:error]: snapmirror: Filesystem version mismatch for destination volume nocna1_vol0, reverting the version and aborting transfer. SnapMirror will retry until this revert is complete. That appears on a destination F840 running 6.0.1R1. Volume /vol/nocna1_vol0 on the F840 is large enough and is marked offline. "snapmirror status" shows: Source Dest Status 192.168.50.17:vol0 drp-na1:nocna1_vol0 Idle Filer 192.168.50.17 is an F740 running 5.3.6R2. It prints this to syslog: Sun Feb 4 23:29:18 EST [worker_thread]: snapmirror: Destination drp-na1 could not accept a complete transfer Sun Feb 4 23:49:18 EST last message repeated 20 times What is this about filesystem versions? Is the F840 doing something about it on /vol/nocna1_vol0? How can I check on the progress of this revert operation? I guess I should be asking: are 5.3.x and 6.0.x snapmirrors compatible? The 6.0 Data Protection Guide doesn't mention caveats or incompatibilities. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

4 4

RE: SnapMirror 5.3.6R2 -> 6.0.1R1
by Traitel, Eyal 05 Feb '01

05 Feb '01

Upgrading from 5.3.x to 6.x includes a WAFL upgrade, in which old snapshots needs to be deleted before upgrade is complete. Since this upgrade is working with low-priority threads, the regular user will just have his WAFL upgraded after a few days/weeks, depending on filer's snap sched settings. Hope it helps, Eyal. ---------------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! ---------------------------------------------------------------------- Eyal Traitel - Filer Escalation Engineer CNA, MCSE, CSA, NACA Network Appliance BV Holland Office Center Kruisweg 799b 2132 NG, Hoofddorp The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Email: eyal(a)netapp.com ---------------------------------------------------------------------- Get answers NOW! - NetApp On the Web - http://now.netapp.com ---------------------------------------------------------------------- -----Original Message----- From: Tuc [mailto:tuc@ttsg.com] Sent: Monday, February 05, 2001 10:01 PM To: Thomas.L.White(a)chase.com Cc: taob(a)risc.org; toasters(a)mathworks.com Subject: Re: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > in the upgrade to 6.0.1R1 > it mentions that all snapshots have to be blown away before > allowing snapmirror to run again. > But this (as far as I know) refers ro upgrade source as well as destination > Ihave not seen any comments re: Upgrading one side only. > ERRR?? Where did you see this? We just upgraded 2 5.3.4RWHATEVER to 6.0.1R1 on Feb 1, and we were told that you had to do both in a snapmirror because of the version issues Brian found. We are having alot of problems with the filers and the systems since the upgrade, but are trying to work it out. No one told us about deleting the previous snapshots.... Thanks, Tuc/TTSG Internet Services, Inc. > tw > > > > > Brian Tao <taob(a)risc.org>@mathworks.com on 02/05/2001 12:45:37 PM > > > > Sent by: owner-toasters(a)mathworks.com > > > To: toasters(a)mathworks.com > cc: > Subject: SnapMirror 5.3.6R2 -> 6.0.1R1 > > > Couldn't find any reference to this error message on NOW: > > Sun Feb 4 23:47:00 EST [drp-na1: worker_thread:error]: snapmirror: > Filesystem version mismatch for destination volume nocna1_vol0, reverting > the version and aborting transfer. SnapMirror will retry until this revert > is complete. > > That appears on a destination F840 running 6.0.1R1. Volume > /vol/nocna1_vol0 on the F840 is large enough and is marked offline. > "snapmirror status" shows: > > Source Dest Status > 192.168.50.17:vol0 drp-na1:nocna1_vol0 Idle > > Filer 192.168.50.17 is an F740 running 5.3.6R2. It prints this to > syslog: > > Sun Feb 4 23:29:18 EST [worker_thread]: snapmirror: Destination drp-na1 > could not accept a complete transfer > Sun Feb 4 23:49:18 EST last message repeated 20 times > > What is this about filesystem versions? Is the F840 doing > something about it on /vol/nocna1_vol0? How can I check on the > progress of this revert operation? > > I guess I should be asking: are 5.3.x and 6.0.x snapmirrors > compatible? The 6.0 Data Protection Guide doesn't mention caveats or > incompatibilities. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" > > > > >

1 0

RE: Decoding pktt trace
by Edward Hibbert 02 Feb '01

02 Feb '01

Yes, snoop seems to do the trick. Thanks. Edward. -----Original Message----- From: Muhlestein, Mark [mailto:mark.muhlestein@netapp.com] Sent: Friday, February 02, 2001 5:41 PM To: Edward Hibbert; Labelle, Steven Cc: 'toasters(a)mathworks.com' Subject: RE: Decoding pktt trace If you mean NLM == NFS Lock Manager, then "snoop" on Sun boxes should work better. You can use "editcap" from the Ethereal package to convert to snoop format first. Editcap also works for converting to NetMon, and a bunch of other formats. Mark -----Original Message----- From: Labelle, Steven [mailto:Steven.Labelle@netapp.com] Sent: Friday, February 02, 2001 10:24 AM To: 'Edward Hibbert'; toasters(a)mathworks.com Subject: !RE: Decoding pktt trace Edward, My preferred method is to convert the pktt trace to the Windows NT Server Network Monitor (Netmon) format using the capconv.exe program available on the Network Appliance NOW site download page. Then I use Netmon to look at the trace in whatever way I please. Steve -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Friday, February 02, 2001 9:09 AM To: toasters(a)mathworks.com Subject: Decoding pktt trace I have occasion to look very hard at some pktt trace. I'm using Ethereal to do this, but it doesn't decode inside NLM packets to make them nice and readable for me. Do any of you folk know anything which would? Regards, Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh <mailto:eh@dataconnection.com> @dataconnection.com Web: http://www.dat <http://www.dat> aconnection.com

2 1

RE: Decoding pktt trace
by Muhlestein, Mark 02 Feb '01

02 Feb '01

If you mean NLM == NFS Lock Manager, then "snoop" on Sun boxes should work better. You can use "editcap" from the Ethereal package to convert to snoop format first. Editcap also works for converting to NetMon, and a bunch of other formats. Mark -----Original Message----- From: Labelle, Steven [mailto:Steven.Labelle@netapp.com] Sent: Friday, February 02, 2001 10:24 AM To: 'Edward Hibbert'; toasters(a)mathworks.com Subject: !RE: Decoding pktt trace Edward, My preferred method is to convert the pktt trace to the Windows NT Server Network Monitor (Netmon) format using the capconv.exe program available on the Network Appliance NOW site download page. Then I use Netmon to look at the trace in whatever way I please. Steve -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Friday, February 02, 2001 9:09 AM To: toasters(a)mathworks.com Subject: Decoding pktt trace I have occasion to look very hard at some pktt trace. I'm using Ethereal to do this, but it doesn't decode inside NLM packets to make them nice and readable for me. Do any of you folk know anything which would? Regards, Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh <mailto:eh@dataconnection.com> @dataconnection.com Web: http://www.dat <http://www.dat> aconnection.com

1 0

!RE: Decoding pktt trace
by Labelle, Steven 02 Feb '01

02 Feb '01

Edward, My preferred method is to convert the pktt trace to the Windows NT Server Network Monitor (Netmon) format using the capconv.exe program available on the Network Appliance NOW site download page. Then I use Netmon to look at the trace in whatever way I please. Steve -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Friday, February 02, 2001 9:09 AM To: toasters(a)mathworks.com Subject: Decoding pktt trace I have occasion to look very hard at some pktt trace. I'm using Ethereal to do this, but it doesn't decode inside NLM packets to make them nice and readable for me. Do any of you folk know anything which would? Regards, Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh <mailto:eh@dataconnection.com> @dataconnection.com Web: http://www.dat <http://www.dat> aconnection.com

1 0

Decoding pktt trace
by Edward Hibbert 02 Feb '01

02 Feb '01

I have occasion to look very hard at some pktt trace. I'm using Ethereal to do this, but it doesn't decode inside NLM packets to make them nice and readable for me. Do any of you folk know anything which would? Regards, Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh <mailto:eh@dataconnection.com> @dataconnection.com Web: http://www.dat <http://www.dat> aconnection.com

1 0

RE: MRTG and Filer Watch for Win32 Perl
by Mohler, Jeff 02 Feb '01

02 Feb '01

Ive run MRTG under windows..yes. -----Original Message----- From: Carruthers, Paul A [mailto:Paul_Carruthers@AIMFUNDS.COM] Sent: Friday, February 02, 2001 5:16 AM To: toasters(a)mathworks.com Subject: MRTG and Filer Watch for Win32 Perl Has anyone out there succeeded in running the MRTG (filer-mrtg) and Disk Space Advisor (filer_watch_df) under Perl for Win32?? Cheers...Paul.

1 0

RE: MRTG and Filer Watch for Win32 Perl
by Knight, Graham 02 Feb '01

02 Feb '01

I have a filer-mrtg package that will run on windows. I'll send you the zip file in a separate e-mail. If anyone else wants it drop me a line. It is not officially supported by netapp, but if you have questions I will answer them to the best of my ability. :-) Graham -----Original Message----- From: Carruthers, Paul A [mailto:Paul_Carruthers@AIMFUNDS.COM] Sent: Friday, February 02, 2001 6:16 AM To: toasters(a)mathworks.com Subject: MRTG and Filer Watch for Win32 Perl Has anyone out there succeeded in running the MRTG (filer-mrtg) and Disk Space Advisor (filer_watch_df) under Perl for Win32?? Cheers...Paul.

1 0

MRTG and Filer Watch for Win32 Perl
by Carruthers, Paul A 02 Feb '01

02 Feb '01

Has anyone out there succeeded in running the MRTG (filer-mrtg) and Disk Space Advisor (filer_watch_df) under Perl for Win32?? Cheers...Paul.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters