Why cannot I move a read-only snapshot around?

[Karl Kiniger]

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:

ls -l
=2E....
drwxr-xr-x. 1 root root 682 Oct 24 16:01 @20131001
drwxr-xr-x. 1 root root 682 Oct 24 16:07 @20131004
drwxr-xr-x. 1 root root 682 Oct 24 16:10 @20131008
drwxr-xr-x. 1 root root 682 Oct 24 16:16 @20131010
drwxr-xr-x. 1 root root 682 Oct 24 16:23 @20131014
drwxr-xr-x. 1 root root 706 Oct 24 16:24 @20131018
drwxr-xr-x. 1 root root 706 Oct 24 16:31 @20131021
drwxr-xr-x. 1 root root 734 Oct 24 16:36 @20131023
drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly


mv \@20131024 readonly

mv: cannot move =E2=80=***@20131024=E2=80=99 to =E2=80=98readonly/@20131=
024=E2=80=99: Read-only file system

I know I can create other new ro snapshots within the readonly directo=
ry
and then delete those above but in the future I want to send/receive ba=
sed on
those snapshots (send -p .... -c .... -c ....) but I want to move them
to a more convenient place.

How can I move them without re-sending all?

Karl

--
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

[Karl Kiniger]

arrgh, forgot to mention:

pc2:~> btrfs --version
Btrfs v0.20-rc1

Fedora 19 x86_64

Karl


--
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

[Chris Murphy]

Post by Karl Kiniger
Dear list, (newbie alert)
=20
After sucessfully sending and receiving a dozen of related snapshots
=20
ls -l
.....
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
=20
=20
=20

y file system

Are the @ snapshot read only snapshots? And is read only just a regular=
directory?

I don't know that this is a bug, it seems like it could be intentional =
because a read only file system wouldn't let you move it out of one tre=
e into another. But there was a bug that prevented moving of subvolumes=
into subvolumes (untested if moving subvolumes into folders worked) th=
at was fixed in kernel 3.11.6 so that might be worth a shot.


Chris Murphy--
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

[Karl Kiniger]

Hi,=20

=20
=20

Post by Karl Kiniger
Dear list, (newbie alert)
=20
After sucessfully sending and receiving a dozen of related snapsho=

ts

Post by Karl Kiniger
=20
ls -l
.....

=2E.....

Post by Karl Kiniger
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
=20
=20
=20

0131024=E2=80=99: Read-only file system

=20

ar directory?

Yes they are read only snapshots (just received by btrfs receive) and
"readonly" is a regular directory. I deliberately did not try to move
those snapshots into other snapshots.

I can move r/w snapshots around without problems
(into some regular directory), just the r/o snapshots refuse moving.

cat /proc/version
Linux version 3.11.6-200.fc19.x86_64

Still curious,

Karl

=20
I don't know that this is a bug, it seems like it could be intentiona=

l because a read only file system wouldn't let you move it out of one t=
ree into another. But there was a bug that prevented moving of subvolum=
es into subvolumes (untested if moving subvolumes into folders worked) =
that was fixed in kernel 3.11.6 so that might be worth a shot.

=20
=20
Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=

" in

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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Chris Murphy]

Post by Karl Kiniger
=20
Yes they are read only snapshots (just received by btrfs receive) and
"readonly" is a regular directory. I deliberately did not try to move
those snapshots into other snapshots.
=20
I can move r/w snapshots around without problems
(into some regular directory), just the r/o snapshots refuse moving.

This is an imperfect example:

dr--------. 1 chris chris 0 Oct 24 16:15 donotmove

[***@f20s ~]$ mv donotmove/ Videos/
mv: cannot move =91donotmove/=92 to =91Videos/donotmove=92: Permission =
denied'

I own that directory. But because it's read only, I can't move it becau=
se moving it changes it. Of course if I become root, that overrides pos=
ix permissions, but the readonly status of a subvolume isn't like posix=
permissions and I see now reason why root should be able to modify it.=
And moving it does modify it.


Chris Murphy--
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

[Karl Kiniger]

Post by Chris Murphy
dr--------. 1 chris chris 0 Oct 24 16:15 donotmove
=20
mv: cannot move =E2=80=98donotmove/=E2=80=99 to =E2=80=98Videos/donot=

move=E2=80=99: Permission denied'

Post by Chris Murphy
=20
I own that directory. But because it's read only, I can't move it bec=

ause moving it changes it. Of course if I become root, that overrides p=
osix permissions, but the readonly status of a subvolume isn't like pos=
ix permissions and I see now reason why root should be able to modify i=
t. And moving it does modify it.

tries this all as root.

drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024 (this is a r/o snap=
)

It looks to me similar to a read-only mounted filesystem:

pc2:/u2/F19/@20131024# touch foo
touch: cannot touch =E2=80=98foo=E2=80=99: Read-only file system

In what way would a r/o snapshot be modified because of moving its
"mount point" ? No one is ever doing something inside.

Karl

Post by Chris Murphy
Chris Murphy

--
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

[Chris Murphy]

Post by Karl Kiniger

