toasters September 2001

toasters@lists.teaparty.net

113 participants
151 discussions

scsi.cmd.checkCondition:error when switching tapes during backup
by Moshe Linzer 10 Sep '01

10 Sep '01

We are running 6.1R1, and we are seeing the following symptoms ever since installing Veritas Netbackup and a new Qualstart AIT tape library. The errors occur when a tape change occurs in the middle of a backup. The 'solution' below seems to say that Veritas is timing out waiting for NDMP to load the new tape. Does anyone know how to increase this timeout in NetBackup? Thanks, Moshe Solution ID: ntapcs1891 Title: NDMP backup error message: Device 0b.4: Sense Data no error - (0x0 - 0x0 0x2) - NetApp filer Problem Environment: NetApp filer F85 F800 series F700 series F600 series Data ONTAP 6.x NDMP backup software ONTAP 5.3 and earlier versions returned a 'SCSI bus reset' then retried the command Problem Description: Error message: [scsi.cmd.checkCondition:error]: Device 0b.4: Check Condition: CDB 0x10: Sense Data no error - (0x0 - 0x0 0x2) Error message: Device 0b.4: Sense Data no error - (0x0 - 0x0 0x2) Fix: 1. Check that a tape is loaded and ready (ONLINE). 2. Check the configuration of the NDMP backup software. If using a robotic tape library, then make sure that the backup software is configured correctly to work with the library. This symptom can also be seen when a dump or restore spans multiple tapes, and the NDMP software times out waiting for the tape change. Legato's default timeout is 30 seconds, and Veritas' default is zero seconds. In this case, the fix is to increase the timeout in the NDMP software. Last updated: JUL 2001 Cause of this problem: An application or process accessing the tape device has made an attempt to write file marks past the end of tape. NDMP backup software is not configured correctly to work with the tape device or library. ©Copyright 1996-2000 Primus Knowledge Solutions, Inc. All Rights Reserved. -- ----------------------------------------------------------------------------- Moshe Linzer | On the Internet, IT Manager | National Semiconductor, Israel | nobody knows you're a moron. Phone: 972-9-970-2247 | Fax: 972-9-970-2001 | - Network Magazine Email: moshel(a)nsc.com | -----------------------------------------------------------------------------

1 0

sysstat giving bogus results if >2GB read in interval
by Chris Thompson 09 Sep '01

09 Sep '01

The NOW database suggests that bug 2689 ("sysstat output is inaccurate if displayed at a long interval") is fixed in recent versions of ONTAP, e.g. 6.1.1. I don't think so. See the start of the disk scrub tonight on an F740... ["sysstat -u 60" is running] CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 1% 21 14 84 35 87 0 0 >60 100% 2% T 1% 1% 7 8 11 38 88 0 0 >60 100% 2% T 2% Sun Sep 9 01:00:00 BST [kern.uptime.filer:info]: 1:00am up 43 days, 6:54 194462270 NFS ops, 0 CIFS ops, 0 HTTP ops 16% 17 57 126 10546 141 0 0 >60 100% 3% T 18% 54% 40 572 520 1887065754 824 0 0 >60 100% 11% 5 62% 49% 13 44 56 3537004865 135 0 0 >60 99% 5% T 57% 51% 30 40 233 547830010 129 0 0 >60 99% 5% T 59% The unreasonable reported disk read rates are apparently due to more than 2^31 bytes being read during the recording interval. "sysstat -u 45" gets the numbers back in range: CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 50% 9 15 65 37010 91 0 0 >60 100% 4% T 59% 51% 18 87 100 37068 188 0 0 >60 100% 4% T 59% 50% 5 10 9 37586 78 0 0 >60 100% 3% T 59% 51% 28 218 247 36076 327 0 0 >60 100% 5% T 58% 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: Jumbo Frames on a Toaster
by lkaptan＠pro-link.net 08 Sep '01

08 Sep '01

My company is a reseller of NetApp.I will deploy an F740 (6.1R1) for SAP , Lotus environment at a customer. Firstly I did the demo there and connected an RS6000 to the filer directly via gigabit interface. For better performance I wanted to enable jumbo frames and enabled it as manuals described and the customer did the configuration on the IBM side. But it did not work. because of the performance over gigabit(1500) and the functionality of the filer (snaprestore indeed) they decided to buy the filer. I will install it to their live environment where the servers will be connected to the filer via cisco gigabit switch. If anybody enabled jumbo frames in such environment the configuration of IBM will be very helpful. I dont think the problem is the Filer. thanks Original Message: ----------------- From: John Coke jcoke(a)ibeam.com Date: Fri, 7 Sep 2001 12:30:55 -0700 To: Toasters(a)mathworks.com Subject: Jumbo Frames on a Toaster I am about to deploy a 740 as the content store for a www server farm and also as storage for a farm of windows media encoders. The idea popped into my head that jumbo frames on a gig link might be what I need to help keep the load on the filer down. Does anyone have any experiences with jumbo frames on a toaster or just jumbo frames in general (a little OT I know)? Thank you. John Coke PGP fingerprint: A8D1 4CBD 88CF 1B37 8008 2F79 3081 2108 8F45 E846 PGP key ID 0x8F45E846 (pgp.mit.edu) -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

