On Thu, Nov 08, 2012 at 06:24:36PM +0100, Stefan Behrens wrote: > On Thu, 8 Nov 2012 22:50:47 +0800, Liu Bo wrote: > > On Tue, Nov 06, 2012 at 05:38:33PM +0100, Stefan Behrens wrote: [...] > >> + btrfs_dev_replace_unlock(dev_replace); > >> + > >> + btrfs_wait_ordered_extents(root, 0); > >> + > >> + /* force writing the updated state information to disk */ > >> + trans = btrfs_start_transaction(root, 0); > > > > why a start_transaction here? Any reasons? > > (same question also for some other places) > > > > Without this transaction, there is outstanding I/O which is not flushed. > Pending writes that go only to the old disk need to be flushed before > the mode is switched to write all live data to the source disk and to > the target disk as well. The copy operation that is part of the scrub > code works on the commit root for performance reasons. Every write > request that is performed after the commit root is established needs to > go to both disks. Those requests that already have the bdev assigned > (i.e., btrfs_map_bio() was already called) cannot be duplicated anymore > to write to the new disk as well. > > btrfs_dev_replace_finishing() looks similar and goes through a > transaction commit between the steps where the bdev in the mapping tree > is swapped and the step when the old bdev is freed. Otherwise the bdev > would be accessed after being freed. > I see, if you're only about to flush metadata, why not join a transaction? thanks, liubo -- 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
