You can use the snapshot_clone_dependency option to determine whether you can delete the base Snapshot copy without deleting the more recent Snapshot copies after deleting a LUN clone. This option is set to off by default.
The following example illustrates how all newer backing Snapshot copies must be deleted before deleting the base Snapshot copy when a LUN clone is deleted.
You can set the snapshot_clone_dependency option to off by entering the following command:
You can create a new LUN clone, lun_s1 from the LUN in Snapshot copy snap1. Also, you should run the lun show -v command to show that lun_s1 is backed by snap1.
system1> lun clone create /vol/vol1/lun_s1 -b /vol/vol1/lun snap1 system1>lun show -v /vol/vol1/lun_s1 32m (33554432) (r/w, online) Serial#: BYjB3?-iq3hU Backed by: /vol/vol1/.snapshot/snap1/lun Share: none Space Reservation: enabled Multiprotocol Type: linux Occupied Size: 0 (0) Creation Time: Tue Oct 19 10:49:13 GMT 2010 Cluster Shared Volume Information: 0x0
You should run the snap list command to show that snap1 is busy, as expected.
system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 24% (24%) 0% ( 0%) Dec 20 02:40 snap1 (busy,LUNs)
When you create a new Snapshot copy, snap2, it contains a copy of lun_s1, which is still backed by the LUN in snap1.
system1> snap create vol1 snap2 system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 24% (24%) 0% ( 0%) Dec 20 02:41 snap2 43% (31%) 0% ( 0%) Dec 20 02:40 snap1 (busy,LUNs)
You should run the lun snap usage command to show this dependency.
system1> lun snap usage vol1 snap1 Active: LUN: /vol/vol1/lun_s1 Backed By: /vol/vol1/.snapshot/snap1/lun Snapshot - snap2: LUN: /vol/vol1/.snapshot/snap2/lun_s1 Backed By: /vol/vol1/.snapshot/snap1/lun
Then you should delete the LUN clone lun_s1.
system1> lun destroy /vol/vol1/lun_s1 Wed Dec 20 02:42:23 GMT [wafl.inode.fill.disable:info]: fill reservation disabled for inode 3087 (vol vol1). Wed Dec 20 02:42:23 GMT [wafl.inode.overwrite.disable:info]: overwrite reservation disabled for inode 3087 (vol vol1). Wed Dec 20 02:42:23 GMT [lun.destroy:info]: LUN /vol/vol1/lun_s1 destroyed
system1> lun show /vol/vol1/lun 30m (31457280) (r/w, online)
You should run the lun snap usage command to show that snap2 still has a dependency on snap1.
system1> lun snap usage vol1 snap1 Snapshot - snap2: LUN: /vol/vol1/.snapshot/snap2/lun_s1 Backed By: /vol/vol1/.snapshot/snap1/lun
You should run the snap list command to show that snap1 is still busy.
system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 39% (39%) 0% ( 0%) Dec 20 02:41 snap2 53% (33%) 0% ( 0%) Dec 20 02:40 snap1 (busy, LUNs)
Since snap1 is still busy, you cannot delete it until you delete the more recent Snapshot copy, snap2.
The following example illustrates how you can delete a base Snapshot copy without deleting all newer backing Snapshot copies when a LUN clone is deleted.
You can set the snapshot_clone_dependency option to on by entering the following command:
You can create a new LUN clone, lun_s1, from the LUN in Snapshot copy snap1. You should run the lun show -v command to show that lun_s1 is backed by snap1.
system1> lun clone create /vol/vol1/lun_s1 -b /vol/vol1/lun snap1 system1> lun show -v /vol/vol1/lun_s1 32m (33554432) (r/w, online) Serial#: BYjB3?-iq3hU Backed by: /vol/vol1/.snapshot/snap1/lun Share: none Space Reservation: enabled Multiprotocol Type: linux Occupied Size: 0 (0) Creation Time: Tue Oct 19 10:49:13 GMT 2010 Cluster Shared Volume Information: 0x0
You should run the snap list command to show that snap1 is busy, as expected.
system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 24% (24%) 0% ( 0%) Dec 20 02:40 snap1 (busy,LUNs)
When you create a new Snapshot copy, snap2, it contains a copy of lun_s1, which is still backed by the LUN in snap1.
system1> snap create vol1 snap2 system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 24% (24%) 0% ( 0%) Dec 20 02:41 snap2 43% (31%) 0% ( 0%) Dec 20 02:40 snap1 (busy,LUNs)
You should run the lun snap usage command to show this dependency.
system1> lun snap usage vol1 snap1 Active: LUN: /vol/vol1/lun_s1 Backed By: /vol/vol1/.snapshot/snap1/lun Snapshot - snap2: LUN: /vol/vol1/.snapshot/snap2/lun_s1 Backed By: /vol/vol1/.snapshot/snap1/lun
Then you can delete the LUN clone lun_s1.
system1> lun destroy /vol/vol1/lun_s1 Wed Dec 20 02:42:23 GMT [wafl.inode.fill.disable:info]: fill reservation disabled for inode 3087 (vol vol1). Wed Dec 20 02:42:23 GMT [wafl.inode.overwrite.disable:info]: overwrite reservation disabled for inode 3087 (vol vol1). Wed Dec 20 02:42:23 GMT [lun.destroy:info]: LUN /vol/vol1/lun_s1 destroyed
system1> lun show /vol/vol1/lun 30m (31457280) (r/w, online)
You should run the lun snap usage command to show that snap2 still has a dependency on snap1.
system1> lun snap usage vol1 snap1 Snapshot - snap2: LUN: /vol/vol1/.snapshot/snap2/lun_s1 Backed By: /vol/vol1/.snapshot/snap1/lun
You should run the snap list command to show that snap1 is no longer busy.
system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 39% (39%) 0% ( 0%) Dec 20 02:41 snap2 53% (33%) 0% ( 0%) Dec 20 02:40 snap1
Since snap1 is no longer busy, you can delete it without first deleting snap2.
system1> snap delete vol1 snap1 Wed Dec 20 02:42:55 GMT [wafl.snap.delete:info]: Snapshot copy snap1 on volume vol1 was deleted by the Data ONTAP function snapcmd_delete. The unique ID for this Snapshot copy is (1, 6).
system1> snap list vol1 Volume vol1 working... %/used %/total date name ---------- ---------- ------------ -------- 38% (38%) 0% ( 0%) Dec 20 02:41 snap2