Let me be the first to say, I could be wrong here, but since 6.0 allows you to offline a volume without rebooting the filer should be able to revert it back without affecting any other volumes. I believe that's what the error message is telling you...
Filesystem version mismatch for destination volume vol1, reverting the version and aborting transfer. A console message will be displayed when this revert is complete.
Therefore, look for a revert complete message on the console (and probably /etc/messages) and it should work.
SnapMirror would have the same issue for the initial transfer. Basically the filesystems have to match. But since 6.x can revert, it works. Obviously 5.x can't upgrade the filesystem to 6.x.
-- Adam Fox NetApp Professional Services, NC adamfox@netapp.com
-----Original Message----- From: Brian L. Brush [mailto:brian@paradyne.com] Sent: Tuesday, February 20, 2001 2:55 PM To: Fox, Adam Cc: toasters@mathworks.com Subject: Re: vol copy from 5.3.6R2 to 6.0.1R1
"Fox, Adam" wrote:
You can still do the transfer. It just has to revert the target (F760) to the 5.3 filesystems first. After that revert is complete, you can do the vol copy.
My understanding is, in that case, I would have to revert ALL of the 760's volumes before the migration from the 230. Although I'm in a test environment at this point--well, half of a test environment--at the time of the actual migration the 760 will have several hundred gigabytes' worth of other volumes already online.
Is there a way to perform the vol copy without affecting the target filer's other volumes?
I would try SnapMirror, but I don't have licenses for it on both boxes.
I'm really trying to avoid the old Unix box intermediary, both because down-time is inversely proportional to speed and because my level of uneasiness is proportional to the intricacy of the migration plan.
--Brian L. Brush Senior Systems Administrator Paradyne Corporation
Adam.Fox@netapp.com writes
Let me be the first to say, I could be wrong here, but since 6.0 allows you to offline a volume without rebooting the filer should be able to revert it back without affecting any other volumes. I believe that's what the error message is telling you...
That was my immediate reaction on seeing the original posting as well!
But why isn't reversion of an *offline* volume, which is about to be completely overwritten by "vol copy", essentially an instantaneous thing? Maybe if I understood these zone checksums better it would be clearer, but I can see why it takes time to make them correct, but not why it should take any time to discard them.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
"Fox, Adam" wrote:
Let me be the first to say, I could be wrong here, but since 6.0 allows you to offline a volume without rebooting the filer should be able to revert it back without affecting any other volumes. I believe that's what the error message is telling you...
Therefore, look for a revert complete message on the console (and probably /etc/messages) and it should work.
Yes, the reversion did finish after 80 minutes (for four 72 GB drives in an F760), and now I can happily vol copy from the 230.
During the migration, though, my destination volume on the F760 will be a newly created volume of ten 18 GB drives--I will be unable to create that volume until I first migrate data from the existing volumes using those drives. Therefore, I won't want to create my new volume under ONTAP 6.0 and wait for the reversion before I can continue my data migration.
Under 6.0, is there a way to create a new volume without checksums instead of waiting for a forced reversion?
--Brian L. Brush Senior Systems Administrator Paradyne Corporation
First of all this mail was somehow resent from February.
The message here refers to checksum revert. With certain combinations of checksums on the source and destination, volcopy must trigger this revert (of checksums) on the destination side before the volcopy can proceed. This happens on a per volume basis. In later releases we tried to make the messages clearer.
mikef
Let me be the first to say, I could be wrong here, but since 6.0 allows you to offline a volume without rebooting the filer should be able to revert it back without affecting any other volumes. I believe that's what the error message is telling you...
Filesystem version mismatch for destination volume vol1, reverting the version and aborting transfer. A console message will be displayed when this revert is complete.
Therefore, look for a revert complete message on the console (and probably /etc/messages) and it should work.
SnapMirror would have the same issue for the initial transfer. Basically the filesystems have to match. But since 6.x can revert, it works. Obviously 5.x can't upgrade the filesystem to 6.x.
-- Adam Fox NetApp Professional Services, NC adamfox@netapp.com
-----Original Message----- From: Brian L. Brush [mailto:brian@paradyne.com] Sent: Tuesday, February 20, 2001 2:55 PM To: Fox, Adam Cc: toasters@mathworks.com Subject: Re: vol copy from 5.3.6R2 to 6.0.1R1
"Fox, Adam" wrote:
You can still do the transfer. It just has to revert the target (F760) to the 5.3 filesystems first. After that revert is complete, you can do the vol copy.
My understanding is, in that case, I would have to revert ALL of the 760's volumes before the migration from the 230. Although I'm in a test environment at this point--well, half of a test environment--at the time of the actual migration the 760 will have several hundred gigabytes' worth of other volumes already online.
Is there a way to perform the vol copy without affecting the target filer's other volumes?
I would try SnapMirror, but I don't have licenses for it on both boxes.
I'm really trying to avoid the old Unix box intermediary, both because down-time is inversely proportional to speed and because my level of uneasiness is proportional to the intricacy of the migration plan.
--Brian L. Brush Senior Systems Administrator Paradyne Corporation
-
Brian L. Brush -
Chris Thompson -
Fox, Adam -
Mike Federwisch