How to create "persistent and independent clone" of a volume ?

Why do want to create a full binary replica of the original volume. Typically, customers have done that because a full binary copy does not have any performance implication on the original volume. A snapshot on the other hand will have performance impact and therefore customers did not take snapshots when they needed a copy of the parent volume.

With XtremIO, all those considerations do not apply. Internally, a snapshot is treated just like any other volume – it has the same performance as any other volume in the array and it has the same data services that the parent volume has. You can always take a snapshot of the original volume and present it to another host, if needed (Snapshots can be created read-only or read-write).

Why does it make a difference if the snapshot icon does not change if the original volume is deleted? You would be surprised to know that there were some customers who requested exactly the opposite of what you are asking for (they want the snapshot icon to remain there all the time). In any case, it does not make any difference in how you use the snapshots.

If you absolutely have to create a full binary copy of a volume, you can always use a host based copy mechanism. But the array would not store two copies of the same data because of inline, global deduplication. The copy operation is going to be very fast, because it turns into a memory operation in XtremIO (because of in memory metadata) – not even a flash operation.

Avi,

i realize there is no "clone" per say but this visual indicator of a snapshot volume versus a "regular" volume is nagging me. I look at it and think: is this a snapshot that was created as part of an upgrade that DBAs wanted to use to roll back in case of a issue or is this a brand new reporting database that was created by snapping my production database.  I would love to be able to control that distinction myself. While you may think it's not important, operationally it's important to me.

I understand your point but wouldn't it be easier to track that detail by naming the snapshots appropriately instead of relying on the icons?

At that scale, is the volume icon going to help you track what the use case of a specific volume is?

If having a volume icon (for a copy) is that important, then one option for now would be to create a full binary copy of the volume using a host side software. Because of deduplication – you would still not consume any extra physical storage on the SSDs, the downside (compared to snapshot based copy) is that you would be consuming extra metadata space in the storage controllers.

Keep in mind that, a snapshot based deployment provides you a lot of other benefits like being able to refresh and restore at any point of time in future. You will not have this option if you are creating full copies from the host level.

In parallel, I will pass on your requirement to the right folks internally.

volume names are not a good way to track application usage in my environment. Remember the platform i was telling you about over private chat. Well i will present over 1 thousand volumes to that platform and once they are presented i have no idea what application these volumes are used for,  i am sure they will be re-used as well for other applications without me being notified. So as you can see at this scale i am not going to deal with volume names, not practical and error prone.

visual indicators are very helpful, for example if you look at LUNs on a VNX, traditional flare LUNs versus pool LUNs. They are easy to identify,  one set of LUNs has very different functionality than others.

My concern with using snapshots as my "cloning" technology is the fact that snapshots will have the option to "Refresh this Volume". While it's great for copies of data that need to be refreshed from prod from time to time, it could be dangerous if i wanted to have an independent "copy" that should have absolutely no association with the volume it was "copied" from. Either let me "clone" (you can use the secret sauce underneath to simply create pointers) or let me "unlink" snapshots from the original volumes.

Not interested in host based copies , no thank you.

Thank you Avi

Dynamox, maybe this is a good case for you to use tags ?

Understood. I can tell you that we are discussing this internally, but this item is not on our roadmap at this time. Stay tuned

Brett,

i use tags to identify "mapping", what systems volumes are presented to.  For example system XYZ is blue color tag, system ABC is red ..etc.

I'm finding all sorts of uses for tags. Reporting is nice on V4

Is there a plan to enhance the ability to toggle on and off the "read-only" flag for snapshots in the future perhaps as well? Currently it seems like we can create a snapshot and at that time we can chose to have it writeable or read-only, but if we want to toggle it after the fact given any change in the business requirements, it doesn't seem possible that I am finding.

I realize we can make a snap of that snap that is writeable.

We made a conscious decision not to allow the read-only snapshots to be converted to read-write version. The assumption is that when the user decided to create a readonly snapshot – there must be a reason for that. Typically, the goal is to have a backup copy (or a set of copies) of the parent volume that you can use for restore at a later point of time, if needed. We don’t want to provide a way to ‘accidentally’ change the readonly snapshot and realize it later, when it is already too late.

As you mentioned, you can always take a RW snapshot of a RO snapshot.

OK, thanks Avi