We have to plan this years yearly maintenance for this, normaly done during our low-period (summer break, vacation time) and I'm looking at going straight to Ontap 8.1 if it is released.
I wish to upgrade the aggregates to 64bit inplace as we only have about 25% free space left and I'm hoping that Ontap 8.1 would let us do that.
This would give us compression and this release more space instead of investing into more disk (for a while more or until next budget).
Next maintenance period is during christmas/newyears break when we have low pressure on the system, but by then we will probably be forced to invest into more disk before that.
Is there any kind of indication of when Ontap 8.1 is due? At least what quarter 2011 (if at all during this year)?
There's an internal target date, but no public release yet.
I have no indication that 32 to 64 bit aggregate conversion will be a feature.
My clients are waiting on SnapLock Compliance certification.
Don't hold your breath waiting, upgrade to 8.0.1 ...
At your service,
(P.S. I appreciate points for helpful or correct answers.)
I know I am replying to this post late but my SE tells me that it will be the fall. Earlier this year when I worked at Netapp in Engineering all they were working on was 8.1 code. I also hear that 8.1 will include a online 32 to 64bit migration but I can not confirm that just a roomer that I heard.
Data ONTAP 8.1 shall be in RC1 released on 29th of September. The GA is planned for 15/01/2012.
As with regards to the 32 to 64-bit migration. This is indeed a feature which is implemented and shall be integrated.
Also, when you go above the 16Tb limit, an aggregate shall always and automatically be upgraded to 64-bit (if on 8.1 offcourse).
SnapLock Compliance is also included.
Release notes for 8.1 RC1
Support for volume SnapMirror replication between 32-bitand 64-bit volumes
Starting with Data ONTAP 8.1, you can replicate volumes byusing SnapMirror between 32-bit and 64-bit volumes. For both synchronous andasynchronous volume replication, the SnapMirror source and destination volumescan be either 32-bit or 64-bit.
It will be by growing over 16tb.. Not in place.
If I read documentation correctly - it will be when going over 16TB and in place
Who needs 64 bit when not exceeding 16TB anyway? Espicially with possibility to replicate between 32 and 64 bit?
I would love if someone shared real life conversion experience. I have customer waiting for it for months, but they do have production databases close to 25TB in total. It would be lengthy and costly attempt to restore from backup ...
That’s a good point.. there is a way with VSM from 32 to 64 but requires enough disk to do it….but is a way to get the volume migrated without going over 16TB…but would have been nice to have an in place conversion without the brute force. But I am happy to get 32 to 64bit finally which has been a bit of a qsm/ndmpcopy pain.
Are we saying that (according to documentation) the only way to do an in-place migration of a 32-bit aggregate to a 64-bit one, is to increase its size over 16TB?
That's a bit odd. It's hard to believe that doing this 'normal' way (without going over 16TB) is technically any different.
I am expecting / hoping for an undocumented 'migrate_below_16t' command requiring diagnostic mode
Yes, unless i missunderstand something.
I'm a little dissapointed in the number of changes after reading the release notes.
Probably had too high expectations.
Sniplet from the release notes
Data ONTAP 8.1 7-Mode RC1 Release Notes
These Release Notes describe new features, enhancements, and known issues for Data ONTAP 8.1 7-Mode RC1, as well as additional information related to running this release on specific storage systems.
Dont get me wrong regarding being little disappointed.
Most, if not everything, missing from the 8.0.x release seems to be in this release.
Probably the most prominent missing feature missing is the inplace 64bit conversion if you have no free disks, like in my case.
but i'm looking hard at finding anything that would excite me in the 7mode like global filesystem, parallel nfs etc.
Right now it's more like cathing up with the homework instead of being a leader with visions.
OK. Now i did find some news I haven't heard of before.
Ontap 8.1 removes the Dedupe volume size limit and Compression can be done as a post-process (as dedupe today) suddenly making the features even more usefull.
Maximum volume size
For Data ONTAP 8.1, compression and deduplication do not impose a limit on the maximum volume size supported; therefore, the maximum volume limit is determined by the type of storage system regardless of whether deduplication or compression is enabled.
Still its not clear if dedupe is searching for duplicates "volume only" or in the whole aggregate, given that the working set for dedupe is now moved to the aggregate.
RC2 is out . But still not clear on in place upgrade of 32s to 64s. I mean if its growing over 16t which only 64s can do.. what is the design behind it?
Attention in Release Notes.
If you have a 3210 or 3140 storage system with Flash Cache modules installed, do not upgrade your system to Data ONTAP 8.1 7-Mode RC2. These configurations might experience low system memory conditions that can cause a system panic in high stress environments.
The issue is under investigation and a long term strategy will be communicated as soon as possible. See 3210 and 3140 storage systems with Flash Cache modules.
For those wondering why you would want to do a 32 bit to 64 bit conversion even though your aggregate is less than 16TB:
Often folks will snapmirror to a much larger aggregate for disaster recovery purposes. If that aggregate is greater than 16TB, and the source aggregate is less than 16TB, you are snapmirroring from a 32 bit aggregate to a 64 bit one. This in of itself isn't a problem until it comes time to do a disaster recovery test like we did. We quickly found out that after breaking the mirror and bringing a volume back online, the 32 bit volume will realize that it is now on a 64 bit aggregate and promptly do a 64 bit conversion, and then a fingerprint update if it is deduped. This process maxes out the IO and makes the filer useless for at least 24 hours (obviously depending on the size of your volume). Our 4 hour RPO is now out the window, until we figure our how to convert our 32 bit volumes to 64 bit, *IN PLACE*.
Thanks for sharing this - this really proves the point (again) how important the issue is.
I hope someone from NetApp engineering team reads this: it is really hard to believe there are any technical reasons why only 16TB+ aggregates can be migrated on-line from 32-bit to 64-bit.
Can 8.1 GA bring any improvement in this area (please)?
There are some interesting wafl processes in kahuna that can bring a fas to its knees. We saw in one case that when convert_ucode was enable on a volume the system was not usable and no wy to throttle it. The source 3100 and target 6240 had the same result until the process finished or was stopped by reboot and quick command to turn the vol option back off. These are very rare edge case but would be nice to get a throttle on these more denial of service side effects.
Just recived this from our NetApp Tecnical Specialist:
At the moment we've released Data ONTAP 8.1 RC2. Our current expectation is that within the next month RC3 will become available. This RC release will be the GA candidate, which means that assuming that no major issues are found and another RC is not required, and our GA metrics are met, the GA release will occur a couple of months after this release.
Realistically, I'd expect that you can plan for the June timeframe unless something major occurs to change the timeframe.
I sure hope that in RC3 or GA they fix the panic and core dump that has happened 2 times in the last month to 2 of my controllers on RC2. Both times I contacted support they said there was no idea when it would be fixed or what exactly was causing it. I would think that would be serious enough to be fixed before GA. I would tell others to think twice before a upgrade.
My brand new NAS0321 V3270 with DOT 8.0.2 got an heart attack 3 nights ago which no core dump, knock off the RLM. The poor NA level II guy could only suggest to upgrade the firmware to R5 which was just released last month.....
Is DOT 8.02 really stable/reliable? Any issue with the new DOT 8.0.2 R5?
Is purchase filer the right choose?
You're right that we have to 'think twice before a upgrade'
Cheers & Good Sarturday
What configurations are you running to get the filers to fail? I.E. CIFS/NFS/Fibre/iSCSI?
If CIFS I came across this regards long running RPC requests that cause a panic and you have to disable the CIFS timeout.
That CIFS issue went out in a NetApp email bulletin several weeks ago. I didn't have the timeout disabled but that wasn't what was crashing the box. I disabled it since I didn't need yet another thing to crash the box.
The crash I am experiencing is a unrecoverable error occurring with communication on the PCI bus. You would at first possibly think that it could be hardware related but it happens on multiple controllers and only since ONTap 8.1. The only thing I can add is what they have said after they have done core analysis to the issues.
Filer is reporting PCI error NMI on Br(20,0,0) that is responsible for communication to [23/24,0,0] PMC-Sierra SAS Adapter in slot 3. Usually, when the ultimate recipient of a transaction receives a completion packet into the transaction layer, the packet format is checked for violations of the TLP formatting rules. The specification defines that the following items can cause a MfTLB:
1. Data payload exceeds Max payload size.
2. The actual data length does not match data length specified in the header.
3. Packets which use an undefined Type field values.
The filers we have run a mix of CIFS/NFS/Fibre with some just Fibre.
Have you checked the PMC-Sierra SAS Adapter firmware version? There were a number of bug fixes in later 8.02Px releases including the one below: