toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

SnapManager
by Loux, Linda 02 Jan '01

02 Jan '01

I am upgrading the server hardware for my Exchange server. My current Exchange server is running NT 4.0, and the databases are on local raid disks. My new hardware will be running Windows 2000, and the databases will be on my filer. I am having trouble trying to accomplish this, since the Migrator assumes the server is not changing. My new server will not have enough local disk space to put the Information Store on it first and then do the migration. Does anyone have the correct procedures for doing this operation? Linda Loux Systems Administrator Rosetta Inpharmatics ********************************************************************** This email message is the property of Rosetta Inpharmatics and contains confidential information that may also be privileged. If you are not the intended recipient, any use, disclosure, copying, or communication of the contents of this message is prohibited. If this message was received in error, please forward a copy to mail_admin(a)rii.com and delete the message and any attachments from your computer. Thank you. **********************************************************************

1 0

NFS server timeouts on the clients
by arr＠oceanwave.com 02 Jan '01

02 Jan '01

I have an brand new F720 running 5.3.6R2. We're exporting two qtrees via NFS and CIFS. When the system is almost completely quiet, I try to tar up about 2M of stuff and it takes FIVE minutes. I also see NFS timeout errors on all NFS clients (the one I'm doing the tar from is specifically solaris 8, but I see the timeouts on linux as well). I've tried NFS v2 and v3, both TCP and UDP, and nothing seems to help. netstat doesn't seem to show packet collisions (the netowrk ispretty much dead), not a lot of errors (<10%). I'm seeing writes about every 10 seconds (which should mean good performance), and the CPU is mostly idle. Why the hell does a tar of 2M take so bloody long? I can understand if I was moving a gig or so, but 2M?! I've included important info (this was after I had changed to v2 UDP). Is there something else I should look at? >nfsstat -c Server rpc: TCP: calls badcalls nullrecv badlen xdrcall 0 0 0 0 0 UDP: calls badcalls nullrecv badlen xdrcall 1354 0 0 0 0 Server nfs: calls badcalls 1306 0 Server nfs V2: (1306 calls) null getattr setattr root lookup readlink read 1 0% 372 28% 2 0% 0 0% 194 15% 0 0% 293 22% wrcache write create remove rename link symlink 0 0% 440 34% 2 0% 1 0% 0 0% 0 0% 0 0% mkdir rmdir readdir statfs 0 0% 0 0% 1 0% 0 0% Server nfs V3: (0 calls) null getattr setattr lookup access readlink read 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% write create mkdir symlink mknod remove rmdir 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% rename link readdir readdir+ fsstat fsinfo pathconf 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% commit 0 0% NFS V2 non-blocking request statistics: null getattr setattr root lookup readlink read 1 100% 372 100% 2 100% 0 0% 194 100% 0 0% 141 48% wrcache write create remove rename link symlink 0 0% 440 100% 1 50% 1 100% 0 0% 0 0% 0 0% mkdir rmdir readdir statfs 0 0% 0 0% 1 100% 0 0% NFS V3 non-blocking request statistics: null getattr setattr lookup access readlink read 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% write create mkdir symlink mknod remove rmdir 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% rename link readdir readdir+ fsstat fsinfo pathconf 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% NFS reply cache statistics: TCP: In progress Delay hits Misses Idempotent Non-idempotent 0 0 0 0 0 UDP: In progress Delay hits Misses Idempotent Non-idempotent 0 5 732 7 42 >sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 2% 0 0 0 0 0 0 0 0 0 19 3% 1 0 0 0 1 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 3% 32 0 0 5 3 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 6% 0 0 0 0 0 48 128 0 0 19 2% 0 0 0 31 0 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 3% 4 0 0 2 1 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 2% 1 0 0 16 0 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 3% 2 0 0 1 1 0 0 0 0 19 5% 0 0 0 0 0 32 152 0 0 19 2% 0 0 0 0 0 0 0 0 0 19 >sysconfig -r Volume vol0 (root) RAID group 0 RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- parity 1.3 1 0 3 FC:A 34500/70656000 35003/71687368 data 1.2 1 0 2 FC:A 34500/70656000 35003/71687368 data 1.0 1 0 0 FC:A 34500/70656000 35003/71687368 data 1.5 1 0 5 FC:A 34500/70656000 35003/71687368 data 1.6 1 0 6 FC:A 34500/70656000 35003/71687368 data 1.1 1 0 1 FC:A 34500/70656000 35003/71687368 Spare disks RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- spare 1.4 1 0 4 FC:A 0 35003/71687368 > netstat -s tcp: 19180 packets sent 16501 data packets (3116859 bytes) 647 data packets (355343 bytes) retransmitted 804 ack-only packets (114 delayed) 0 URG only packets 0 window probe packets 1156 window update packets 76 control packets 22021 packets received 15990 acks (for 3112800 bytes) 187 duplicate acks 0 acks for unsent data 13688 packets (5178316 bytes) received in-sequence 618 completely duplicate packets (890780 bytes) 0 old duplicate packets 10 packets with some dup. data (10 bytes duped) 50 out-of-order packets (61320 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 1 packet received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 13 connection requests 27 connection accepts 3 bad connection attempts 0 listen queue overflows 32 connections established (including accepts) 40 connections closed (including 1 drop) 8 embryonic connections dropped 15825 segments updated rtt (of 16329 attempts) 531 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections timed out in persist 8 keepalive timeouts 0 keepalive probes sent 8 connections dropped by keepalive 3594 correct ACK header predictions 3474 correct data packet header predictions 1758 PCB cache misses 0 segments dropped at untrusted interface 0 connection requests closed at filter udp: 3671023 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 dropped due to no socket 137 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 3670886 delivered 3665023 datagrams output ip: 7921585 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with size larger than maximum 0 with data size < data length 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 packets with spoofed source address 0 packets arrived on wrong port 6499598 fragments received 0 fragments dropped (dup or out of space) 0 malformed fragments dropped 0 overlapping fragments discarded 3966 fragments dropped after timeout 2272723 packets reassembled ok 3693053 packets for this host 790 packets for unknown/unsupported protocol 0 packets forwarded 867 packets not forwardable 0 redirects sent 3685059 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 412593 output datagrams fragmented 862312 fragments created 0 datagrams that can't be fragmented icmp: 0 calls to icmp_error 0 errors not generated 'cuz old message was icmp Output histogram: echo reply: 7 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: echo reply: 2 echo: 7 time exceeded: 790 7 message responses generated > netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis Queue e8* 1500 none none 0 0 0 0 0 0 e0 1500 192.168.1 myhost 7929745 5917 4 0 with incorrect version number 0 packets with spoofed source address 0 packets arrived on wrong port 6499598 fragments received 0 fragments dropped (dup or out of space) 0 malformed fragments dropped 0 overlapping fragments discarded 3966 fragments dropped after timeout 2272723 packets reassembled ok 3693053 packets for this host 790 packets for unknown/unsupported protocol 0 packets forwarded 867 packets not forwardable 0 redirects sent 3685059 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 412593 output datagrams fragmented 862312 fragments created 0 datagrams that can't be fragmented icmp: 0 calls to icmp_error 0 errors not generated 'cuz old message was icmp Output histogram: echo reply: 7 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: echo reply: 2 echo: 7 time exceeded: 790 7 message responses generated

2 3

01-01-2001
by Oldies.Online.Casino＠mathworks.co.uk 02 Jan '01

02 Jan '01

1 0

ESTALE
by Edward Hibbert 31 Dec '00

31 Dec '00

We're using HP machines running HP 11 against a NetApp, using NFS. We are occasionally seeing ESTALE errors on file I/O operations. This may be a problem in the application, but I'd welcome any information any of you have on just what ESTALE means. I've seen it described as occurring when an NFS client uses an invalid file handle, but I've also seen reference to it occurring when machines are rebooted. So, my rather vague question is: what do you all know about ESTALE? Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh(a)dataconnection.com Web: http://www.dataconnection.com

2 1

RE: Relying on automatic load on DLT7000 drive
by Chris Thompson 29 Dec '00

29 Dec '00

Apologies for resurrecting a 2.5-week old thread, but I've realised I ought to wrap up a few things before the [real:-)] millennium... Chang-Ping Hu <chang-ping.hu(a)netapp.com> wrote: 1> 1> There are a few rationales behind the change. 1> 1> 1. To provide a fix to allow proper handling of a cleaning tape by DLT tape 1> libraries (Burt #29835.) 1> 1> 2. In the case of a stand-alone drive, to provide a consistent drive 1> behavior across various tape drive types. AIT and Exabyte drives will 1> physically eject a tape when an unload command is issued. This change will 1> make the DLT drives respond in a similar way, even though it does not 1> physically eject the tape. 1> 1> 3. The change will require a user to manually reload the tape to enable the 1> DLT drive to read it. This prevents accidentally overwriting a tape user 1> may otherwise think has been unloaded. Again, this is no different from the 1> AIT and Exabyte drives. I think I'm convinced by the compatibility (2) and safety (3) arguments that the state before 5.3.7R2 was wrong. 1> In your particular case, to add incremental dumps, an alternative is to use 1> nrst0a instead urst0a. If you don't really care about the previous data 1> on the tape, you can even use rst0a. and also Amol Chitre <Amol.Chitre(a)netapp.com> wrote 2> 2> In the absence of a stacker, why are you using a urst0a? It seems to me that 2> you are overwriting during the incremental dumps. In that case, you can use 2> a rst0a and the tape will not be unloaded. On the other hand, if you dont 2> want to overwrite, you can use nrst0a. In case you want to continue with 2> urst0a, you might have to do a manual unload and reload everytime. I ought to have made this clearer. I use nrst0a exclusively for the dumps themselves, and pack several of them onto a single tape (these are small incremental dumps). There's an outer-level management script that checks labels, writes packing lists, and positions the tape, all via the na_rmt(8) interface [q.v.]. Dumps on successive days do not overwrite each other: they get added on the end of the tape. At the moment, the management script ends up unloading the tape ("I6\n1\n" to na_rmt). Just opening the tape again the next day reloads it if the same tape is still sitting in the drive. This is convenient at times without operator cover. Obviously I can change this to not unload the tape, but that has some disadvantages, including the greater exposure to loss of the filemark directory on a power failure that I mentioned before. I can live with it, though! Solaris' rmt implementation supports some larger-numbered "I" (ioctl) operations beyond 6, including 14 (MTLOAD). A nice solution for me would be to have ONTAP's rmt support this as well: an explicit load request doesn't fall into the overwrite-the-tape-by-accident scenario. However, I suppose that these extensions are highly unstandardised, and it might be asking rather a lot of NetApp to support them. 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: Block checksums and Zoned checksums
by sthaug＠nethelp.no 29 Dec '00

29 Dec '00

> 21 years ago - and boy, does it seem *weird* to write that - my first > programming experience was with a very funky old machine called the PERQ. Yup, I remember the PERQ. Some of them found their way to Norway too :-) > Musing somewhat related to toasters: Like GigE pushing against the limits > of a 1500 byte MTU, isn't it about time we start moving to 1K or larger > block sizes on our SCSI drives? In the age of FibreChannel and Ultra160, > shuffling all those wee blocks about seems silly, given that filesystems > are using 1K, 2K, 4K and larger logical block sizes. You may want to check out the Usenet newsgroup comp.arch, which has a rather interesting discussion about just that. Look for the thread with subject line Re: 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM) Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Block checksums and Zoned checksums
by Chris Thompson 29 Dec '00

