linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


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