public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Ian Kelling <iank@fsf.org>
To: Btrfs <linux-btrfs@vger.kernel.org>
Subject: bug: btrfs receive: ERROR: clone: did not find source subvol
Date: Tue, 31 Jan 2023 09:02:27 -0500	[thread overview]
Message-ID: <87mt5y4uyj.fsf@fsf.org> (raw)

on sending host:
btrfs send -p /mnt/root/btrbk/q.20230126T000018-0500 /mnt/root/btrbk/q.20230130T200019-0500
on receiving host:
btrfs -v receive '/mnt/root/btrbk/'
...
write p/c/firefox-swf-profile/places.sqlite - offset=0 length=32768
... (642 similar lines writing to places.sqlite)
write path/to/abrowser-profile/places.sqlite - offset=42860544 length=32768
write path/to/abrowser-profile/places.sqlite - offset=42893312 length=49152
write path/to/abrowser-profile/places.sqlite - offset=42942464 length=16384
ERROR: clone: did not find source subvol


On the receiving machine:

# cat /proc/version 
Linux version 6.1.4-060104-generic (kernel@sita) (x86_64-linux-gnu-gcc-12 (Ubuntu 12.2.0-9ubuntu1) 12.2.0, GNU ld (GNU Binutils for Ubuntu) 2.39) #202301071207 SMP PREEMPT_DYNAMIC Sun Jan  8 18:52:10 UTC 2023
 # btrfs --version
btrfs-progs v6.1.2


On the sending machine:

# cat /proc/version
Linux version 6.1.8-gnu (rms@mit-oz) (x86_64-linux-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.40) #1.0 SMP PREEMPT_DYNAMIC Tue Sep 27 12:35:59 EST 1983
# btrfs --version
btrfs-progs v6.1.2

The snapshot was created running those versions.

I take snapshots hourly and send and receive them using btrbk, which is
a perl wrapper. This error has happened around 7 times in the last year
or so, and when I inspected, it was always places.sqlite, which is a 45M
sqlite database of firefox containing browsing history. Note, I use
abrowser, a rebranded firefox in trisquel that fixes some software
freedom issues. The workaround I've found is to delete the parent
snapshot on sending machine. The error exists for any combination of
that parent and a subsequent snapshot.

A few details about the sending machine where the bad snapshot
originated: It is using ECC ram and reported no ECC errors, and no
kernel errors anywhere near the time of the snapshot. The disks are 2
ssds in raid1.

I'm happy to help the btrfs developers debug the issue, running any
commands, running alternate software, etc. Note, I can't share
places.sqlite file as it contains private browsing history.


-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

             reply	other threads:[~2023-01-31 14:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 14:02 Ian Kelling [this message]
2023-01-31 16:57 ` bug: btrfs receive: ERROR: clone: did not find source subvol Andrei Borzenkov
2023-02-18 14:42   ` Ian Kelling
2023-02-24 17:55     ` Andrei Borzenkov
2023-05-02 21:22       ` btrfs receive: ERROR: clone: did not find source subvol (user error, not a bug) Ian Kelling
2023-05-21 22:26         ` Ian Kelling

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=87mt5y4uyj.fsf@fsf.org \
    --to=iank@fsf.org \
    --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