toasters

toasters@lists.teaparty.net

13513 discussions

Recovered error messages no longer logged in 5.1.2R3
by Greg Kitch 18 Feb '99

18 Feb '99

We recently upgraded our operating system version on an F220, F330 and F540 to 5.1.2R3. After a few days we noticed that we had stopped receiving recovered error messages on our SCSI disks. Following is an example of one such message: Sun Jan 17 02:19:16 PST [isp_main]: Disk 4a.4(0x4e55d0): READ sector 6200854 recovered error (1 17, 1) We sent a request to support inquiring about the status of these error messages and have been told that beginning with 5.1.2R3 they are no longer being logged. It is the case that the occasional and infrequent occurrence of these messages on a very active filer is not an indication of a problem, it is also our understanding that if these messages start increasing (1 an hour or 10-20 per day) on a specific disk for different blocks, then you should be paying very close attention to that disk and we would notify support. This seems to have been the case with several disk failures that we have experienced on our filers. An RFE (12820) has been filed at our request to supply a toggle for these messages to enable the customer to selectively include or exclude them from the messages file. We believe messages of this nature can be very helpful although one must understand their significance (or insignificance) when they occur. We have read some of the discussion concerning these messages on toasters but are not aware of anyone else that has noticed their disappearance and would like to see them made available again. Have I missed them? Does anyone else have an interest in having the flexibility of including soft error messages in the log files or is there a general consensus that they are unnecessary. We're trying to get support from other users for making the toggle available. One step further, we would like to see a list of all such error messages potentially logged by the system and what they mean. We have seen such lists on other systems and think that they could be helpful for the filers as well. Thanks. Greg Kitch UCLA SEASnet Computing Facility 2567 Boelter Hall Los Angeles, CA 90095 ----- End Included Message -----

1 0

Re: Poor small file CIFS performance in 5.2.1
by sirbruce＠ix.netcom.com 18 Feb '99

18 Feb '99

On 02/18/99 09:29:26 you wrote: > >Hi All, > >Any other CIFS users seeing very poor CIFS performance when accessing large >numbers of small files? > >The specific problem is with across network backups using ARCServe. We were >seeing 70MB/min to a DLT3 drive when running OnTap 5.1D3, but upgrding to >5.2.1 has dropped that back to 20MB/min. > >When I backup large files (256MB core files for example) I'm seeing backup >throughput of ~130MB/min which is pushing the DLT drive close to its limit >(150MB/min with 2:1 compression). > >In general the performance for large files is better in 5.2.1, but Netapp >seem to have broken the small file throughput. By large numbers of small files, do you mean a bunch of small files in one directory? If so, are you sure this collection of small files actually existed when you did the backup before on the previous OS version? I guess what I'm getting at is the possible explanation that nothing broke between 5.1D3 and 5.2.1. Obviously, if something did, you'll have to wait to hear back from Netapp. It's also possible there was a fix in your D3 patch that did not make it into 5.2.1. People running patched versions to address a particular problem should always check to see if the patch made it into a subsequent release. Bruce

1 0

Poor small file CIFS performance in 5.2.1
by Garrett Burke 18 Feb '99

18 Feb '99

