toasters February 2001

toasters@lists.teaparty.net

88 participants
116 discussions

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

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