Getting a bit off-topic here, but were you able to boot from that fs with grub after a simple rsync?
On Mon, May 8, 2017 at 1:01 PM, Sean Greenslade <s...@seangreenslade.com> wrote: > 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
