LUN Clones vs. FlexClones

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.

Tags: , ,


  1. Jeremy’s avatar

    That’s one of the reasons that the best practice is to have a 1:1 lun:vol relationship. Creating multiple flexible volumes doesn’t take any more space apart from the snapshot reserve. Snapshot per volume, lun per volume = snapshot per lun.

    At least, that’s my understanding.

  2. slowe’s avatar


    Yes, you’re correct in that using a 1:1 relationship between LUNs and volumes does allow for independent Snapshots of each LUN, since Snapshots run on a volume level.

    The ability to do a LUN clone for no additional charge, though, does make LUN clones useful in some scenarios.


  3. BA’s avatar

    I’m very new to ONTAP and lun/volume creation, so I am hoping to get some help :)

    I want to take a nightly snapshot of production database lun and present it to a development server for the devs to hammer on. What would be your recommendation for doing so, as automatically as possible of course :) Can we hammer thru this together? thx!!

  4. slowe’s avatar


    I’d recommend you take a really close look at NetApp’s SnapManager products. SnapManager for SQL and SnapManager for Oracle have hooks into the DB engines to ensure that the Snapshots are consistent and recoverable, and they provide automation tools to make the whole process easy.

    Otherwise, the process is certainly doable, but requires downtime from the database (you need to stop the database in order to ensure a consistent Snapshot) and some manual scripts to create clones for development and testing.

    Good luck!

  5. Vijay Raghavan’s avatar

    On the question of one lun per flexvol, isn’t there a smallish limit on the total number of flexvols that an aggregate supports?

  6. Jugoslav Djajic’s avatar

    Vijay, you are right, there is a 500 FlexVol limit, but unfortunately it’s not per aggregate, it’s per filer.

  7. Mouli’s avatar

    When we have 1:1 relationship between the lun : flexvol , it means i have only a single file in the filesystem.

    How do we create a lun clone in this scenarion. Ideally, the filesystem doesnot have any space for the lun clone ??

  8. Anand’s avatar

    The recent release of ONTAP 8.1 provides the ability to create LUN clones using the FileClone engine. This does away with any dependency on SnapShots. The upper limit for number of FileClones in a Vol is 32K. Therefore more than one LUN and its clone can be created in a Vol without the worry of running into Vol limits. As the clones are not Snapshots dependent any more. The Snapshots can be deleted.

  9. slowe’s avatar

    Anand, thanks for your comment, and thanks for clarifying the functionality that is present in newer versions of ONTAP. In the future, please be sure to disclose that you work for NetApp, so that other readers are aware of the affiliation. Thanks!

Comments are now closed.