LUN Clones vs. FlexClones
Published on 21 May 2007 · Filed in Explanation · 592 words (estimated 3 minutes to read)My recent article on how to provision VMs using FlexClones prompted a reader to ask the question, “What about using LUN clones?” That’s an excellent question, and one that I myself asked when I first started using some of the advanced functionality of Network Appliance storage systems. I had expected that this question would come up, and so I’d already begun preparing an article discussing LUN clones vs. FlexClones. My thanks go to Aaron for prompting the discussion!
LUN clones and FlexClones share a lot of similarities:
-
Both LUN clones and FlexClones are built on top of the Snapshot functionality resident within Data ONTAP, the OS that runs on Network Appliance storage systems.
-
Both LUN clones and FlexClones are space conservative, meaning the clones only take up as much space as required to store changes from the original.
-
Both LUN clones and FlexClones can be created in seconds, and the size of the LUN (or FlexVol) does not significantly impact the time required to create the clone.
The key disadvantage to using LUN clones comes as a result of an interaction between how WAFL (the file system used by Data ONTAP) handles LUNs, and how Snapshots are performed and managed.
From WAFL’s perspective, a LUN is really nothing more than a single file on the file system. You can see this by browsing via CIFS or NFS to a FlexVol that contains a LUN:
[macosx:/Volumes/vol02$] slowe% ls -la
total 25165856
drwx------ 1 slowe admin 16384 Dec 31 1969 .
drwxrwxrwt 8 root admin 272 May 21 11:47 ..
-rwx------ 1 slowe admin 12884901888 May 21 11:48 vswex02_vmfs
If I were to enable the .snapshot (or ~snapshot) directory, we’d actually be able to see Snapshots of the LUN within that directory. In fact, this NOW (NetApp on the Web; login required) article describes mounting LUN snapshots inside the .snapshot (or ~snapshot) as a way of recovering files or folders inside a snapshot. This technique is also applicable to recovering VMs from a LUN snapshot.
“OK,” you may be saying, “so LUNs are implemented and managed as files. What’s your point?”
My point is that Snapshots are handled per volume, and capture all the data in the active filesystem. A LUN exists as a file in the filesystem, so a Snapshot will capture that. When you create a LUN clone, you will then create another file in the active filesystem, which subsequent Snapshots will then capture. The end result is that you can end up with Snapshots that cannot be deleted because they reference a LUN clone which is, in turn, backed by another Snapshot. In these cases, you won’t be able to delete Snapshots until you delete the LUN clone and all the Snapshots that reference that LUN clone. This blog posting discusses this very problem and provides a Data ONTAP command to help track down the dependencies. (I’m also told that there is a NOW article on this problem as well, but I was unable to locate it.)
For short-term scenarios, LUN cloning works well and is, as some have pointed out, free (FlexClone requires a separate, paid license). For longer-term storage scenarios, however, LUN clones and the dependencies introduced by subsequent Snapshots of those LUN clones mean that FlexClones are a better solution. Since FlexClones are entire volumes stored within an aggregate, they aren’t subject to the same problems as LUN clones (which are stored within a volume).
I hope this helps clear up some of the differences between using LUN clones and using FlexClones. Add your comments or questions below.