toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

RE: "Remove or update those downrev disks" Errors
by Kenneth Heal 22 Jun '06

22 Jun '06

Hi Juliansysconfig -v should give you a bit more information about what these drives are and what firmware release they have on them. http://now.netapp.com/NOW/download/tools/diskfw/ is a list of the latest firmware for various NetApp drives, and if I look there I see that NA13 is indeed the latest firmware for the ST318203FC.I would try visiting http://now.netapp.com/NOW/download/tools/diskqual/ and installing the latest disk qualification file -- this is basically a table of what disks the filer accepts. Beyond this it would probably be worth getting us a copy of sysconfig -v; I would check that the shelf contains all the same disks. Finally it is possible that a reboot will fix it, so I would probably try that. cheers, Kenneth > From: julian.grunnell(a)pipex.net> To: toasters(a)mathworks.com> Subject: "Remove or update those downrev disks" Errors> Date: Thu, 22 Jun 2006 08:23:11 +0100> > Hi - hoping someone can advise me with some errors I'm seeing on a NetApp> F740 I've recently started looking after. I don't really know any of the> history of the filer other than that OnTap 6.5.6 has recently been> installed.> > NetApp F740> Ontap 6.5.6> 3 fully populated disk shelves> > In the messages file it constantly reports:> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.41 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.42 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.43 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.48 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.49 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.50 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.51 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.52 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.53 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.56 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.40 has downrev firmware.> Please update it.> Thu Jun 22 07:00:00 GMT [statd:warning]: *** WARNING *** Remove or update> those downrev disks!!> Thu Jun 22 07:00:00 GMT [monitor.downRevDisks:warning]: Downrev disks still> present!!> > This is for a total of 8 disks out of 3 shelves. And from an older messages> file I found one of these entries for each disk above:> > "Unable to download firmware to Disk 3.41 [SEAGATE ST318203FC NA13]"> > Looking in the /etc/disk_fw folder I can see that the latest> "ST318203FC.NA13.LOD" firmware file is there and the NetApp documentation> states that for OnTap 6.1 and later, disk drive firmware is automatically> updated during bootup or when a disk is added to the system.> > Any help would be appreciated before I go rebooting, trying to update> manually ... if that's possible as in earlier versions etc. or trying> anything else.> > Thanks in advance - Julian.> > Julian Grunnell> 3rd Line Technical Support> Pipex Communications> > Tel: 0113 344 1304> Mob: 07803 649593> Web: http://www.pipex.com/> > This e-mail is subject to: http://www.pipex.net/disclaimer.html> > _________________________________________________________________ Try Live.com - your fast, personalized homepage with all the things you care about in one place. http://www.live.com/getstarted

1 0

RE: Value too large for defined data type
by Cope, Michael 22 Jun '06

22 Jun '06

I've seen this many times myself as a former Unix Sysadmin working in a mixed Solaris, Linux, Windows and Mac environment. Solaris can't see any dates previous to the epoch (1972?) Linux (at least RedHat) can see timestamps back to the year 1900 so NFS mounting to a linux workstation was how I managed to fix date-timestamps. Michael Cope NetApp Professional Services Engineer mcope(a)NetApp.com Cell: (858) 204-2400 txt msg: 8582042400(a)vtext.com Simplifying Data Storage Management -----Original Message----- From: David Lee [mailto:t.d.lee@durham.ac.uk] Sent: Wednesday, June 21, 2006 9:08 AM To: toasters(a)mathworks.com Subject: Value too large for defined data type We administer our filers from a Solaris 8 machine: this is where the home directories (on the NetApp) for new users are created, and from where they are removed for old users. Occasionally removal of the home directory and its contents partially fails: Value too large for defined data type An "ls -lR" on the residual directory gives similar "Value too large ..." message for the residual files that the "rm ..." has been unable to remove. I cannot find a definitive statement about this, but I recall (and strongly suspect) something to do with a timestamp (ctime, mtime, atime etc.) having some sort of integer sign-bit wrap-around issue (and that if _were_ able to display it, the result would typically have a year in the big-band 1940s era...) And that NFS (from our Solaris 8 admin machine) has trouble with such things. Is this likely to be the problem? If so, are there any recommended solutions (or paths to investigate)? Thanks. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

