Just in case you don't know: Solaris ZFS knows the concept of "promoting" a clone to become a primary filesystem.
Imagine you did a clone of a big database filesystem running in another rdbms instance.
Now you want to use that clone as production file system and you don't need the original file system any more. This won't work because the clone DEPENDS on the original filesystem.
To change that, simply use the promote command to reverse the dependency between clone and original.
Example:
# zfs snapshot mypool/rdbmsdata@snap1
We just created a snapshot of the rdbmsdata filesystem.
Now let's make a clone:
# zfs clone mypool/rdbmsdata@snap1 mypool/rdbmsclone
Result:
mypool/rdbmsclone 0 149G 371M /mypool/rdbmsclone
mypool/rdbmsdata 371M 149G 371M /mypool/rdbmsdata
mypool/rdbmsdata@snap1 0 - 371M -
As you can see, the clone "rdbmsclone" does not need any space - we did not change anything, it does not differ from its parent "rdbmsdata".
In case you want to delete "rdbmsclone" the system will refuse - it will ask you to bury rdbmsclone as well, because rdbmsclone is dependent on rdbmsdata.
To revert this depency, just type:
# zfs promote mypool/rdbmsclone
Result:
mypool/rdbmsclone 371M 149G 371M /mypool/rdbmsclone
mypool/rdbmsclone@snap1 0 - 371M -
mypool/rdbmsdata 0 149G 371M /mypool/rdbmsdata
Watch the snapshot "snap1". It became a snaphot of "rdbmsclone".
Now it's possible to destroy "rdbmsdata" as it became in turn dependent on "rdbmsclone":
# zfs destroy mypool/rdbmsdata
And it has gone:
mypool/rdbmsclone 371M 149G 371M /mypool/rdbmsclonemypool/rdbmsclone@snap1 0 - 371M -
Not rocket science, but worth noting. And a big timesaver in many circumstances when doing upgrades, version tests or benchmarks with different versions.
Leave a comment