toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

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

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