On Sun, Mar 20, 2016 at 10:34 PM, Ryan Erato <[email protected]> wrote: . > > Sending "home.snap" to "/mnt/ssd" results in the -2 error. What is > peculiar, or possibly a red herring, is that it seems to fail at the > same point each time, at 4.39GB in to the transfer.
That's pretty suspicious. I didn't realize from the first description that the command is doing something for a while before failing. I thought it was failing immediately. Try this: btrfs send -vvv --no-data -f homesnap.btr home.snapshot That will write out metadata only to a file, no receive. See if the error still happens and if the extra v gives more info. If it still fails with no more useful information then what I'd try next is a btrfs check with the most recent btrfs-progs you can find. If you're in need of a suggestion, this has btrfs-progs 4.4.1, I've tested that it boots, it's got a published sha256 hash, and is served over https. Yes, it's not even an alpha, but all you're doing is a check, not a --repair, and no need to mount it (although that's probably safe also, I've been doing it most of the weekend). https://dl.fedoraproject.org/pub/alt/stage/24_Alpha-1.6/Workstation/x86_64/iso/ dd that iso file to a USB stick, it will destroy all data on the stick, and then boot the computer, and switch to tty2 (control-alt-f2) to get to a shell. I think 'btrfs check > btrfscheck.txt' will output most of the results to a text file. Often it misses the first few lines for whatever reason. You can either 'fpaste <filename>' and then note the URL and post it here, or you can scp the file elsewhere, if you have wired ethernet connected. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
