1

I'm attempting to perform a backup to an external hard drive. Both the native drive and external drive use a BTRFS filesystem. I do this by first creating a read-only snapshot of my home directory:

# btrfs subvolume snapshot -r /home /.snapshots/home/BACKUP

Followed by a send/receive to the backup drive:

# btrfs send /.snapshots/home/BACKUP | btrfs receive /.backup/home

I get this output:

At subvol /.snapshots/home/BACKUP
At subvol BACKUP
ERROR: failed to clone extents to matt/.local/share/Anki2/Matt/collection.anki2: Invalid argument

where the error occurs after a minute or so. I tried with several different snapshots and got the same error on each. Moreover, I couldn't find that file in any of the snapshots. I thought this might be some sort of disk corruption error, so I booted into a USB OS image and ran

# btrfs check --repair /dev/mapper/...

on the unmounted filesystem. This reported no errors. After booting back into the filesystem, I tried the backup again and got the same error. Any thoughts on what could be causing this?


EDIT

As per Emmanuel Rosa's comment, I tried

# btrfs scrub start -B /

which exited without errors. The issue is still present after the scrub.


EDIT 2

I wasn't able to figure out what was wrong with this. I ended up just deleting the local file and then it worked again.


EDIT 3

While deleting files temporarily suspends the issue, new files are often created that create the same error, so this really isn't resolved. sqlite files seem to be particularly problematic.

4
  • Oh, boy. btrfs check --repair is the LAST thing one should run. See man btrfs-check. btrfs scrub may be useful. Check man btrfs-scrub to see if it fits your use case. Apr 12, 2020 at 12:51
  • Thanks for the heads up about btrfs-check repair and for pointint out scrub. Unfortunately, scrub didn't find any errors and I got the same error.
    – MattHusz
    Apr 12, 2020 at 17:21
  • Do any of the btrfs subvolume {find-new,list,show} commands show any surprises for your subvolumes?
    – rickhg12hs
    Apr 14, 2020 at 13:41
  • As far as I can tell those all look normal.
    – MattHusz
    Apr 14, 2020 at 15:48

1 Answer 1

1

This was apparently a bug in the Linux kernel, which was fixed by this commit. I discovered this by posting a question on the btrfs mailing list. Upgrading the kernel resolved the issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .