snapshots, cloning, & promoting

[Dave Cottlehuber]

My old iMac finally died which gave me the convenient excuse to
upgrade my MBP to 16GiB RAM + an additional 512GiB SSD -- your envy is
welcomed. Along the way dropbox did its thing and wiped all the data.
Naturally I had a zfs snapshot so this previously horrifying incident
turned into a mild annoyance. Yay zfs.

However it became apparent I don't understand how snaps and clones
work when it comes to promotion. Why does cloning and promoting a
*snapshot* move the preceding snaps across to the clone, and not leave
a CoW copy or something under the original tub/test* tree?


% zfs create tub/test
% cd /zfs/test
% touch 1
% zfs snapshot tub/test@1
% touch 2
% zfs snapshot tub/test@2
% touch 3
% zfs snapshot tub/test@3
% touch 4
% zfs snapshot tub/test@4
% touch 5
% zfs list |grep test
tub/test 67K 70.6G 19K /zfs/test
tub/test@1 16K - 19K -
tub/test@2 16K - 19K -
tub/test@3 16K - 19K -
tub/test@4 0 - 19K -
% zfs snapshot tub/test@5
% zfs clone tub/test@3 tub/test3
% zfs list |grep test
tub/test 84K 70.6G 20K /zfs/test
tub/test@1 16K - 19K -
tub/test@2 16K - 19K -
tub/test@3 16K - 19K -
tub/test@4 16K - 19K -
tub/test@5 0 - 20K -
tub/test3 0 70.6G 19K /zfs/test3
% zfs promote tub/test3
% zfs list |grep test
tub/test 33K 70.6G 20K /zfs/test
tub/test@4 16K - 19K -
tub/test@5 0 - 20K -
tub/test3 51K 70.6G 19K /zfs/test3
tub/test3@1 16K - 19K -
tub/test3@2 16K - 19K -
tub/test3@3 0 - 19K -
########### WAT JUST HAPPENED? ############
% zfs destroy -r tub/test
% zfs list |grep test
tub/test3 51K 70.6G 19K /zfs/test3
tub/test3@1 16K - 19K -
tub/test3@2 16K - 19K -
tub/test3@3 0 - 19K -

As a side note if you know how I could merge the resulting snaps back
into a single timeline (kinda like a git merge rebase combo) that
would be cosmetically nice. Rsync did the job but it wastes space as
it treats renamed files as new.

A+
Dave

[Lucien Pullen]

Also sprach Dave Cottlehuber at 10/12/12 2:22 AM:

> My old iMac finally died which gave me the convenient excuse to
> upgrade my MBP to 16GiB RAM + an additional 512GiB SSD -- your envy is
> welcomed.

There's enough to share with everyone.

> Along the way dropbox did its thing and wiped all the data.

Dropbox on ZFS? I take it there's an easier way than tricking Dropbox
into running on a mountpoint than the way I did.

> However it became apparent I don't understand how snaps and clones
> work when it comes to promotion. Why does cloning and promoting a
> *snapshot* move the preceding snaps across to the clone, and not leave
> a CoW copy or something under the original tub/test* tree?

It does, actually. History is still tied to the old snapshots (which
are tied to the original filesystem), but exists in a different
location in the tree. A little confusing, but it works.

ZFS gurus: Is there a way to see that dependency chain at once other
than trying to non-recursively delete a filesystem that has snapshots
and clones?

I've only promoted once (a VirtualBox image for WinXP had gone
horribly wrong and everything was broken), and it's ~3:30 AM, so I'll
leave a more in-depth explanation to someone that isn't half asleep,
but that's the gist of it.

> As a side note if you know how I could merge the resulting snaps back
> into a single timeline (kinda like a git merge rebase combo) that
> would be cosmetically nice. Rsync did the job but it wastes space as
> it treats renamed files as new.

Not a clue... have never thought of doing that. Maybe take a hint from
how Solaris handles boot environments?

.... ....

On second thought, look at how Solaris handles boot environments
(maybe try one yourself). That should clear up some confusion.

[Dave Cottlehuber]

On 12 October 2012 10:34, Lucien Pullen <drur...@gmail.com> wrote:
> Also sprach Dave Cottlehuber at 10/12/12 2:22 AM:
>> My old iMac finally died which gave me the convenient excuse to
>> upgrade my MBP to 16GiB RAM + an additional 512GiB SSD -- your envy is
>> welcomed.
>
> There's enough to share with everyone.
>
>> Along the way dropbox did its thing and wiped all the data.
>
> Dropbox on ZFS? I take it there's an easier way than tricking Dropbox
> into running on a mountpoint than the way I did.

Not sure what you mean, this is what I do:

ll ~/Dropbox
lrwxr-xr-x 1 dch staff 19B 11 Oct 01:02 /Users/dch/Dropbox@ ->
/zfs/shared/dropbox

I don't think that counts as a trick really.

Also, before I add the softlink I do this to make it all clean & tidy.

cd /zfs/shared/dropbox
rsync -thrivazP --delete <old_dropbox_location>/ .
mkdir .fseventsd && touch .fseventsd/no_log

The last bit is the only non-obvious one. It tells avoids having a
system-generated .fseventsd folder that never completes syncing. I
don't recall where I found this tip but its handy.

> On second thought, look at how Solaris handles boot environments
> (maybe try one yourself). That should clear up some confusion.

I suspect I'll leave this tip for when I've actually used solaris at
some future point! But thanks for it.

A+
Dave