Again in the position where my source aggregate is 32 bit and destination is 64 bit and this prevents vfiler online migration.
Last year this was a priv set diag command
aggr 64bit-upgrade start aggr1 -mode grow-all
http://www.gossamer-threads.com/lists/netapp/toasters/11820
In test mode, this completed the 64 bit upgrade quickly and without error.
Anyone done this in production? (Ontap 8.1)
thanks
I did it on a NearStore running 8.1. It worked fine. I didn't really keep track of how long it took since it did it in the background.
Jeff
On Tue, Mar 19, 2013 at 9:50 PM, Fletcher Cocquyt fcocquyt@stanford.edu wrote:
Again in the position where my source aggregate is 32 bit and destination is 64 bit and this prevents vfiler online migration.
Last year this was a priv set diag command
aggr 64bit-upgrade start aggr1 -mode grow-all
http://www.gossamer-threads.com/lists/netapp/toasters/11820
In test mode, this completed the 64 bit upgrade quickly and without error.
Anyone done this in production? (Ontap 8.1)
thanks
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
thanks Jeff,
The -mode check just completed - took 45 minutes - sysstat -x 1 did not show any increase
Upgrading a volume to 64-bit consumes additional free space in the volume. The following table shows the space usage after each volume is upgraded to 64-bit:
Volume Name Total Used Available Capacity ----------- ----- ---- --------- -------- vol0 300GB 73GB 226GB 24% fcappdata 1536GB 688GB 847GB 44% backup 20GB 4210MB 15GB 20% backup1 3660GB 1941GB 1719GB 53% backup2 60GB 45GB 14GB 75% appdata 2252GB 1986GB 266GB 88% irtdev 70GB 56GB 13GB 80% vm65 3481GB 3193GB 288GB 91% devapp1 30GB 2112MB 27GB 6%
I might grow the vm65 volume before attempting the grow-all
thanks
On Mar 19, 2013, at 9:13 PM, Jeff Cleverley jeff.cleverley@avagotech.com wrote:
I did it on a NearStore running 8.1. It worked fine. I didn't really keep track of how long it took since it did it in the background.
Jeff
On Tue, Mar 19, 2013 at 9:50 PM, Fletcher Cocquyt fcocquyt@stanford.edu wrote:
Again in the position where my source aggregate is 32 bit and destination is 64 bit and this prevents vfiler online migration.
Last year this was a priv set diag command
aggr 64bit-upgrade start aggr1 -mode grow-all
http://www.gossamer-threads.com/lists/netapp/toasters/11820
In test mode, this completed the 64 bit upgrade quickly and without error.
Anyone done this in production? (Ontap 8.1)
thanks
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
I don't think you'll have any space issues with 288 gig free. Obviously adding more won't hurt and you can pull it back out when you are done. I seem to recall having some volumes with less free space when I did mine. They were all thin provisioned so I don't know if that makes any difference or not.
Jeff
On Tue, Mar 19, 2013 at 10:20 PM, Fletcher Cocquyt fcocquyt@stanford.edu wrote:
thanks Jeff,
The -mode check just completed - took 45 minutes - sysstat -x 1 did not show any increase
Upgrading a volume to 64-bit consumes additional free space in the volume. The following table shows the space usage after each volume is upgraded to 64-bit:
Volume Name Total Used Available Capacity
vol0 300GB 73GB 226GB 24% fcappdata 1536GB 688GB 847GB 44% backup 20GB 4210MB 15GB 20% backup1 3660GB 1941GB 1719GB 53% backup2 60GB 45GB 14GB 75% appdata 2252GB 1986GB 266GB 88% irtdev 70GB 56GB 13GB 80% vm65 3481GB 3193GB 288GB 91% devapp1 30GB 2112MB 27GB 6%
I might grow the vm65 volume before attempting the grow-all
thanks
On Mar 19, 2013, at 9:13 PM, Jeff Cleverley jeff.cleverley@avagotech.com wrote:
I did it on a NearStore running 8.1. It worked fine. I didn't really keep track of how long it took since it did it in the background.
Jeff
On Tue, Mar 19, 2013 at 9:50 PM, Fletcher Cocquyt fcocquyt@stanford.edu wrote:
Again in the position where my source aggregate is 32 bit and destination is 64 bit and this prevents vfiler online migration.
Last year this was a priv set diag command
aggr 64bit-upgrade start aggr1 -mode grow-all
http://www.gossamer-threads.com/lists/netapp/toasters/11820
In test mode, this completed the 64 bit upgrade quickly and without error.
Anyone done this in production? (Ontap 8.1)
thanks
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Hi,
Been reading this list for a while but not posted. I thought it maybe useful to highlight a bug relating to 32-64bit aggregate upgrades:
611922 - 64-bit volume format upgrade may cause a disruption during allocation and deletion.
The bug isn't fixed until 8.1P3 or 8.1.1. I saw this where disks were added taking the aggregate over 16TB and triggering the 32-64 bit conversion. It panicked one controller, failed over to the other controller and then panicked that controller leaving one of the volumes in the aggregate inconsistent.
Regards Martin
-- View this message in context: http://network-appliance-toasters.10978.n7.nabble.com/Upgrading-32-64-bit-ag... Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.
Martin - that is one of the worst bugs I've ever read - "silent data corruption" - yikes
Will have to look at a 8.1.2 upgrade or find some other way
thanks
On Mar 20, 2013, at 2:14 AM, Martin martin@leggatt.me.uk wrote:
Hi,
Been reading this list for a while but not posted. I thought it maybe useful to highlight a bug relating to 32-64bit aggregate upgrades:
611922 - 64-bit volume format upgrade may cause a disruption during allocation and deletion.
The bug isn't fixed until 8.1P3 or 8.1.1. I saw this where disks were added taking the aggregate over 16TB and triggering the 32-64 bit conversion. It panicked one controller, failed over to the other controller and then panicked that controller leaving one of the volumes in the aggregate inconsistent.
Regards Martin
-- View this message in context: http://network-appliance-toasters.10978.n7.nabble.com/Upgrading-32-64-bit-ag... Sent from the Network Appliance - Toasters mailing list archive at Nabble.com. _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
If you want to grow vm65 because of performance concerns (91% full), you need not worry unless your aggregate is also 'really' full, i.e. not just thick provisioned...
Sebastian
On 20.03.2013 05:20, Fletcher Cocquyt wrote:
thanks Jeff,
The -mode check just completed - took 45 minutes - sysstat -x 1 did not show any increase
Upgrading a volume to 64-bit consumes additional free space in the volume. The following table shows the space usage after each volume is upgraded to 64-bit:
Volume Name Total Used Available Capacity
vol0 300GB 73GB 226GB 24% fcappdata 1536GB 688GB 847GB 44% backup 20GB 4210MB 15GB 20% backup1 3660GB 1941GB 1719GB 53% backup2 60GB 45GB 14GB 75% appdata 2252GB 1986GB 266GB 88% irtdev 70GB 56GB 13GB 80% vm65 3481GB 3193GB 288GB 91% devapp1 30GB 2112MB 27GB 6%
I might grow the vm65 volume before attempting the grow-all
thanks
On Mar 19, 2013, at 9:13 PM, Jeff Cleverley <jeff.cleverley@avagotech.com mailto:jeff.cleverley@avagotech.com> wrote:
I did it on a NearStore running 8.1. It worked fine. I didn't really keep track of how long it took since it did it in the background.
Jeff
On Tue, Mar 19, 2013 at 9:50 PM, Fletcher Cocquyt <fcocquyt@stanford.edu mailto:fcocquyt@stanford.edu> wrote:
Again in the position where my source aggregate is 32 bit and destination is 64 bit and this prevents vfiler online migration.
Last year this was a priv set diag command
aggr 64bit-upgrade start aggr1 -mode grow-all
http://www.gossamer-threads.com/lists/netapp/toasters/11820
In test mode, this completed the 64 bit upgrade quickly and without error.
Anyone done this in production? (Ontap 8.1)
thanks
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Has anyone experienced false positives for filer, and/or protocol being down? I have been getting these errors and I have upgraded to 5.1.. I was getting the errors prior to 5.1 upgrade as well..
This is an example of the alert.
A Warning event at 20 Mar 13:00 Pacific Daylight Time on Active/Active Controller filer1.root.filer...: Host NFS service is down. NFS service is down on host filer1.root.filer (10195).
This one gets my ticker going.... :)
A Critical event at 20 Mar 12:30 Pacific Daylight Time on Active/Active Controller filer3.root.filer: The Active/Active Controller is down.
I have this happen intermittently and it's not filer specific. Nothing in the messages file; all good.. No autosupport that goes out, so wondering if it's worth opening up a month log case with Netapp..
All flavors of DOT are 8.1x and DFM is monitoring about 5 HA pairs.
Thanks
Yah, having them too regulary - but now that I read your mail, I just recognized that I haven't had them for a while now although I haven't changed anything in my environment...
Bye,
Alexander Griesser System-Administrator
ANEXIA Internetdienstleistungs GmbH
Telefon: +43-463-208501-320 Telefax: +43-463-208501-500
E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.at
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Klise, Steve Gesendet: Mittwoch, 20. März 2013 21:38 An: toasters@teaparty.net Lists Betreff: DFM/oncommand alerting
Has anyone experienced false positives for filer, and/or protocol being down? I have been getting these errors and I have upgraded to 5.1.. I was getting the errors prior to 5.1 upgrade as well..
This is an example of the alert.
A Warning event at 20 Mar 13:00 Pacific Daylight Time on Active/Active Controller filer1.root.filer...: Host NFS service is down. NFS service is down on host filer1.root.filer (10195).
This one gets my ticker going.... :)
A Critical event at 20 Mar 12:30 Pacific Daylight Time on Active/Active Controller filer3.root.filer: The Active/Active Controller is down.
I have this happen intermittently and it's not filer specific. Nothing in the messages file; all good.. No autosupport that goes out, so wondering if it's worth opening up a month log case with Netapp..
All flavors of DOT are 8.1x and DFM is monitoring about 5 HA pairs.
Thanks
False positives on filer/protocol being down are not uncommon in DFM.
If you go to your DFM server and kick off an infinite ping, do you get any lost ping packets? Especially around the time the service down errors start?
These errors occur when the DFM server cannot contact the filer via SNMP or ping, so there could be some network flakiness going on.
Also useful would be a packet trace during one of the "filer down" messages. That will show if the packets are making it back to the DFM server. But that can be hard to catch in-flight.
I'd start there - if you don't see anything readily apparent, you should open up a case and give them the data mentioned, as well as a dfmdc. That will at least get the ball rolling...
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Klise, Steve Sent: Wednesday, March 20, 2013 4:38 PM To: toasters@teaparty.net Lists Subject: DFM/oncommand alerting
Has anyone experienced false positives for filer, and/or protocol being down? I have been getting these errors and I have upgraded to 5.1.. I was getting the errors prior to 5.1 upgrade as well..
This is an example of the alert.
A Warning event at 20 Mar 13:00 Pacific Daylight Time on Active/Active Controller filer1.root.filer...: Host NFS service is down. NFS service is down on host filer1.root.filer (10195).
This one gets my ticker going.... :)
A Critical event at 20 Mar 12:30 Pacific Daylight Time on Active/Active Controller filer3.root.filer: The Active/Active Controller is down.
I have this happen intermittently and it's not filer specific. Nothing in the messages file; all good.. No autosupport that goes out, so wondering if it's worth opening up a month log case with Netapp..
All flavors of DOT are 8.1x and DFM is monitoring about 5 HA pairs.
Thanks
we have Balance, akorri and I don't really see anything out of the norm, or excessive.. I will open a case and if I find something of value, report back..
Thanks Justin.
From: Justin.Parisi@netapp.com To: klises@sutterhealth.org; toasters@teaparty.net Subject: RE: DFM/oncommand alerting Date: Wed, 20 Mar 2013 20:52:43 +0000
False positives on filer/protocol being down are not uncommon in DFM.
If you go to your DFM server and kick off an infinite ping, do you get any lost ping packets? Especially around the time the service down errors start?
These errors occur when the DFM server cannot contact the filer via SNMP or ping, so there could be some network flakiness going on.
Also useful would be a packet trace during one of the “filer down” messages. That will show if the packets are making it back to the DFM server. But that can be hard to catch in-flight.
I’d start there – if you don’t see anything readily apparent, you should open up a case and give them the data mentioned, as well as a dfmdc. That will at least get the ball rolling…
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Klise, Steve Sent: Wednesday, March 20, 2013 4:38 PM To: toasters@teaparty.net Lists Subject: DFM/oncommand alerting
Has anyone experienced false positives for filer, and/or protocol being down? I have been getting these errors and I have upgraded to 5.1.. I was getting the errors prior to 5.1 upgrade as well..
This is an example of the alert.
A Warning event at 20 Mar 13:00 Pacific Daylight Time on Active/Active Controller filer1.root.filer…: Host NFS service is down. NFS service is down on host filer1.root.filer (10195).
This one gets my ticker going…. J
A Critical event at 20 Mar 12:30 Pacific Daylight Time on Active/Active Controller filer3.root.filer: The Active/Active Controller is down.
I have this happen intermittently and it’s not filer specific. Nothing in the messages file; all good.. No autosupport that goes out, so wondering if it’s worth opening up a month log case with Netapp..
All flavors of DOT are 8.1x and DFM is monitoring about 5 HA pairs.
Thanks
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Alexander Griesser -
Fletcher Cocquyt -
Jeff Cleverley -
Klise, Steve -
Martin -
Parisi, Justin -
Sebastian Goetze -
steve klise