1 0

multi volume dump fails
by Daniel Oxenhandler 07 Sep '01

07 Sep '01

Toasters, We are backing up an F-740, running ONTAP 5.3.6R2, with dump commands executed from a Solaris host using rsh. There is a Sun L9 stacker (DLT8000) directly attached to the filer. Recently, one of the qtrees exceeded the capacity of one tape. We are attempting to do a multi tape backup using the following syntax: rsh filer dump 0ubf 63 urst0a,urst0a /vol/vol0/home but the backup still fails at around 50GB when the first tape fills up: DUMP: Thu Sep 6 15:35:15 2001 : We have written 51991386 KB to tape. DUMP: Thu Sep 6 15:40:15 2001 : We have written 54129100 KB to tape. DUMP: Dumping tape file 2 on urst0a DUMP: Thu Sep 6 15:45:34 2001 : We have written 54896885 KB to tape. DUMP: Tape file 2 begins with blocks from inode 5777316 DUMP: Tape write failed. DUMP: DUMP IS ABORTED DUMP: Deleting "/vol/vol0/../snapshot_for_backup.381" snapshot. Any ideas? Daniel Oxenhandler Senior Network Engineer Sprint Laboratories 650-375-4281

2 1

Jumbo Frames on a Toaster
by John Coke 07 Sep '01

07 Sep '01

I am about to deploy a 740 as the content store for a www server farm and also as storage for a farm of windows media encoders. The idea popped into my head that jumbo frames on a gig link might be what I need to help keep the load on the filer down. Does anyone have any experiences with jumbo frames on a toaster or just jumbo frames in general (a little OT I know)? Thank you. John Coke PGP fingerprint: A8D1 4CBD 88CF 1B37 8008 2F79 3081 2108 8F45 E846 PGP key ID 0x8F45E846 (pgp.mit.edu)

1 0

RE: Upgrade to 6.1R1
by Mohler, Jeff 07 Sep '01

07 Sep '01

*nods* The confusion is my fault. I was testing on a system that was -once- 6.1.1 but was reverted by someone in the Lab this AM that I didnt catch. NOW is correct. -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, September 07, 2001 11:16 AM To: jeff.mohler(a)netapp.com Cc: mcope(a)isisph.com; toasters(a)mathworks.com Subject: Re: Upgrade to 6.1R1 jeff.mohler(a)netapp.com (Jeff Mohler) writes: > > These are normal messages that are usually supressed by ONTAP. > Its the software querying the FCAL & SCSI loops for devices at bootup. > > 6.1.1 did not supress these messages as all previous versions have, and > all later versions will. The messages are harmless and "normal" although > you usually will not see them. Ummm... some confusion about ONTAP release numbers here? The bug database at NOW seems to indicate that bug 41100 was present in 6.1 and 6.1R1 but fixed in 6.1.1. 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: Upgrade to 6.1R1
by Mohler, Jeff 07 Sep '01

07 Sep '01

