On Thu, May 17, 2018 at 5:46 AM, james harvey <jamespharvey20@xxxxxxxxx> wrote: > ... > In short, "btrfs device replace" caused it... > ... This should read "btrfs replace". Ran a 2 year old ISO, archlinux-2016.04.01-dual.iso. Kernel 4.4.5, btrfs-progs v4.4.1. Same behavior as example, so not a (within 2 year) regression. (Back on current kernel/btrfs...) Confirmed same behavior using existing device to replace rather than id, adding a 4th partition to the disk in my example: # btrfs replace start -B /dev/vda1 /dev/vda4 /mnt -or even- # btrfs replace start -Br /dev/vda1 /dev/vda1 /mnt Realized in my original example, I didn't run "filefrag -v" again to make sure the physical offsets didn't change. But, tried the example again with it, and replace didn't change them. There's a workaround, before a fix is available, and for anyone who can't upgrade to a new version once the fix is available: # btrfs device add /dev/vda4 /mnt # btrfs device remove /dev/vda1 /mnt This does more than just make new mirrored copies on /dev/vda4 of the data that was on /dev/vda1. At least in my run of this example, it moves the mirrored copies for the file from physical offsets starting 269952 to 531904, from device ids 1&2 to 3&4. So, it might take a bit longer. But, who cares, it leaves the data properly mirrored and in compressed form. I'll also note that even before any of the patches in the past few days, this is sufficient to re-write the file uncompressed, respecting its NOCOW attribute: # cp zero /root/zero # cp /root/zero zero # sync -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
