8.1 32bit > 64bit VSM

[nsitps1976]

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?

[baijulal]

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

[aborzenkov]

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]

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]

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

[nsitps1976]

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]

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]

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]

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.