29 Dec '00

I've been reading the 6.0.1R1 "Start Here" document (for advance planning: we're not about to move to it) and especially the "New features in 6.0.1" section. I wonder whether someone can explain how "block checksum" disks (and volumes) differ from "zoned checksum" ones, at a slightly more technical level than "block checksum disks are the ones with yellow front bezel ID labels and the orange system requirements labels on the side"? :) 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.

3 3

EMC
by chris＠webtop.com 28 Dec '00

28 Dec '00

Looks like EMC are trawling the mailing list for sales leads. People of a sensitive disposition may want to hide their contact details when posting if they wish to avoid being contacted. -- Chris Good WebTop.com http://www.webtop.com Tel: +44 (0) 1223 715000 Fax: +44 (0) 1223 715001

2 1

cifs and win nt res kit SU cmd
by neil lehrer 27 Dec '00

27 Dec '00

i take it all back, NT SU and cifs on my filers is working correctly. fixed one problem corrected multiple symptoms. -- regards

1 0

RE: snapmirror quarry...
by Berry, Grant 27 Dec '00

27 Dec '00

Hi Brian and all. Snapmirror does xfer the source volume's snapshots over to the target volume, so that space has to be considered as well. In general you need as much or more space available on the snapmirror target. Have a look at section 4. in this white paper, it explains it well: http://www.netapp.com/tech_library/3043.html Another good doc on snapmirror is here: http://now.netapp.com/NOW/knowledge/docs/olio/guides/TR3073.shtml Please keep in mind that these docs are due for updating when it come to performance details when considering snap create and blockmap xfer times and their (huge) improvements in ONTAP 6.x. Regards, Grant -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Saturday, December 23, 2000 1:54 PM To: Lance R. Bailey Cc: 'Traitel Eyal'; toasters Subject: Re: snapmirror quarry... On Fri, 22 Dec 2000, Lance R. Bailey wrote: > > snap mirror is a front to vol copy. think of vol copy as "dd" ie: > block level. Does this include or exclude snap reserve space? Vol copy does not require that you duplicate snapshots of a volume, so I assume SnapMirror is the same? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

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