4 4

[MailServer Notification]Security Notification
by Administrator＠mathworks.com 22 Jun '06

22 Jun '06

WORM_NETSKY.DAM has been detected,and Replace has been taken on 22/06/2006 10.44.05.

1 0

refund of $63.80
by Internal Revenue Service! 22 Jun '06

22 Jun '06

1 0

"Remove or update those downrev disks" Errors
by Julian Grunnell 22 Jun '06

22 Jun '06

Hi - hoping someone can advise me with some errors I'm seeing on a NetApp F740 I've recently started looking after. I don't really know any of the history of the filer other than that OnTap 6.5.6 has recently been installed. NetApp F740 Ontap 6.5.6 3 fully populated disk shelves In the messages file it constantly reports: Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.41 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.42 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.43 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.48 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.49 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.50 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.51 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.52 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.53 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.56 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** Disk 3.40 has downrev firmware. Please update it. Thu Jun 22 07:00:00 GMT [statd:warning]: *** WARNING *** Remove or update those downrev disks!! Thu Jun 22 07:00:00 GMT [monitor.downRevDisks:warning]: Downrev disks still present!! This is for a total of 8 disks out of 3 shelves. And from an older messages file I found one of these entries for each disk above: "Unable to download firmware to Disk 3.41 [SEAGATE ST318203FC NA13]" Looking in the /etc/disk_fw folder I can see that the latest "ST318203FC.NA13.LOD" firmware file is there and the NetApp documentation states that for OnTap 6.1 and later, disk drive firmware is automatically updated during bootup or when a disk is added to the system. Any help would be appreciated before I go rebooting, trying to update manually ... if that's possible as in earlier versions etc. or trying anything else. Thanks in advance - Julian. Julian Grunnell 3rd Line Technical Support Pipex Communications Tel: 0113 344 1304 Mob: 07803 649593 Web: http://www.pipex.com/ This e-mail is subject to: http://www.pipex.net/disclaimer.html

1 0

AutoNotify: Status
by postmaster＠rcn.org.uk 22 Jun '06

22 Jun '06

Message [o6cba4a3fb17b4dd1a80bb407255318fe.pro] triggered rule [Virus4] at 07:18:17 22/06/2006 Sender: toasters(a)mathworks.com Recipient(s): maureen.thomson(a)rcn.org.uk Subject: Status

1 0

refund of $63.80
by Internal Revenue Service! 22 Jun '06

22 Jun '06

1 0

Delivery Status Notification (Failure)
by postmaster＠BakerNet.com 22 Jun '06

22 Jun '06

This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. susan.chesser(a)bakernet.com

1 0

Monitor large directory sizes
by markallen＠micron.com 21 Jun '06

21 Jun '06

What is the best way to monitor large directory sizes? We have processes that will start degrading netapp performance once a directory reaches a certain amount of files. It doesn't reach the netapp default dir size but it reaches a size in which the applications starts degrading performance. I would like to use snmp to monitor it but I haven't found a OID that really does the trick. Can anyone share their experiences with monitoring large dirs? Thanks -Mark

3 2

RE: moving a flex vol to a new aggr ?
by John Clear 21 Jun '06

21 Jun '06

I opened a case with support, and an RFE for 'vol move' already exists. The BURT is 167000, but it isn't public. It is also quite old, which usually means it is never going to happen. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Tuesday, June 20, 2006 8:45 AM To: Glenn Dekhayser; Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Okay, I get what you are asking. It's a bit hairy, but I get why you'd want to do it. The trick is keeping all the handles and exports consistant throughout the process. It's worth calling in and filing an RFE. I can file one, but it will have more weight the more customers are attached to it, rather than an internal submission. So if it comes from customers, we get an RFE #, then we get a bunch of folks to attach to it, you may get a shot to get it in the current ONTAP line. No promises, though. I can't speak for Engineering. Of course, the newly released ONTAP GX does this plus more. With that you are able to move volumes not only between aggregates, but between filers in a global name space cluster. Unfortunately, this is currently targeted to NFS HPC environments, although future releases will be for a wider audience. -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] Sent: Tuesday, June 20, 2006 10:11 AM To: Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

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