Post by Chris Murphy
dr--------. 1 chris chris 0 Oct 24 16:15 donotmove
=20
mv: cannot move =91donotmove/=92 to =91Videos/donotmove=92: Permissi=

on denied'

Post by Karl Kiniger

Post by Chris Murphy
=20
I own that directory. But because it's read only, I can't move it be=

cause moving it changes it. Of course if I become root, that overrides =
posix permissions, but the readonly status of a subvolume isn't like po=
six permissions and I see now reason why root should be able to modify =
it. And moving it does modify it.

Post by Karl Kiniger
=20
tries this all as root.
=20

ap)

Post by Karl Kiniger
=20
=20
touch: cannot touch =91foo=92: Read-only file system
=20
In what way would a r/o snapshot be modified because of moving its
"mount point" ? No one is ever doing something inside.

=46or the same reason I can't move or rename a read only directory even=
though I'm not doing something inside.



Chris Murphy--
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

[Karl Kiniger]

Post by Karl Kiniger
In what way would a r/o snapshot be modified because of moving its

Post by Karl Kiniger
"mount point" ? No one is ever doing something inside.

For the same reason I can't move or rename a read only directory even though I'm not doing something inside.

I see now: the .. entry would change if the directory were being moved.

Still hoping there is a better way on btrfs than sending and receiving the snaps
just to a different folder.

Karl

Post by Karl Kiniger
Chris Murphy

--
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

[Chris Murphy]

Post by Karl Kiniger

Post by Karl Kiniger
In what way would a r/o snapshot be modified because of moving its

Post by Karl Kiniger
"mount point" ? No one is ever doing something inside.

For the same reason I can't move or rename a read only directory even though I'm not doing something inside.

I see now: the .. entry would change if the directory were being moved.
Still hoping there is a better way on btrfs than sending and receiving the snaps
just to a different folder.

Presumably you can rename/move the containing folder. So if it's in a folder already, create a replacement for it, mv the current containing folder into the replacement. And then rename them however you want.


Chris Murphy--
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

[Karl Kiniger]

....

Post by Chris Murphy

Post by Karl Kiniger
Still hoping there is a better way on btrfs than sending and receiving the snaps
just to a different folder.

Presumably you can rename/move the containing folder. So if it's in a folder already, create a replacement for it, mv the current containing folder into the replacement. And then rename them however you want.

Good idea, worked perfectly.
(fortunately there was a containing folder :-)

Thank you,
Karl

Post by Chris Murphy
Chris Murphy

--
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

[Duncan]

Post by Karl Kiniger
Dear list, (newbie alert)
After sucessfully sending and receiving a dozen of related snapshots I

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.

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).

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.)

[Karl Kiniger]

Hi

(pls see also my other reply in this thread)

Post by Duncan

Post by Karl Kiniger
Dear list, (newbie alert)
After sucessfully sending and receiving a dozen of related snapshots I

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.

Post by Duncan
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.....)

Post by Duncan
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

Post by Duncan
--
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Christian Robert]

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 =91./snap_ro/helo=92: 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/

Post by Karl Kiniger
Hi
(pls see also my other reply in this thread)

Post by Karl Kiniger
Dear list, (newbie alert)
After sucessfully sending and receiving a dozen of related snapsho=

ts I

Post by Karl Kiniger

I see you mention fedora 19 in a followup, but for those not on fedo=

ra,

Post by Karl Kiniger

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 wha=

t

Post by Karl Kiniger

you're running into. Kernel 3.11 was affected as well as early 3.12=

-rcs

Post by Karl Kiniger

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 involvin=

g

Post by Karl Kiniger

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 r=

ead-

Post by Karl Kiniger

only snapshots to a different location on a read/write base or paren=

t

Post by Karl Kiniger

subvolume, this post assuming it's a parent subvolume, thus triggeri=

ng

Post by Karl Kiniger

the nested subvolumes bug).

No nested subvolumes involved. (Is this true? This all is inside the =

top

Post by Karl Kiniger
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

Post by Karl Kiniger

just about to be released) or will now have to wait for 3.13. So ei=

ther

Post by Karl Kiniger

try latest 3.12 git and see if its there, or find and cherry-pick th=

e

Post by Karl Kiniger

patch, applying it against 3.11 or 3.12. (Given that btrfs is still=

an

Post by Karl Kiniger

experimental filesystem with fixes applied every kernel, while rever=

ting

Post by Karl Kiniger

to an old enough kernel should unregress this particular problem, I =

can't

Post by Karl Kiniger

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

Post by Karl Kiniger

fixed bugs.)

Agreed, I dont want to go back to older kernels - too risky. The data=

are

Post by Karl Kiniger
backed up anyways (on ZFS if you are curious) but the time invested =

into

Post by Karl Kiniger
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 fo=

r

Post by Karl Kiniger
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

Post by Karl Kiniger
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Karl Kiniger]

Post by Christian Robert
you can change a "ro" snapshot into a "rw" snapshot
you just snapshot it without the -r" option

Yes, I know but the new rw snapshots are not really identical
in terms of ID, generation count and UUID (the file contents will
remain the same of course).

The question is how this will affect btrfs send and receive,
especially considering the -p and -c option.

Karl

--
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