Hi All, Any other CIFS users seeing very poor CIFS performance when accessing large numbers of small files? The specific problem is with across network backups using ARCServe. We were seeing 70MB/min to a DLT3 drive when running OnTap 5.1D3, but upgrding to 5.2.1 has dropped that back to 20MB/min. When I backup large files (256MB core files for example) I'm seeing backup throughput of ~130MB/min which is pushing the DLT drive close to its limit (150MB/min with 2:1 compression). In general the performance for large files is better in 5.2.1, but Netapp seem to have broken the small file throughput. I've been through the usual tests: check duplex, swap network cables, even moved both backup host and the filer to another switch. Given the throughput on large files, I can't see it being a network problem. Neither the switch nor the filer interface are showing large number of errors. Backup performance from other NT servers hasn't dropped off. We backup from a snapshot. The small files (source files mainly, we're a SW house) are in quota trees using mixed security. There's quite a complex ACL system in place and some files may have 6-8 NT groups as part of the ACL. cifs.oplocks.enable is on and cifs.lvl2_oplocks_cap is off, which hasn't changed since the upgrade. I have a support call open with Netapp (Log ID: 52724.00000) and have provided them with a 60s network trace of the traffic between the filer and backup host when the backup throughput has gone way down and there's not much other filer usage, but they have yet to get back to me. Can anyone think of anything I should check for? Thanks, GB

1 0

Re: Sharing files between NT and Unix
by Mark Muhlestein 17 Feb '99

17 Feb '99

Actually it depends on the application. If the Windows application has the file open exclusively, then you won't be able access it from NFS. But if it is open in a mode that allows readers, it will work. And some applications open a file, copy it to a temporary file, close the original file, operate on the copy, then rename it to the original name when you do a save. And byte range locking also comes into play with some applications. All these types of lock are supported in a multi-protocol manner on the filer. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Tom Limoncelli <tal(a)research.bell-labs.com> To: Schepers, Jan <Jan.Schepers(a)nl.origin-it.com> Cc: 'toasters(a)mathworks.com' <toasters(a)mathworks.com> Date: Tuesday, February 16, 1999 7:32 PM Subject: Re: Sharing files between NT and Unix >"Schepers, Jan" wrote: >> "NetApps Filers can't share files between NT and Unix *simultaneously*." > >I do it every day! > >It should be noted that the exact same file can't be opened at the exact >same time (ie. you can't "cat" a file in unix at the exact moment >MS-Word is reading the file). This is because MS-Word locks the file! >So, if you find a product that WILl "cat" the file while MS-Word is >using it, it sounds like they aren't implementing any locking! Ouch! > >--tal >

1 0

cont: Sharing files between NT and Unix
by Schepers, Jan 17 Feb '99

17 Feb '99

>Hello People, > >This was my question to you: >Apparently I have never understood the concept of an netapp filer, >but this is what an HP guy is trying to tell me: >"NetApps Filers can't share files between NT and Unix *simultaneously*." > >What could he have meant ? Thanks to all the numerous people that gave their reaction. I realized that dropping the question amongst equal tuned people would result in responses that line with my observations. Ergo, the place the get the answer is of course the HP sales-rep. I'll let you know when it comes to something beautiful :-) MNY THKS, Jan >

1 0

Sharing files between NT and Unix
by Schepers, Jan 17 Feb '99

17 Feb '99

Hello People, Apparently I have never understood the concept of an netapp filer, but this is what an HP guy is trying to tell me: "NetApps Filers can't share files between NT and Unix *simultaneously*." What could he have meant ? cheers, Jan

5 4

Question on 5.x
by Jaye Mathisen 17 Feb '99

17 Feb '99

I'm still running 4.3.4, going to upgrade to 5.x shortly. One question: On the volumes that can be created, can I set up some to have snapshots, and some that don't? Or is it only system-wide?

2 1

Re: Netapp nfs over tcp
by Gordon Keegan 16 Feb '99

16 Feb '99

> On Fri, 12 Feb 1999, Gordon Keegan wrote: > > > > > Speaking of NFS over TCP, we'd also like to try turning nfs.tcp.enable > > on to do some testing. Does anyone know if this would affect current > > mounts if we just enable it at the filer command line with > > "options nfs.tcp.enable on", or can that be done? > > Your clients aren't currently mounting with tcp, you'll have to have > them umount the server and then remount after you've enabled it on > the server. So it is kind of a chore. > I probably didn't phrase the question as well as I should have. If I enable NFS over TCP, then mount a single host using TCP and do testing, will that stomp on the dozens of other clients that still have their UDP mounts? (there; hopefully that was better :) -- Gordon Keegan, M10-10 Phone: (508) 261-4696 Motorola ISG Fax: (508) 261-5757 20 Cabot Boulevard Mansfield, MA 02048 email: lgk011(a)dma.isg.mot.com

6 5

Re: Sharing files between NT and Unix
by mds＠gbnet.net 16 Feb '99

16 Feb '99

On Tue 16 Feb, 1999, "Schepers, Jan" <Jan.Schepers(a)nl.origin-it.com> wrote: > Hello People, > > > Apparently I have never understood the concept of an netapp filer, > but this is what an HP guy is trying to tell me: > "NetApps Filers can't share files between NT and Unix *simultaneously*." Well as the above statment is totally, provably incorrect... > > What could he have meant ? ...he evidently meant 'I will lie outrageously to try to boost my company's chances of a sale'. So many companies' sales-forces resort to this that I find myself proposing a cull of salespeople - in the Canadian-baby-seal style, to preserve the viability of the rest of the species. > > cheers, You're most welcome. > > Jan > >-- End of excerpt from "Schepers, Jan"

1 0

Re: Netapp nfs over tcp
by Daniel Quinlan 16 Feb '99

16 Feb '99

Actually, I have one question: is there any reason we wouldn't want to start using NFSv3/UDP for Solaris boxes on our switched LAN? - Dan

2 1

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