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 ..... 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 ‘@20131024’ to ‘readonly/@20131024’: Read-only file system I know I can create other new ro snapshots within the readonly directory and then delete those above but in the future I want to send/receive based 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Oct 24, 2013, at 9:29 AM, Karl Kiniger <karl.kiniger@med.ge.com> wrote:> 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 > ..... > 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 ‘@20131024’ to ‘readonly/@20131024’: Read-only file systemAre 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 tree into another. But there was a bug that prevented moving of subvolumes into subvolumes (untested if moving subvolumes into folders worked) that 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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.) -- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu 131024, Chris Murphy wrote:> > On Oct 24, 2013, at 9:29 AM, Karl Kiniger <karl.kiniger@med.ge.com> wrote: > > > 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 > > ...........> > 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 ‘@20131024’ to ‘readonly/@20131024’: Read-only file system > > Are the @ snapshot read only snapshots? And is read only just a regular 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> > 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 tree into another. But there was a bug that prevented moving of subvolumes into subvolumes (untested if moving subvolumes into folders worked) that 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 majordomo@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Oct 24, 2013, at 3:57 PM, Karl Kiniger <karl.kiniger@med.ge.com> wrote:> > 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.This is an imperfect example: dr--------. 1 chris chris 0 Oct 24 16:15 donotmove [chris@f20s ~]$ mv donotmove/ Videos/ mv: cannot move ‘donotmove/’ to ‘Videos/donotmove’: Permission denied'' I own that directory. But because it''s read only, I can''t move it because moving it changes it. Of course if I become root, that overrides posix 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 131024, Chris Murphy wrote:> dr--------. 1 chris chris 0 Oct 24 16:15 donotmove > > [chris@f20s ~]$ mv donotmove/ Videos/ > mv: cannot move ‘donotmove/’ to ‘Videos/donotmove’: Permission denied'' > > I own that directory. But because it''s read only, I can''t move it because moving it changes it. Of course if I become root, that overrides posix 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.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 ‘foo’: 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> Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Oct 24, 2013, at 4:46 PM, Karl Kiniger <karl.kiniger@med.ge.com> wrote:> On Thu 131024, Chris Murphy wrote: >> dr--------. 1 chris chris 0 Oct 24 16:15 donotmove >> >> [chris@f20s ~]$ mv donotmove/ Videos/ >> mv: cannot move ‘donotmove/’ to ‘Videos/donotmove’: Permission denied'' >> >> I own that directory. But because it''s read only, I can''t move it because moving it changes it. Of course if I become root, that overrides posix 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. > > 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 ‘foo’: 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.For 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 131024, Chris Murphy wrote:> > On Oct 24, 2013, at 4:46 PM, Karl Kiniger <karl.kiniger@med.ge.com> wrote:> In what way would a r/o snapshot be modified because of moving its> > "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> > Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Oct 24, 2013, at 5:13 PM, Karl Kiniger <karl.kiniger@med.ge.com> wrote:> On Thu 131024, Chris Murphy wrote: >> >> On Oct 24, 2013, at 4:46 PM, Karl Kiniger <karl.kiniger@med.ge.com> wrote: >> In what way would a r/o snapshot be modified because of moving its >>> "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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > On Thu 131024, Chris Murphy wrote: > >> > >> On Oct 24, 2013, at 4:46 PM, Karl Kiniger <karl.kiniger@med.ge.com> wrote:....> > > > 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> Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat 131026, Christian Robert wrote:> you can change a "ro" snapshot into a "rw" snapshot> you just snapshot it without the -r" optionYes, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html