Promote Snapshot to Subvolume? (again)

[Robert White]

I'll ask again...

Is there any reason it would be Bad=E2=84=A2 to allow a snapshot subvol=
ume to be=20
"promoted" to a non-snapshot subvolume?

I know that there is precious little difference between the two. But=20
there _is_ a difference once you start trying to automate system=20
maintenance.

What I want is a "btrfs property set /path snapshot false" that would=20
change the subvolume root such that it looked like it had been made wit=
h=20
"btrfs subvol create" instead of "btrfs subvol snapshot".


LONG BORING JUSTIFICATION:


One of my actual systems:

Gust ~ # btrfs sub list /
ID 256 gen 571944 top level 5 path home
ID 574 gen 571944 top level 5 path var/tmp
ID 962 gen 262649 top level 5 path BACKUP-2014-06-18
ID 963 gen 262648 top level 256 path home_BACKUP-2014-06-18
ID 964 gen 330331 top level 5 path BACKUP-2014-07-15
ID 965 gen 330331 top level 256 path home_BACKUP-2014-07-15
ID 970 gen 443923 top level 5 path BACKUP-2014-09-01
ID 971 gen 443924 top level 256 path home_BACKUP-2014-09-01

Gust ~ # btrfs sub list -s /
ID 962 gen 262649 cgen 262642 top level 5 otime 2014-06-18 02:25:33 pat=
h=20
BACKUP-2014-06-18
ID 963 gen 262648 cgen 262646 top level 256 otime 2014-06-18 02:27:38=20
path home_BACKUP-2014-06-18
ID 964 gen 330331 cgen 330330 top level 5 otime 2014-07-15 18:51:18 pat=
h=20
BACKUP-2014-07-15
ID 965 gen 330331 cgen 330331 top level 256 otime 2014-07-15 18:51:26=20
path home_BACKUP-2014-07-15
ID 970 gen 443923 cgen 443922 top level 5 otime 2014-09-01 04:04:14 pat=
h=20
BACKUP-2014-09-01
ID 971 gen 443924 cgen 443924 top level 256 otime 2014-09-01 04:04:36=20
path home_BACKUP-2014-09-01

With these two listings I can now automatically classify which elements=
=20
of the system are vital and which are redundant. E.g. which are "live"=20
and which are part of the backup scheme. (more-so with consideration fo=
r=20
read-only status but that's an aside.)


So clearly, in this instance, I did a mkfs.btrfs on the device to creat=
e=20
/, and a "btrfs subvol create" to make /home and /var/tmp

I want to make a an automatic snapshot and roll backup script that uses=
=20
the diff of these two outputs to decide what to snapshot and what to=20
age. No big deal. Works fine.

But when I come to the _restore_ operation it all falls apart. If, say,=
=20
I need to recreate /home from /home_BACKUP-2014-09-01 I _can_ delete th=
e=20
/home subvol, then make a non-read-only snapshot of=20
/home_BACKUP-2014-09-01 into /home and the system is back in=20
configuration...

BUT...

From that moment on the backup script would be broken because the=20
"restore-shot" (ha ha) is now going to show up in "btrfs sub list -s /"=
=20
where it would be excluded from being snapshotted and where it would be=
=20
subject to aging and eventual removal unless I rewrote the script.

ASIDE: I can custom write the script for the box, but there are more=20
boxes involved in the target roll-out. I could use naming conventions. =
I=20
could do a lot of things, but they'd become far more per-system specifi=
c.

ALSO: I know I could btrfs create /home and then copy the contents of=20
the relevant snapshot, but that now purturbs the long tail of metadata=20
for the more constant data.

So The Questions:

Does the "snapshotness" of a subvolume have any actual _ongoing_ purpos=
e=20
once it has been created?

Is there a reason _not_ to be able to de-snapshot a subvolume?

I fully understand that changing the property would be a one-way=20
operation since restoring the removed plumbing would be indeterminate.

-- Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html