Oracle ZFS Storage Appliance: Replication Source and Target Share Names are Different

Asset ID:	1-72-2126058.1
Update Date:	2018-01-05
Keywords:

Solution Type Problem Resolution Sure

Solution 2126058.1 : Oracle ZFS Storage Appliance: Replication Source and Target Share Names are Different

Applies to:

Sun ZFS Storage 7420 - Version All Versions and later
Sun ZFS Storage 7320 - Version All Versions and later
Sun ZFS Storage 7120 - Version All Versions and later
Oracle ZFS Storage ZS3-2 - Version All Versions and later
Oracle ZFS Storage Appliance Racked System ZS4-4 - Version All Versions and later
7000 Appliance OS (Fishworks)

Symptoms

On the source replication, project/share name is imgbck/imgbck_XESH
On the target replication, project/share name is imgbck/imgbck_XESh

Source
a101:shares imgbck> list
imgbck_XESH 1.94T off /export/imgbck_XESH

Target
a402:shares replication source-000 package-006 imgbck> list
imgbck_XESh 5.68T off /export/imgbck_XESh

Cause

Share name was mis-spelt before replication.

- The shares in question was first created with the name "imgbck_XESh"

Sun Feb 22 02:57:50 2015
nvlist version: 0
  address = 192.168.0.1
  host = 192.168.0.1
  annotation =
  user = user
  class = audit.ak.appliance.nas.share.create
  payload = (embedded nvlist)
  nvlist version: 0
  pool = localstore
  project = imgbck
  share = imgbck_XESh
  volume = 0
  (end payload)

- About 5 minutes later, it was renamed to "imgbck_XESH"

Sun Feb 22 03:02:51 2015
nvlist version: 0
  address = 192.168.0.2
  host = 192.168.0.2
  annotation =
  user = user2
  class = audit.ak.appliance.nas.share.rename
  payload = (embedded nvlist)
  nvlist version: 0
  pool = localstore
  project = imgbck01
  oldshare = imgbck_XESh
  newshare = imgbck_XESH
  (end payload)

And this answer where "imgbck_XESh" first came from.

Next question is, how this got to the replication target with the old name.

- Here we have a replication that was kicked off with the old name. The rename took place 51 seconds after the start of the replication.

Sun Feb 22 03:02:00 2015
nvlist version: 0
  project = imgbck
  target_host = a402
  source = appliance/kit/akd:default
  class = alert.ak.appliance.nas.project.replication.send.start
  uuid = 3c33bf07-f9c9-4835-8399-e8ff2847853c
  link =

- The replication finished at 3:51.

Sun Feb 22 03:51:13 2015
nvlist version: 0
  project = imgbck
  target_host = a402
  source = appliance/kit/akd:default
  link = 3c33bf07-f9c9-4835-8399-e8ff2847853c
  class = alert.ak.appliance.nas.project.replication.send.finish
  result = success
  uuid = aa13c217-4b01-6933-8f60-f42084d06d4c

So, in summary. We have the following.

Sun Feb 22 02:57:50 2015 - A share created with "imgbck_XESh"
Sun Feb 22 03:02:00 2015 - Replication started
Sun Feb 22 03:02:51 2015 - Share renamed to "imgbck_XESH"
Sun Feb 22 03:51:13 2015 - Replication finished

And we ended up with the old name in the replication target as the name was changed during mid replication.

Normally, if another replication update is run again. The updated name will migrate to the replication target.

But clone was created on the target, which made it not possible to update the replication target name due to bug 17279707.

Solution

Workaround:

Destroy all clones for this share/project at the replication target, then run a replication update.

This is caused by the following bug.

CR 17279707 - cannot update after reversing package with origin of out-of-project clone

Solution:

CR 17279707 is fixed in Appliance Firmware Release 2013.1.6.0

(... NOT yet released)

References

<BUG:17279707> - CANNOT UPDATE AFTER REVERSING PACKAGE WITH ORIGIN OF OUT-OF-PROJECT CLONE

Attachments

This solution has no attachment