Promote Snapshot to Subvolume? (again)

Promote Snapshot to Subvolume? (again)

[Robert White]

I'll ask again...

Is there any reason it would be Bad™ to allow a snapshot subvolume to be 
"promoted" to a non-snapshot subvolume?

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

What I want is a "btrfs property set /path snapshot false" that would 
change the subvolume root such that it looked like it had been made with 
"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 path 
BACKUP-2014-06-18
ID 963 gen 262648 cgen 262646 top level 256 otime 2014-06-18 02:27:38 
path home_BACKUP-2014-06-18
ID 964 gen 330331 cgen 330330 top level 5 otime 2014-07-15 18:51:18 path 
BACKUP-2014-07-15
ID 965 gen 330331 cgen 330331 top level 256 otime 2014-07-15 18:51:26 
path home_BACKUP-2014-07-15
ID 970 gen 443923 cgen 443922 top level 5 otime 2014-09-01 04:04:14 path 
BACKUP-2014-09-01
ID 971 gen 443924 cgen 443924 top level 256 otime 2014-09-01 04:04:36 
path home_BACKUP-2014-09-01

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


So clearly, in this instance, I did a mkfs.btrfs on the device to create 
/, 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 
the diff of these two outputs to decide what to snapshot and what to 
age. No big deal. Works fine.

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

BUT...

 From that moment on the backup script would be broken because the 
"restore-shot" (ha ha) is now going to show up in "btrfs sub list -s /" 
where it would be excluded from being snapshotted and where it would be 
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 
boxes involved in the target roll-out. I could use naming conventions. I 
could do a lot of things, but they'd become far more per-system specific.

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

So The Questions:

Does the "snapshotness" of a subvolume have any actual _ongoing_ purpose 
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 
operation since restoring the removed plumbing would be indeterminate.

-- Rob

Re: Promote Snapshot to Subvolume? (again)

[Florian Gamböck]

Sorry to come up with an old thread, but I'm really interested if 
something is going on with that idea. It would help in many situations 
if you could "promote" snapshots to "regular" subvolumes.

Let's for example take btrfs-restore: It does not restore snapshots by 
default, which is rather smart, because a snapshot should merely be a 
somewhat older version of an existing subvolume. But let's assume in 
some point in the past, you really messed up your /home and you used a 
snapshot to recreate it, like deleting the dirty /home subvolume and 
snapshotting the latest backup to a writeable /home again. Then, 
whatever the reason be, you see yourself confronted with using the 
btrfs-restore tool. Now per default you cannot restore /home, since it 
is officially a snapshot, but on the other hand, you do not want to 
restore all other snapshots together with /home (without fiddling with 
some regular expression path filter, that is).

To truly achieve the desired outcome, instead of snapshotting a backup 
to /home, you would have had to create a new subvolume /home and to 
reflink-cp all the contents from the snapshot to the new /home. I find 
this somehow irritating, given that snapshotting is almost instantly 
while cp takes quite some time on a big enough /home.

So I hereby want to push this snapshot-promoting request and would be 
interested in the developers' opinions!

-- 
Flo