From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Why cannot I move a read-only snapshot around?
Date: Thu, 24 Oct 2013 18:05:07 +0000 (UTC) [thread overview]
Message-ID: <pan$85344$b336f5bf$ca444091$a3ef1e0c@cox.net> (raw)
In-Reply-To: 20131024152955.GA6110@kipc2.localdomain
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
next prev parent reply other threads:[~2013-10-24 18:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 15:29 Why cannot I move a read-only snapshot around? Karl Kiniger
2013-10-24 15:37 ` Karl Kiniger
2013-10-24 17:10 ` Chris Murphy
2013-10-24 21:57 ` Karl Kiniger
2013-10-24 22:28 ` Chris Murphy
2013-10-24 22:46 ` Karl Kiniger
2013-10-24 22:51 ` Chris Murphy
2013-10-24 23:13 ` Karl Kiniger
2013-10-25 0:57 ` Chris Murphy
2013-10-25 8:00 ` Karl Kiniger
2013-10-24 18:05 ` Duncan [this message]
2013-10-24 22:09 ` Karl Kiniger
2013-10-26 5:45 ` Christian Robert
2013-10-28 11:56 ` Karl Kiniger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$85344$b336f5bf$ca444091$a3ef1e0c@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).