These are normal messages that are usually supressed by ONTAP. Its the software querying the FCAL & SCSI loops for devices at bootup. 6.1.1 did not supress these messages as all previous versions have, and all later versions will. The messages are harmless and "normal" although you usually will not see them. Please see http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs2266&resource= for additional background information. -----Original Message----- From: mcope(a)isisph.com [mailto:mcope@isisph.com] Sent: Friday, September 07, 2001 7:05 AM To: owner-toasters(a)mathworks.com Cc: toasters(a)mathworks.com Subject: Re: Upgrade to 6.1R1 I have 4 filers running DOT 6.1R1 and they all say this on boot-up. I want to say it has something to do with putting anything in NVRAM to disk and possibly to perform check for any disk problems. I've accepted it as a normal part of the boot process. Michael Cope UNIX/Linux Systems Administrator ISIS Pharmaceuticals mcope(a)isisph.com UNIX is very user friendly... it's just highly selective about who it makes friends WITH! On 9/7/2001 12:38:28 AM, "Uros Lampret" <uros.lampret(a)ourspace.si>@mathworks.com wrote: > After upgrade to DOT 6.1R1 I've got a warning that I don't understand. > After every reboot filer displays: > > Starting Press CTRL-C for special boot menu > ...................................................................... > .......... > ................................ > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.10(0xfffffc00012d73a0, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.11(0xfffffc00012d7600, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.12(0xfffffc00012d7860, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.13(0xfffffc00012d7ac0, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.14(0xfffffc00012d7d20, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.15(0xfffffc00012d7f80, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > > NetApp Release 6.1R1: Fri Apr 20 03:08:22 PDT 2001 > Copyright (c) 1992-2001 Network Appliance, Inc. > Starting boot on Fri Sep 7 05:52:34 GMT 2001 > > Somebody eles saw this? > > Uros > - att1.htm

2 1

CIFS performancs problems: small files and WinNT
by mcope＠isisph.com 07 Sep '01

07 Sep '01

My company recently migrated about 500GB of files from our NetWare server onto a Filer. We're experiencing a performance problem with opening, copying, or moving multiple (more than 2) small files between the Filer and our users on NT Workstation. Each file has a latency of almost a full second to get processed (open, copy, move). This happens for files between 1K up to 1MB. Large files (over 5MB) don't display this latency. We've played with the CIFS options for TCP on the Filer and making registry changes on the NT workstations and still haven't seen a significant reduction in latency. We think we've narrowed the problem down to the TCP/IP stack in NT. A Win2K workstation with a 100Mb NIC experiences zero latency while an NT Server with a Gigabit NIC is painfully slow while working with the exact same small files. Most of my experience is with Unix and NFS connections to Filers but I've been using CIFS to connect my NT workstation to our Filers for a couple of years and never really noticed this. Has anyone else experienced this latency issue with CIFS, NT and small files or have any suggestions on how to resolve it? My network administrator would like to see a Filer fix rather than have to touch 600+ PCs but I'll entertain any suggestions. TIA, Michael Cope UNIX/Linux Systems Administrator ISIS Pharmaceuticals mcope(a)isisph.com UNIX is very user friendly... it's just highly selective about who it makes friends WITH!

1 0

RE: How to know which qualified tape drive I can emulate?
by Cormier, Darleen 07 Sep '01

07 Sep '01

Hi Nick, If I'm understanding your question correctly, you do not need to emulate anything. The DLT7000s have been fully supported since DataONTAP 5.1.1. Regards, Darleen -----Original Message----- From: nick.mayrath(a)webmd.net [mailto:nick.mayrath@webmd.net] Sent: Thursday, September 06, 2001 4:49 PM To: toasters(a)mathworks.com Subject: How to know which qualified tape drive I can emulate? How do I know which qualified tape drive I can emulate? I have a Sun Microsystems L280 Autoloader (6 slots, DLT7000). I'm running Ontap 5.3.6r2 and will be upgrading to 6.1r1 soon. Thanks in advance Nick Mayrath Network Administrator ExpressBill, Inc. 800-453-8439 ext. 216

1 0

Re: Upgrade to 6.1R1
by mcope＠isisph.com 07 Sep '01

07 Sep '01

I have 4 filers running DOT 6.1R1 and they all say this on boot-up. I want to say it has something to do with putting anything in NVRAM to disk and possibly to perform check for any disk problems. I've accepted it as a normal part of the boot process. Michael Cope UNIX/Linux Systems Administrator ISIS Pharmaceuticals mcope(a)isisph.com UNIX is very user friendly... it's just highly selective about who it makes friends WITH! On 9/7/2001 12:38:28 AM, "Uros Lampret" <uros.lampret(a)ourspace.si>@mathworks.com wrote: > After upgrade to DOT 6.1R1 I've got a warning that I don't understand. > After every reboot filer displays: > > Starting Press CTRL-C for special boot menu > ...................................................................... > .......... > ................................ > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.10(0xfffffc00012d73a0, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.11(0xfffffc00012d7600, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.12(0xfffffc00012d7860, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.13(0xfffffc00012d7ac0, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.14(0xfffffc00012d7d20, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > Thu Jan 1 00:00:00 GMT [isp_timeout:warning]: > 0b.15(0xfffffc00012d7f80, 0x12): > command timeout, quiescing bus to allow outstanding I/O to complete. > > NetApp Release 6.1R1: Fri Apr 20 03:08:22 PDT 2001 > Copyright (c) 1992-2001 Network Appliance, Inc. > Starting boot on Fri Sep 7 05:52:34 GMT 2001 > > Somebody eles saw this? > > Uros > - att1.htm

1 0

← Newer
1
...
8
9
10
11
12
13
14
15
16
Older →

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