Copy method on ZFS pools

[triluch]

Refs #47

This method works, however there is limitation when using zfs snapshot and clone: clone is dependant on original dataset and it's snapshot and ZFS does not offer any way around that (zfs promote allows to switch parent-child relationship, but doesn't break it).

So, when user creates copy the source dataset cannot be destroyed as long as copies exist.

This may be surprising and not desired behavior for the end user, but there is no viable way to remedy this (except using zfs send | zfs recv instead, but this is long operation and involves copying all data on dataset).

Because of that I was thinking about making a flag in config to enable copy method on ZFS, so user will be aware of consequences and limitations.

@tasleson What do you think about that?

[tasleson]

@triluch Let me think about this a bit. LibStorageMgmt has API calls for determining when a Parent/Child dependency exists and methods which can be called to mitigate. However, we hard coded what functionality is supported into the targetd plugin.

Just to clarify, If you have parent, create the child, then do a promote to switch parent child relationship, you still cannot delete the parent?

[tasleson]

@triluch I think you should go ahead with a flag in the configuration. We may want to add some API calls to allow better integration with things like libStorageMgmt and others, so that they can query operations that are supported for each pool.

I think we should also add an error code on the delete path which indicates that volume cannot be deleted as it has dependent volumes.

[triluch]

@tasleson

Just to clarify, If you have parent, create the child, then do a promote to switch parent child relationship, you still cannot delete the parent?

Child then becomes parent. "Old" child (new parent) cannot be then deleted until "old" parent (new child) exists. Promote jest switches which dataset is the parent. If we do:

zfs create tank/src
zfs snapshot tank/src@snap
zfs clone tank/src@snap tank/dst

Then tank/src cannot be deleted as long as tank/dst exists. Snapshot "snap" is listed as tank/src's snapshot. Then if we do:

zfs promote tank/dst

tank/dst cannot be deleted as long as tank/src exists. Snapshot "snap" becomes listed as tank/dst's snapshot. So the cloned datasets cannot be unlinked from their source.

[triluch]

@tasleson I have added config option to enable copy on ZFS, warning in manual about it and set it to false by default (true for tests though). Also added specific error for deleting volumes with dependent clones. I have reused one of existing error codes for that, because I wasn't sure how are the codes assigned now, but that's of course easy to change if needed.

[triluch]

Error code fixed.

[tasleson]

@triluch Thanks!