ONTAP Discussions

8.1 32bit > 64bit VSM

nsitps1976
5,063 Views

I am using VSM to replicate 32bit src volumes (7.3.3) to 64bit dest (8.1). Once the initialize is complete my dest vols revert back to 32bit.

Is this expected behaviour and how can I rectify this?

8 REPLIES 8

baijulal
5,063 Views

Not sure this a BURT, but note that customers are advised to run 8.1RC3.

aborzenkov
5,063 Views

Volumes remain 32 bit for the duration of SnapMirror relationship (otherwise they could not be updated). They will be converted to 64 bit after snapmirror break.

nsitps1976
5,063 Views

Great, thanks.

How does this affect a flexclone of the dest snapmirrored volume? This will be a 32bit volume? Will this cause issues within a 64bit aggr?

aborzenkov
5,063 Views

Good question. I do not know. Care to test and report?

nsitps1976
5,063 Views

Sure, already done.

When the clone is initiated a number of tasks begin:

  1. [###:wafl.scan.start:info]: Starting splitting of the inofile on volume ###
  2. [###:wafl.scan.64bit.upgrade.start:notice]: The 64-bit upgrade scanner has started running on volume ###

Once this is complete a 64bit upgrade begins:

[###:wafl.scan.start:info]: Starting 64bit upgrade on volume ###

Depending on the size of the volume the time to complete the task varies.

I have noticed that DOT will only do one upgrade at a time. i.e. I created a number of clones but each upgrade waits until the previous has finished – The end result is a 64bit flexclone of a 32bit parent.

Lastly, the flexclone seems to use a little more space than a native 64bit to 64bit clone, or this is what I am assuming as space within the aggr does reduce more than expected with a flexclone.

aborzenkov
5,063 Views

So you mean that it immediately starts 32 to 64 bit conversion for clone? Good to know. In this case it is expected that it will consume more space, as more data will change compared with native clone.

nsitps1976
5,063 Views

Yes, the conversion begins immediately, however, if I create a 2nd clone before the first conversion is complete the 2nd conversion waits until the first is complete.

Oliver_Fuckner
5,063 Views

I have a pretty large volume (3.4T and 127Mio inodes in use), this really takes a long time:

First the scanner:

Tue Jun 19 12:39:56 CEST [diamond:wafl.scan.start:info]: Starting splitting of the inofile on volume xxxVSM64. 

Tue Jun 19 12:39:56 CEST [diamond:wafl.split.inofile.scan.complete:info]: Volume xxxVSM64 Split inofile scan completed. 

Tue Jun 19 12:39:56 CEST [diamond:wafl.scan.start:info]: Starting 64bit space qualifying on volume xxxVSM64. 

Wed Jun 20 00:19:33 CEST [diamond:wafl.scan.64bit.space.done:notice]: The 64-bit space qualifying scanner has completed running on Volume xxxVSM64. 

After this, the volume is 64bit when you look at vol status

now the conversion:

Wed Jun 20 00:44:33 CEST [diamond:wafl.64bit.upgrade.start:notice]: The 64-bit upgrade has started on volume xxxVSM64.

Wed Jun 20 00:44:33 CEST [diamond:wafl.scan.64bit.upgrade.start:notice]: The 64-bit upgrade scanner has started running on volume xxxVSM64.

Wed Jun 20 00:44:33 CEST [diamond:wafl.scan.start:info]: Starting 64bit upgrade on volume xxxVSM64.

Right now, after 11 hours of conversion, 97 of 157 mio blocks are converted, so it will finish in 3-5 hours I suppose.

Public