2014-10-23 18:36:22 UTC
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
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=
"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=
ID 963 gen 262648 cgen 262646 top level 256 otime 2014-06-18 02:27:38=20
ID 964 gen 330331 cgen 330330 top level 5 otime 2014-07-15 18:51:18 pat=
ID 965 gen 330331 cgen 330331 top level 256 otime 2014-07-15 18:51:26=20
ID 970 gen 443923 cgen 443922 top level 5 otime 2014-09-01 04:04:14 pat=
ID 971 gen 443924 cgen 443924 top level 256 otime 2014-09-01 04:04:36=20
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"=20
and which are part of the backup scheme. (more-so with consideration fo=
read-only status but that's an aside.)
So clearly, in this instance, I did a mkfs.btrfs on the device to creat=
/, 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=20
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 th=
/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
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 /"=
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=20
boxes involved in the target roll-out. I could use naming conventions. =
could do a lot of things, but they'd become far more per-system specifi=
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=
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.
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html