ERROR: cannot find parent subvolume, can't see reason for it.

ERROR: cannot find parent subvolume, can't see reason for it.

[J. Hart]

I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the 
following error:

ERROR: cannot find parent subvolume

The "src/snp1" is present in both "src/" and "dst/".   The "src/snp2" is 
present in "src/" .
The send works when "-p" is not used, but will not work when it is.

I imagine I am missing something obvious but cannot see what, and would 
appreciate some suggestions on what might be causing the error.

note: I have sent several queries to this list, but have not heard 
anything back.   I hope they have not been inappropriate.  If so, I 
would be grateful if you would let me know, or if there is somewhere 
else I should be going for advice.

I have had pretty good luck with the basics of btrfs and have high hopes 
for it.  I do seem to be having some difficulty getting much beyond 
basic functionality with small flat filesystem layouts, and will soon 
have to revert back to ext4 for some of the more complex functionality I 
made use of under that.   I look forward to seeing what further progress 
might be had with btrfs, and hope to be able to use it in a few years time.

Re: ERROR: cannot find parent subvolume, can't see reason for it.

[Duncan]

J. Hart posted on Sat, 29 Apr 2017 23:10:48 -0400 as excerpted:

> I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the
> following error:
> 
> ERROR: cannot find parent subvolume
> 
> The "src/snp1" is present in both "src/" and "dst/".   The "src/snp2" is
> present in "src/" .
> The send works when "-p" is not used, but will not work when it is.
> 
> I imagine I am missing something obvious but cannot see what, and would
> appreciate some suggestions on what might be causing the error.

Note that my own use-case doesn't include send/receive, so the degree to 
which I can get into specific detail is limited, but as you mentioned 
sometimes we miss the obvious and need someone else to point it out, so 
in that spirit, here's a couple obvious things:

* Your apparently contrived for posting paths above are relative.  Have 
you tried absolute paths and/or are you certain the relative paths are 
correctly relative to your current working directory?

* src/snp1 is a read-only snapshot, not just a directory, correct?

> note: I have sent several queries to this list, but have not heard
> anything back.   I hope they have not been inappropriate.  If so, I
> would be grateful if you would let me know, or if there is somewhere
> else I should be going for advice.

I see three previous threads (the first starting on March 25) with you as 
original poster on the list, all of which have followups to the list, one 
of which has a single followup from you to someone replying to you, from 
you as well.  I don't however see any followups from you to replies on 
the other two threads, and only the one followup to someone replying on 
the one thread.

So it may be that you're not getting the replies very well.

Are you subscribed to the list?  While some posters reply directly to 
author as well, and that's encouraged, some reply only to the list 
(including me unless specifically asked or there's some other hint, as 
here, that it may be needed).

The other possibility, of course, is that replies are getting spam-binned 
via gmail or on your end.  You may want to check that.

Meanwhile, if you're subscribed or are otherwise not getting replies, 
there's a number of list archives available, see:

https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list

The mail-archive one is probably easier to use than marc, and the gmane 
web-based archive is offline, possibly permanently. 

(Gmane does still have the news-based, that is nntp:// archive available, 
which I actually read and post thru myself, but the service recently 
changed hands and there's little information on whether the web service 
is coming back or not, and without it the news side is likely to 
eventually die as well.)

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

Re: ERROR: cannot find parent subvolume, can't see reason for it.

[Chris Murphy]

On Sat, Apr 29, 2017 at 9:10 PM, J. Hart <jfhart085@gmail.com> wrote:
> I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the
> following error:
>
> ERROR: cannot find parent subvolume
>
> The "src/snp1" is present in both "src/" and "dst/".

It's not merely that it must be present. The src/snp1 must have
originally been sent to dst/ using btrfs send/receive. And in
particular it's trying to match subvolume UUIDs; so really the error
is "cannot find parent subvolume uuid on the destination"  - at least
I *think* that's what's going on.

You'd need to use -v or possibly -vv with both the send and receive
commands to get more verbose output and maybe see whether it's the
send or receive side having the problem. I'm gonna guess it's the
receive side.


-- 
Chris Murphy

Re: ERROR: cannot find parent subvolume, can't see reason for it.

[J. Hart]

Thank you very much for your response.

I had just discovered exactly this a few hours ago.  In sending an 
original snapshot instead of using a duplicate already in place, I was 
able to get around this problem.
As you mentioned, the error was coming from the receive side.

I am presently investigating a another error I have detailed in another 
message:

ERROR: rename o3528-7220-0 -> usr failed: Directory not empty

It is probably not related.  I will file a report with Kernel.org 
bugzilla on it.


On 04/30/2017 04:43 PM, Chris Murphy wrote:
> On Sat, Apr 29, 2017 at 9:10 PM, J. Hart <jfhart085@gmail.com> wrote:
>> I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the
>> following error:
>>
>> ERROR: cannot find parent subvolume
>>
>> The "src/snp1" is present in both "src/" and "dst/".
> It's not merely that it must be present. The src/snp1 must have
> originally been sent to dst/ using btrfs send/receive. And in
> particular it's trying to match subvolume UUIDs; so really the error
> is "cannot find parent subvolume uuid on the destination"  - at least
> I *think* that's what's going on.
>
> You'd need to use -v or possibly -vv with both the send and receive
> commands to get more verbose output and maybe see whether it's the
> send or receive side having the problem. I'm gonna guess it's the
> receive side.
>
>

Re: ERROR: cannot find parent subvolume, can't see reason for it.

[J. Hart]

Thank you very much for your thoughtful and thorough reply.   I 
appreciate this very much.

I have finally been able to work past the issue.  It seems that 
send/receive participates in maintaing some sort of "chain of 
custody/ancestry".  I had been using a pre-existing snapshot at the 
destination instead of sending over an identical original via "btrfs 
send".   This seems to have had the effect of "breaking" that "chain", 
causing send to refuse to use that snapshot as a parent.  When the 
original is sent,  send can use it  as such, and the operation I was 
attempting proceeds without error.

On 04/30/2017 03:07 AM, Duncan wrote:
> [This mail was also posted to gmane.comp.file-systems.btrfs.]
>
> J. Hart posted on Sat, 29 Apr 2017 23:10:48 -0400 as excerpted:
>

> I see three previous threads (the first starting on March 25) with you 
> as original poster on the list, all of which have followups to the 
> list, one of which has a single followup from you to someone replying 
> to you, from you as well. I don't however see any followups from you 
> to replies on the other two threads, and only the one followup to 
> someone replying on the one thread. So it may be that you're not 
> getting the replies very well. Are you subscribed to the list? While 
> some posters reply directly to author as
I will try keeping a more careful eye on the archives as you suggest and 
see if I am missing replies.

With Thanks,

J. Hart