On Mon, May 08, 2017 at 12:41:11PM -0400, Austin S. Hemmelgarn wrote: > Send/receive is not likely to transfer the problem unless it has something > to do with how things are reflinked. Receive operates by recreating the > sent subvolume from userspace using regular commands and the clone ioctls, > so it won't replicate any low-level structural issues in the filesystem > unless they directly involve the way extents are being shared (or are a side > effect of that). On top of that, if there is an issue on the sending side, > send itself will probably not send that data, so it's actually only > marginally more dangerous than using something like rsync to copy the data.
True, but my goal was to eliminate as many btrfs variables as I could. To answer the original question, I used rsync to copy the data and attributes (something like rsync -aHXp --numeric-ids) from a live CD to an external hard drive (formatted ext4), then ran mkfs.btrfs on the original partition, then re-ran the rsync in the opposite direction. It worked quite well for me, and the problem hasn't resurfaced. --Sean -- 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
