[
https://issues.apache.org/jira/browse/CLOUDSTACK-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751833#comment-13751833
]
edison su commented on CLOUDSTACK-4489:
---------------------------------------
1. yes we were tracking snapshot on primary storage, but the new code doing the
same thing a little bit different. In 4.2, we only track the leaf snapshot on
primary storage, stored it in snapshot_store_ref table, while in pre-4.2, we
put the information in snapshot table. In order to get the exact behavior, we
need to go through the snapshot chain, find out the leaf snapshot, then stored
in in snapshot_store_ref table, which will take a lot of time during the
upgrade to do that.
2. Take full snapshot after upgrade, it's the safest way for upgrade. We may
have problem during the upgrade, or the upgrade procedure has problem which
haven't occurred currently, but as long as we take full snapshot after the
upgrade, then we can guarantee the snapshot will always work.
3. the resource code will deal with how to delete snapshot from primary
storage. Take xenserver as example, everytime, after backup the current
snapshot into secondary storage, the resource code will delete the snapshot's
parents on primary storage.
> [object_store_refactor] First snapshot on disk after upgrade is not
> incremental if there was a snapshot taken before upgrade for the disk
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-4489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4489
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Storage Controller, XenServer
> Affects Versions: 4.2.1
> Environment: Build is from commit
> :a6bf80216466ada185de7e04d3e64be4e25c11a7
> Upgrade from 3.0.6 to 4.2
> Cluster: Xen
> Reporter: Sanjeev N
> Assignee: edison su
> Priority: Critical
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, management-server.log,
> management-server.log.2013-08-23.gz
>
>
> First snapshot on disk after upgrade is not incremental if there was a
> snapshot taken before upgrade for the disk
> Steps to reproduce:
> ===============
> 1.Install 3.0.6 and bring up CS with xen cluster
> 2.Deploy guest vm with both root and data disk
> 3.Create a snapshot on data disk
> 4.Upgrade to 4.2
> 5.After upgrade again take snapshot on the same data disk
> Result:
> ======
> Snapshot created was full snapshot.
> Observations:
> ===========
> In snapshot_store_ref table parent_snapshot_id was set to 0. Created another
> snapshot on the same data disk for which parent_snapshot_id was set to the
> snapshot_id taken after the upgrade.
> mysql> select id,snapshot_id,volume_id,parent_snapshot_id,install_path from
> snapshot_store_ref where volume_id=11 and store_role='Image';
> +-----+-------------+-----------+--------------------+-----------------------------------------------------+
> | id | snapshot_id | volume_id | parent_snapshot_id | install_path
> |
> +-----+-------------+-----------+--------------------+-----------------------------------------------------+
> | 1 | 1 | 11 | 0 |
> snapshots/2/11/eb957385-d67e-4338-8f24-831a392dba0e |
> | 227 | 115 | 11 | 0 |
> snapshots/2/11/2900f706-c6b8-4ab0-ab5a-a3a4b40d709b |
> | 229 | 116 | 11 | 115 |
> snapshots/2/11/2900f706-c6b8-4ab0-ab5a-a3a4b40d709b |
> +-----+-------------+-----------+--------------------+-----------------------------------------------------+
> snapshot_id 1 was taken before upgrade, 115 and 116 were taken after upgrade.
> For snapshot 115 parent_snapshot_id is 0 and snapshot size is same as
> snapshot 1 i.e. it's a full snapshot.
> Attaching management server log file and cloud db.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
