you can change a "ro" snapshot into a "rw" snapshot
you just snapshot it without the -r" option
ex:
# btrfs subv snap -r linux-3.12-rc5 snap_ro
Create a readonly snapshot of 'linux-3.12-rc5' in './snap_ro'
# touch ./snap_ro/helo
touch: cannot touch ‘./snap_ro/helo’: Read-only file system
# btrfs subv snap snap_ro snap_rw
Create a snapshot of 'snap_ro' in './snap_rw'
# touch ./snap_rw/helo
# btrfs subv delete ./snap_ro
Delete subvolume '/data/snap_ro'
# mv snap_rw snap_any
# ls -ld snap*
drwxrwxr-x 1 root root 944 Oct 26 01:41 snap_any/
On 2013-10-24 18:09, Karl Kiniger wrote:
Hi
(pls see also my other reply in this thread)
On Thu 131024, Duncan wrote:
Karl Kiniger posted on Thu, 24 Oct 2013 17:29:56 +0200 as excerpted:
Dear list, (newbie alert)
After sucessfully sending and receiving a dozen of related snapshots I
want to move them all to the readonly folder but I cannot:
I see you mention fedora 19 in a followup, but for those not on fedora,
that's not much help figuring out which kernel you're running. It's
likely that the following is your problem, tho there's not enough
information in your post to be sure.
I promise to include more info in the future but just received
snapshots should be read-only if I read the docs correctly.
There was a recent regression with nested subvolumes that may be what
you're running into. Kernel 3.11 was affected as well as early 3.12-rcs
and I believe 3.10 also but I'm not sure how far back, except that
someone mentioned trying an old kernel (3.8 or 3.6-ish) and moving
subvolumes into subvolumes worked there (tho doing anything involving
writing into read-only snapshots shouldn't work, by design, but that
doesn't appear to be what you're doing, you're just trying to move read-
only snapshots to a different location on a read/write base or parent
subvolume, this post assuming it's a parent subvolume, thus triggering
the nested subvolumes bug).
No nested subvolumes involved. (Is this true? This all is inside the top
level volume or what it is called in btrfs.....)
A fix is available but I'm not sure whether it got into 3.12 (which is
just about to be released) or will now have to wait for 3.13. So either
try latest 3.12 git and see if its there, or find and cherry-pick the
patch, applying it against 3.11 or 3.12. (Given that btrfs is still an
experimental filesystem with fixes applied every kernel, while reverting
to an old enough kernel should unregress this particular problem, I can't
recommend it except possibly for testing against data you don't care
about, since by doing so you're exposing yourself to other known and now
fixed bugs.)
Agreed, I dont want to go back to older kernels - too risky. The data are
backed up anyways (on ZFS if you are curious) but the time invested into
my current btrfs setup would be gone.
I can live with the current situation, its just not nice to have the
snapshots lying around in a place where they should not belong.
If it were possible to temporarily make the r/o snapshots r/w just for
the purpose of moving (being aware that caution is needed) I would
not hesitate ane try that.
Karl
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
