Re: ERROR: cannot find parent subvolume, can't see reason for it.
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. Hartwrote: 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ERROR: cannot find parent subvolume, can't see reason for it.
On Sat, Apr 29, 2017 at 9:10 PM, J. Hartwrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ERROR: cannot find parent subvolume, can't see reason for it.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ERROR: cannot find parent subvolume, can't see reason for it.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ERROR: cannot find parent subvolume, can't see reason for it.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html