On Thu, Jul 04, 2013 at 04:14:23PM +0200, Stefan Behrens wrote: > Miao Xie reported the following issue: > > The filesystem was corrupted after we did a device replace. > > Steps to reproduce: > # mkfs.btrfs -f -m single -d raid10 <device0>..<device3> > # mount <device0> <mnt> > # btrfs replace start -rfB 1 <device4> <mnt> > # umount <mnt> > # btrfsck <device4> > > The reason for the issue is that we changed the write offset by mistake, > introduced by commit 625f1c8dc. > > We read the data from the source device at first, and then write the > data into the corresponding place of the new device. In order to > implement the "-r" option, the source location is remapped using > btrfs_map_block(). The read takes place on the mapped location, and > the write needs to take place on the unmapped location. Currently > the write is using the mapped location, and this commit changes it > back by undoing the change to the write address that the aforementioned > commit added by mistake. > I'd like to see a xfstest for this please so we can make sure something like this doesn't happen in the future. You can use SCRATCH_DEV_POOL to have multiple devices. Please cc linux-btrfs when you submit it so I can review it and hopefully get it in faster. Thanks, Josef -- 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
